Ö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 du känna till grunderna för datainsamling och vidarebefordran av händelser.

Webbläsarleverantörer ändrar hur de hanterar cookies från tredje part. Advertising och marknadsföringsleverantörer och marknadsföringsteknologier kräver ofta användning av 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 use-cases-data

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

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

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 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 besökarinteraktionsdata 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å:

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 vendor-apis

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 investigate-apis

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:

Med andra ord:

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 ett UID eller annat 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. Försök att bakåtkompilera en klientsidestagg med tanken att flytta den datainsamlingen till händelsevidarebefordran utan lämpliga API:er rekommenderas inte.

Tillägget Adobe Experience Platform Cloud Connector kan göra HTTP-begäranden vid behov med leverantörer som har rätt API:er för överföring av händelsedata från server till server. Ä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 tools

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 Client.

Nästa steg next-steps

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: