Lad os starte med at forstå problemet.
Hvorfor er normal browser tracking ikke “tilstrækkelig”, hvis man gerne vil maksimere sin dataindsamling til GA4 og videresendelse af events til diverse annonceplatforme, som man nu engang bruger.
Der kan være mange grunde, som adblockers, consent og alle de ting vi kender, men lige i denne post handler det ikke så meget om de grunde, men om noget andet.
Selvom man har serverside tracking, så er det ikke sikkert, at man faktisk får specielt meget ekstra data ved default, da alt adfærden stadig sker, og samles op i browseren clientside, som derfra bliver sendt videre til ens server-endpoint. GA4 clientside adfærd -> server-endpoint. Ift til webhook-tracking af køb, så betyder det at vi er afhængige af at kvitteringssiden bliver vist, før et købs-event kan blive skudt afsted.
MobilePay er f eks i Danmark, en større årsag til at kvitteringssiden aldrig bliver vist, og det gør at man mister en del købs-events, som aldrig rammer serveren og aktivere downstream aktivitet. Der er sikkert mange andre ting, som også påvirker om man ser kvitteringssiden - f eks lukker folk browseren ned osv osv.
Hvordan webhook-tracking kan løse / hjælp på problemet.
Kort sagt, så er flowet med webhook-tracking således:
Kunden betaler > backend markerer orden som betalt > Backend sender webhook med relevant payload > Vores server-endpoint claimer webhook > Og vi sender det videre til platformene.
Det er meget high-level, hvad der sker.
De vigtigste fordele ved dette er at kunden aldrig behøver at lande på kvitteringssiden for at samle trackingen op, og det gør at vi kan spore lidt flere end normalt.
Webhooken kommer stadig, selvom kunden:
- Lukker browseren
- Bliver i MobilePay-appen
- Mister forbindelsen
- Stopper redirectet
- Lukker fanen for hurtigt
- Bruger en betalingsmetode med et eksternt flow
- Og hvad der ellers kan gå galt.
Du tracker den faktiske betalingsstatus
Du kan bruge orders/paid frem for blot orders/create, hvilket gør at trackingen kan blive mere præcist.
Mere konsistent produktdata
Da det kommer fra backend, er vi mindre afhængige af hvad der er i datalayeret, eller om der er fejl eller mangler - Så vi er mindre afhængige af datalayer med webhooks.
Bedre kontrol over refunds og cancellations
Webhooks åbner op for muligheder, som at spore refunds / cancellations, hvilket kan være relevant, hvis man gerne vil have det med i feks Google Ads. Det kan være du er en tøjvirksomhed, som naturligt har lidt flere refunds end andre virksomheder. Du kan derfor sende refunds til annonceplatformene, for at få et mere korrekt datagrundlag.
Nemt at skalere
Det er nemt at skalere, da vi med en webhook, kan sende denne videre til alle vores annonceplatformene - så når man først har sat det op, kører det bare hvor man har lyst.
At sende webhook alene, er dog ikke nok.
Bare at sende webhooken alene fra backend, er som regel ikke særlig brugbart, da vi kun modtager payload’en fra webhooken.
Mange annonce og analyse platformene, som GA4 og Google Ads virker kun optimalt (eller overhovedet), hvis man sender en masse GA4 browser data med i requesten. Det er jo feks cookies, consent, relevante id’er, interne parametre osv osv.
Det er derfor essentielt, at man får denne data med i webhook’en hvis det skal virke optimalt. Det kan gøres på flere måder, som kan komme i en anden post en dag.
Hvor meget ekstra data får man så med, når man bruger webhooks?
Det vil altid variere fra case til case, men jeg plejer at se et sted mellem 5-20% ekstra køb events, som vi kan sende til platformene.
En måde at tjekke på om webhook-tracking er værd at få sat op for ens forretning, er et nemt og hurtigt kig i sin backend, og hvor mange køb man har der vs hvad GA4 siger. Hvis tallet afviger meget, kan det give mening at kigge på webhooks.
Man kan også tag et kig på hvor meget mobiltrafik, ens side har. Har man meget mobiltrafik, kan det give anledning til at få sat webhooks op, da de fleste bruger MobilePay til at betale med deres mobil.
Det kan også være, at man bare har lyst til at “maxe” sit tracking ud med alt man kan - og det er også helt okay.