Det här avsnittet innehåller svar på frågor som ofta ställs om att använda omdirigeringserbjudanden när Adobe Analytics används som rapportkälla för Adobe Target (A4T).
Har Analytics för Adobe Target (A4T) stöd för omdirigeringserbjudanden? section_46B8B03ED4D542C6AD875F5F61176298
Svar
Ja, om implementeringen använder at.js. Implementeringen måste dock uppfylla de minimikrav som anges nedan för att kunna använda omdirigeringserbjudanden i aktiviteter som använder Analytics som rapportkälla.
Vilka är minimikraven för omdirigeringserbjudanden med A4T? section_FA9384C2AA9D41EDBCE263FFFD1D9B58
Svar
Implementeringen måste uppfylla följande minimikrav:
Experience Cloud Visitor ID-tjänst: visitorAPI.js version 2.3.0 eller senare.
Adobe Analytics: appMeasurement.js version 2.1.
Adobe Target: at.js version 1.6.2 eller senare.
De tre biblioteken måste finnas på både sidan med omdirigeringserbjudandet och den sida som besökaren omdirigeras till.
Varför finns det ibland avvikelser i data mellan A4T och Analytics?
Hur minimerar jag avvikelser i trafikfördelningen när jag använder omdirigeringserbjudanden i A4T-aktiviteter? discrepancies
Svar
Ett begränsat antal kunder har rapporterat större variationsgrader i trafikdistributionen när omdirigeringserbjudanden används i aktiviteter som konfigurerats med Analytics for Target (A4T).
Tänk på följande:
Felaktig ordning för Target- och Analytics-anrop kan ge upphov till högre variationsgrader.
Anropet Target måste föregå anropet Analytics på källsidan (där omdirigering sker) och på målsidan (där omdirigering avslutas).
Se till att du använder omdirigeringserbjudanden i A4T-omdirigeringsaktiviteter.
Om det finns flera Target platsförfrågningar på källsidan (där omdirigering sker) rekommenderar Adobe att du kör omdirigeringsaktiviteten på den första Target-platsförfrågan.
Om du kör omdirigeringsaktiviteten på den första Target-platsbegäran minskar risken för aktivitetskvalifikationer som inträffar på andra Target-platsbegäranden och räknas i rapporten. Besökare som omdirigeras behöver inte räknas med i rapporterna om andra aktiviteter eftersom de inte kommer att se upplevelserna.
Varför räknas ibland sidvisningar på originalsidan och på omdirigeringssidan? section_B8F6CC2190B84CF08D945E797C5AF07B
Svar
När du använder at.js version 1.6.3 eller senare är det inte något problem att räkna sidvisningar på båda sidorna. Detta konkurrensvillkor påverkar endast kunder som använder tidigare versioner. Target-teamet har två versioner av at.js: den aktuella versionen och den andra senaste versionen. Uppgradera at.js efter behov för att kontrollera att du kör en version som stöds.
Om du använder en tidigare version av at.js som inte stöds finns det en risk för att ett konkurrensvillkor kan uppstå som kan få Analytics-anropet att utlösas innan omdirigeringen körs på den första sidan. Detta kan leda till att sidvisningar på den ursprungliga sidan och på omdirigeringssidan räknas. Detta resulterar i en extra sidvy på den första sidan, där besökaren aldrig riktigt "såg" den första sidan.
Vi rekommenderar att du använder den formulärbaserade dispositionen för att skapa en omdirigeringsaktivitet för att öka hastigheten på omdirigeringen på sidan eftersom koden körs på sidan. Du bör också skapa ett omdirigeringserbjudande för varje upplevelse, även standardupplevelsen, där omdirigeringen skulle returnera originalsidan. Genom att skapa ett omdirigeringserbjudande för varje upplevelse säkerställer du att det sker i alla upplevelser om en felräkning inträffar. Rapportering och analys är fortfarande giltiga för testet.
En anledning till att du kanske vill använda omdirigeringserbjudanden för alla upplevelser i aktiviteten, inklusive standardupplevelsen (kontrollen), är att ange samma villkor för alla upplevelser. Om till exempel standardupplevelsen inte har något omdirigeringserbjudande, men de andra upplevelserna har omdirigeringserbjudanden, har upplevelsen utan omdirigeringserbjudandet en inneboende fördel. Omdirigeringserbjudanden rekommenderas endast för tillfälliga scenarier, till exempel testning. Omdirigeringserbjudanden rekommenderas inte för permanenta scenarier, som personalisering. När du har bestämt "vinnaren" bör du ta bort omdirigeringen för att förbättra sidladdningsprestanda.
Stöds både Visual Experience Composer (VEC) och Form-Based Experience Experience Composer? section_FDA26FE7909B48539DA770559E687677
Svar
Ja, båda dispositionerna stöds så länge du använder de inbyggda omdirigeringserbjudandena.
Om du använder din egen anpassade kod för omdirigeringen måste du se till att du fyller i de två nya parametrar som är kopplade till omdirigerings-URL:er ( adobe_mc_sdid och adobe_mc_ref, som förklaras nedan).
Vilka nya frågesträngsparametrar läggs till i omdirigerings-URL:erna? section_BA73E8B3CFCC4CBEB5BE3F76B2BC8682
Svar
Följande frågesträngsparametrar är associerade med omdirigeringserbjudanden:
table 0-row-2 1-row-2 2-row-2
Parameter
Beskrivning
adobe_mc_sdid
Parametern adobe_mc_sdid skickar SDID (Additional Data Id) och Experience Cloud Org Id från standardsidan till den nya sidan. Med dessa ID:n kan A4T"sy ihop" Target-begäran på standardsidan med Analytics-begäran på den nya sidan. Det förväntade formatet som ska överföras i URL:en (för hybridappar eller från en app till webbplatsen eller en webbplats till en annan) är `ex. adobe_mc_sdid=SDID=123
adobe_mc_ref
Parametern adobe_mc_ref skickar den refererande URL-adressen för standardsidan till den nya sidan. När Analytics används med AppMeasurement.js version 2.1 (eller senare) används det här parametervärdet som den refererande URL:en på den nya sidan.
Parametrarna läggs automatiskt till i omdirigerings-URL:erna när de inbyggda omdirigeringserbjudandena i VEC och formulärbaserad Experience Composer används när besökar-ID-tjänsten implementeras på sidan. Om du använder din egen anpassade omdirigeringskod i VEC eller formulärbaserad disposition måste du se till att skicka de här parametrarna med din anpassade kod.
Mina webbservrar tar bort de här parametrarna från mina URL:er, vad ska jag göra? section_0C2DDB72939F4875B6D0428B8DCB38E5
Svar
Arbeta med IT-teamet för att få dessa parametrar ( adobe_mc_sdid och adobe_mc_ref) tillåtslista.
Vad händer om jag inte använder A4T med min omdirigeringsaktivitet och inte vill att de här extra parametrarna ska läggas till i mina URL:er? section_9E608D75FF9349FE96C65FEDD7539F45
Svar
Använd en anpassad kodad omdirigering om:
Du använder inte A4T med omdirigeringsaktiviteten
Tjänsten för besökar-ID är implementerad
Du vill inte att de här parametrarna ska läggas till automatiskt i dina URL-adresser
Som god praxis kanske du vill behålla parametern adobe_mc_ref i URL:en för att rapportera referensinformationen till Analytics korrekt.
Varför är parametrarna adobe_mc_ref och adobe_mc_sdid dubbelt så URL kodade i min implementering? section_5EFE5F012B944C40865731EA18E7E79E
Svar
Om du använder A4T och omdirigeringserbjudanden lägger Target till parametrarna adobe_mc_ref och adobe_mc_sdid till URL:en. Dessa värden är redan URL-kodade. För det mesta fungerar allt som förväntat, men vissa kunder kan ha belastningsutjämnare eller WEB-servrar som försöker koda frågesträngsparametrarna en gång till.
På grund av den här dubbla kodningen när besökar-API:t försöker avkoda värdet adobe_mc_sdid kan det inte extrahera SDID-värdet och generera ett nytt SDID. Den här processen leder till att felaktiga SDID-värden skickas till Target och Analytics, och du ser en ojämn delning för omdirigeringar i Analytics-rapporter.
Adobe rekommenderar att du pratar med IT-teamet för att säkerställa att adobe_mc_ref och adobe_mc_sdid tillåtslista så att dessa värden inte förändras på något sätt.
Varför ska den refererande URL:en skickas till den nya sidan? section_91AB8B0891F6416CBF7E973DCAF54EB5
Svar
Anta att en besökare klickar på en länk på www.google.com till din hemsida (www.mysite.com/index.html) där en omdirigeringsaktivitet är aktiv och sedan omdirigeras till en ny sida (www.mysite.com/index2.html).
Tidigare skulle Analytics-begäran på den nya sidan rapportera den refererande URL:en www.mysite.com/index.html i stället för www.google.com. Detta orsakade felaktig rapportering i Analytics som är kopplad till de refererande URL:erna (till exempel marknadsföringskanalrapporter). Rapporterna hade förlorat det faktum att du kom till webbplatsen från www.google.com.
Med at.js version 0.9.6 (eller senare) och AppMeasurement.js 2.1 (eller senare) rapporterar Analytics-begäran på den nya sidan den refererande URL:en www.google.com.
Kan jag använda anpassade omdirigeringserbjudanden från HTML? section_E49F9A83A286488C8F1098A040203D7E
Svar
Nej, du måste använda ett inbyggt omdirigeringserbjudande för aktiviteter som använder Analytics som rapportkälla (A4T). Från Target-perspektivet är erbjudanden från HTML ogenomskinliga: Target kan inte veta att en viss del av HTML innehåller JavaScript som initierar en omdirigering.
Stöder Adobe Experience Platform Web SDK omdirigeringserbjudanden för A4T? platform
Följande vanliga frågor och svar innehåller mer information om hur du använder A4T och omdirigeringserbjudanden med Platform Web SDK.
Har Analytics for Target (A4T) stöd för omdirigeringserbjudanden?
Kan jag använda anpassade omdirigeringserbjudanden/omdirigeringserbjudanden för HTML med Platform Web SDK?
Svar
Nej, du måste använda ett inbyggt omdirigeringserbjudande för aktiviteter som använder A4T. Från Target-perspektivet är erbjudandena från HTML ogenomskinliga. Target kan inte veta att en viss del av HTML innehåller JavaScript som initierar en omdirigering.
