Överväg att flytta leverantörstaggar på klientsidan till händelsevidarebefordran

Det finns flera goda skäl att överväga att flytta leverantörstaggar på klientsidan från webbläsare och enheter och till en server. I den här artikeln diskuterar vi hur du utvärderar en leverantörstagg på klientsidan för att kunna flytta den till en händelsevidarebefordringsegenskap.

Den här utvärderingen är bara nödvändig om du överväger att ta bort en leverantörstagg på klientsidan och ersätta den med datadistribution på serversidan i en händelsevidarebefordringsegenskap. I den här artikeln förutsätts att du är bekant med grunderna i datainsamlingoch händelsevidarebefordran.

Webbläsarleverantörer ändrar hur de hanterar cookies från tredje part. Reklamleverantörer och marknadsföringsteknologier behöver ofta använda många taggar på klientsidan. Dessa utmaningar är bara två övertygande skäl till att våra kunder lägger till datadistribution på serversidan.

Användningsexempel och data

Det första steget är att definiera de användningsfall som implementeras med leverantörstaggen på klientsidan. Ta till exempel pixeln Facebook (Meta). Flytta den från vår webbplats till Meta Conversions API med tillägget för händelsevidarebefordran innebär det att de specifika användningsfallen dokumenteras först.

För den aktuella leverantörskoden på klientsidan:

• Vilka specifika händelser och andra datapunkter visas och skickas till klientsidans tagg?
• När och var sker dataöverföringen?

Det kan vara praktiskt att göra en lista, ett kalkylblad, ett diagram eller annan post med data och händelsesekvenser för att dokumentera utvärderingen, även om det bara är till för dig. Se till att du inkluderar etiketter för datakällor - varifrån kommer det? Destinationer - vart går den? Och omvandlingar - vad händer mellan källa och mål?

I vårt exempel spårar vi konverteringar med Facebook pixel när besökarna interagerar med vår webbplats efter att ha tittat på en Facebook-annons. De kan också interagera med vår webbplats efter att ha tittat på relaterade annonser på en annan social plattform. För att kunna se dessa konverteringar i Facebook annonseringsverktyg och rapporter måste de data som behövs hämtas till Facebook. Dessa data kan omfatta konverteringshändelser som nedladdningar, registreringar, gilla-markeringar eller inköp.

Data

Vad händer med data för vår användning när den befintliga taggen på klientsidan körs eller körs på vår webbplats? Kan vi samla in de data vi behöver i klienten, utan leverantörstaggen, så att vi kan skicka dem till händelsevidarebefordran? När du använder taggar eller andra tagghanteringssystem, är de flesta data för besökarinteraktion tillgängliga för insamling och distribution. Men finns de data vi behöver för vår användning tillgängliga när vi behöver dem, där vi behöver dem och i det format vi behöver dem - utan leverantörstaggen på klientsidan? Här är några andra datafrågor att tänka på:

• Krävs det ett användar-ID för varje leverantör för varje händelse?
• Om så är fallet, hur kan de samlas in eller genereras utan klientsidestaggen?
• Kräver leverantören specifikt sin klientkod vid körning?
• Vilka andra data krävs? Var kommer dessa data ifrån?

De flesta leverantörstaggar på klientsidan kräver inte många datapunkter för ett visst användningsfall, men det kan vara bra att notera användningsexempel och obligatoriska data under utvärderingarna.

Leverantörs-API:er

Nu vet vi vilka specifika användningsfall som ska implementeras, vilka data som krävs och sekvensen av händelser från källa till mål. För att avgöra om användningsexemplet passar bra för vidarebefordran av händelser kan vi nu undersöka leverantörs-API-informationen.

Undersöker API:er

Här är några steg vi kan ta för att undersöka leverantörs-API-slutpunkter.

Har leverantören API:er som är utformade för överföring av händelsedata från server till server? Börja med att hitta kraven för dessa specifika API-slutpunkter:

• Finns API-slutpunkterna för att skicka nödvändiga data? Om du vill hitta slutpunkter som stöder dina användningsfall kan du titta i leverantörens dokumentation för utvecklare eller API.
• Tillåter de strömmande händelsedata eller endast batchdata?
• Vilka autentiseringsmetoder stöder de? Token, HTTP, OAuth client credentials version eller annan? Se här för metoder som stöds av händelsevidarebefordran.
• Vad är uppdateringsförskjutningen för deras API? Är den begränsningen kompatibel med minimumen för händelsespridning? Information här.
• Vilka data kräver de för de relevanta slutpunkterna?
• Kräver de en leverantörsspecifik användaridentifierare för varje anrop till slutpunkten?
• Om de behöver den identifieraren, var och hur kan den genereras eller hämtas, utan kod på klientsidan?

Med andra ord:

• Tillhandahåller leverantören de API-slutpunkter som krävs för våra användningsfall?
• Har de någon kompatibel autentiseringsmetod för vidarebefordran av händelser?
• Kan vi komma åt alla data som krävs för en implementering av vidarebefordran av händelser (antingen från klienten eller från andra API-anrop)?

Taggen är antagligen en bra kandidat för att gå från klienten till våra servrar i en händelsevidarebefordringsegenskap om vi kan svara ja på dessa frågor.

Om leverantören inte har API-slutpunkterna som stöd för våra användningsfall är det uppenbart att leverantörstaggen inte är en bra kandidat för att använda händelsevidarebefordran i stället för leverantörstaggen på klientsidan.

Vad händer om de har API:er, men också behöver ett unikt besökar- eller användar-ID för varje API-anrop? Hur kommer vi åt det ID:t om vi inte har leverantörens klientkod (tagg) på webbplatsen?

Vissa leverantörer förändrar sina system för den nya världen utan cookies från tredje part. Dessa ändringar inkluderar användning av alternativa unika identifierare, som en UUID eller andra kundgenererat ID. Om leverantören tillåter ett kundgenererat ID kan vi antingen skicka det från klienten till Platform Edge Network med Web eller Mobile SDK, eller eventuellt hämta det från ett API-anrop vid händelsevidarebefordran. När vi skickar data till den leverantören i en regel för vidarebefordran av händelser, tar vi bara med den identifieraren vid behov.

Om leverantören kräver data (t.ex. ett leverantörsspecifikt unikt ID) som bara kan genereras eller kommas åt av deras egen tagg på klientsidan, är det troligt att den leverantörstaggen inte är en bra kandidat att flytta. Ett försök att bakåtkompilera en tagg på klientsidan med tanken på att flytta den datainsamlingen till händelsevidarebefordran utan lämpliga API:er rekommenderas inte.

The Adobe Experience Platform Cloud Connector tillägg kan göra HTTP-begäranden efter behov med leverantörer som har rätt API:er för överföring av server-till-server-händelsedata. Även om leverantörsspecifika tillägg är bra att ha och fler tillägg håller på att utvecklas just nu, kan vi implementera regler för vidarebefordran av händelser i dag med Cloud Connector-tillägget, utan att vänta på ytterligare leverantörstillägg.

Verktyg

Det är enklare att undersöka och testa leverantörs-API-slutpunkter med verktyg som Postman, eller textredigeringstillägg som Visual Studio Code Thunder Client, eller HTTP-klient.

Nästa steg

I den här artikeln finns en serie steg för att utvärdera en leverantörs klientsidestagg och eventuellt flytta den på serversidan i en egenskap för vidarebefordring av händelser. Mer information om relaterade ämnen finns i följande länkar:

• Tagghantering i ADOBE EXPERIENCE PLATFORM
• Vidarebefordran av händelser för serverbearbetning
• Uppdateringar om terminologi datainsamling