Ik meet aankopen al via Server-Side Tagging, nu wil ik ze via webhooks gaan meten. Hoe stel ik dat in?
Ben je al vertrouwd met Server-Side Tagging voor het meten van conversies, maar wil je de nauwkeurigheid en betrouwbaarheid van je metingen verbeteren met webhooks? Dan ben je op de juiste plek.
Server-Side Tagging biedt al veel voordelen ten opzichte van client-side tracking, maar zelfs deze methode kan soms conversies missen. Webhooks bieden een krachtige aanvulling die zorgt voor vrijwel perfecte 1-op-1 metingen van je aankopen en conversies, direct vanuit de backend van je website.
In dit artikel leer je stap voor stap hoe je webhooks kunt implementeren binnenin je bestaande Server-Side Tagging setup. We behandelen de configuratie, integratie met je analyseplatformen en hoe je ervoor zorgt dat beide meetmethoden optimaal samenwerken.
Voor meer achtergrond over de werking en voordelen van webhooks voor conversie-tracking, raden we je aan ons artikel over backend-webhooks te lezen. Wil je meer weten over hoe webhooks de kanaalverdeling in Google Analytics 4 beïnvloeden? Bekijk dan ook ons artikel over het effect van webhooks op de kanaalverdeling.
Wat is de theorie achter backend-webhooks?
De AdPage backend-webhooks van Shopify, WooCommerce en Magento zijn een andere manier om een aankoop op de website te meten. Als je via een standaard Server-Side Tagging setup een aankoop meet, doe je dat doordat er een dataLayer event gepusht wordt in de browser van de gebruiker als deze op de bedankpagina van de site terecht komt. Maar als je deze aankoop via een backend-webhook meet, dan wordt er vanuit de backend van de webshop direct een signaal naar de server container verstuurd op het moment dat er een order aangemaakt wordt in die backend. De reden dat je backend-webhooks wil gebruiken komt vanwege 3 type bezoekers die aankopen op de webshop doen:
Vroegtijdige afhakers. Dit zijn bezoekers die na betaling in een betaalapp niet terugkeren naar de bedankpagina binnen de browser, maar de betaal-app direct afsluiten en niet terugkeren op de bedankpagina in de browser. Hun conversie wordt nooit geregistreerd in je analytische en marketing platformen, ondanks dat ze wel hebben gekocht. Deze gemiste aankoopogebeurtenissen kunnen aanzienlijk zijn, vooral als je veel mobiele shoppers hebt. Met webhooks worden deze aankopen alsnog correct geregistreerd omdat de conversiedata direct vanuit je CMS naar GA4 wordt gestuurd, onafhankelijk van het gedrag van de gebruiker na de betaling.
Ongeduldige kopers. Dit zijn bezoekers die de bedankpagina afsluiten voordat deze volledig is geladen en alle tracking scripts zijn geactiveerd. Ook hun aankoop blijft ongeregistreerd voor je analytische en marketing platformen als je het purchase-event client-side probeert te meten. Met de huidige verwachtingen van snelle online ervaringen, en omdat je bij iedere aankoop standaard een bevestigingsmail ontvangt, is het niet ongewoon dat gebruikers niet wachten tot een pagina volledig is geladen. Webhooks vangen deze groep op door de transactie- en gebruikersgegevens server-side te versturen, onafhankelijk van hoe lang of hoe kort een gebruiker op de bedankpagina blijft.
Browser wisselaars. Dit zijn bezoekers die hun klantreis doorlopen in bijvoorbeeld Google Chrome of de in-app browser van Facebook, maar na betaling door de betaalapp worden doorgestuurd naar de standaardbrowser volgens de apparaatinstellingen, die anders is dan de browser waarin ze winkelden. Google Analytics zal dit als twee verschillende sessies zien aangezien de client_id, session_id en session_count van de bezoeker opnieuw gegenereerd wordt, waardoor de attributie volledig verloren gaat. Zelfs wanneer je webhooks instelt op de bedankpagina, dus niet vanuit de backend van je CMS, ga je de purchase events van deze bezoekers alsnog niet kunnen attributeren.
Om de webhooks effectief te laten werken, moeten ze dezelfde gebruikers- en marketinginformatie bevatten als de rest van de klantreis die je via Server-Side Tagging meet. Hier ligt echter een uitdaging: bij een standaard Server-Side Tagging setup genereert Google automatisch drie essentiële identificatiegegevens: de client_id, session_id en session_count.
Het probleem is dat je deze drie ID's niet zomaar kunt ophalen uit de sessie van je bezoeker om ze als parameters aan je webhook toe te voegen. Dit zou echter betekenen dat je webhook-metingen en je reguliere metingen niet aan dezelfde gebruiker gekoppeld kunnen worden in GA4. De oplossing is dat je de door Google gegenereerde client_id, session_id en session_count moet overschrijven met waarden uit dezelfde bron als waar je webhook-payloads hun gegevens vandaan halen: het AdPage marketing-script.
Het goede nieuws is dat je deze drie ID's consistent kunt overschrijven gedurende de hele klantreis. Op elke pagina vindt er namelijk een 'trytagging_user_data' dataLayer event push plaats. Dit event is specifiek ontworpen om deze drie ID's te kunnen overschrijven, waardoor je een naadloze integratie tussen je Server-Side Tagging en webhook-metingen mogelijk maakt. Deze IDs kan je binnen Google Tag Manager overschrijven via de Google Tag en in onderstaande stappen zullen deze stappen toegelicht worden.
Wanneer je parameters in de Google Tag toe gaat voegen vanuit een dataLayer event push, zal je de Google Tag dus ook moeten laten triggeren op basis van deze dataLayer event push. Hierdoor komt je wellicht in de knel met andere GA4 event tags die je al voor dit dataLayer event probeert af te vuren. Je Google Tag bevat namelijk de configuratieparameters waar al je GA4 events uit de GA4 event tags zich aan moeten houden, dus je kan geen GA4 event tags af laten vuren vóór de Google Tag. Als je de trigger van je Google Tag dan gaat aanpassen van 'Initialisation' naar 'trytagging_user_data', zal je ook de triggers van alle GA4 event tags moeten controleren. Maar deze stappen zullen we in onderstaande stappenplan ook meenemen.
