Ik meet Shopify 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.
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.
Open je GTM web container
Open je Google Tag met de server-side configuratie parameters
Als het goed is, ziet die Google Tag er ongeveer zo uit (je kan andere optionele parameters hebben of andere benamingen gebruiken):
Voeg hier een nieuwe parameter toe. De naam van de parameter is "x_client_id".
Als waarde voor deze nieuwe parameter klik je op het lego-blokje met het plusje om een nieuwe variabele aan te maken. Klik hier op het blauwe plusje rechtsboven.
Als variabele configuratie kies je voor Data Layer Variable. Als Data Layer Variable Name vul je "marketing.client_id" in. Geef de variabele een duidelijke naam en sla deze op.
Voeg nog een nieuwe parameter toe. De naam van de parameter is "x_session_id".
Als waarde voor deze nieuwe parameter klik je op het lego-blokje met het plusje om een nieuwe variabele aan te maken. Klik hier op het blauwe plusje rechtsboven.
Als variabele configuratie kies je voor Data Layer Variable. Als Data Layer Variable Name vul je "marketing.session_id" in. Geef de variabele een duidelijke naam en sla deze op.
Voeg nog een nieuwe parameter toe. De naam van de parameter is "x_session_count".
Als waarde voor deze nieuwe parameter klik je op het lego-blokje met het plusje om een nieuwe variabele aan te maken. Klik hier op het blauwe plusje rechtsboven.
Als variabele configuratie kies je voor Data Layer Variable. Als Data Layer Variable Name vul je "marketing.session_count" in. Geef de variabele een duidelijke naam en sla deze op.
Nu ziet je Google Tag, als het goed is, er zo uit (het kan zijn dat je andere benamingen voor je variabelen gebruikt hebt):
Nu gaan we de trigger aanpassen. Verwijder je 'Initialization' trigger.
Voeg een nieuwe trigger toe. Heb je al een 'user_data' of 'trytagging_user_data' trigger, selecteer die dan uit de lijst van triggers. Anders mag je een nieuwe trigger aanmaken, Custom Event als type trigger kiezen en "trytagging_user_data" als Event Name invullen.
Nu ziet je Google Tag, als het goed is, er zo uit (het kan zijn dat jouw trigger een andere naam heeft):
Sla de Google Tag op.
Check in het overzicht van je Tags op de GTM web container of je GA4 event tags hebt met een van de volgende trigger-iconen:
In het geval van onderstaande screenshot is er dus één tag die geactiveerd zou worden vóór de Google Tag en dus niet naar de server container verstuurd zou worden:
Je kan een trigger die voor de Google Tag afgevuurd wordt op twee manieren vervangen:
Je kan een trigger vervangen door een 'trytagging_user_data' trigger. In het geval van een page_view tag, of bij een gebeurtenistag die je op een specifieke bedankpagina laat triggeren, kan je de trigger het beste vervangen met een Custom Event trigger met de Event Name "trytagging_generate_lead". Dus op één van de onderstaande twee manieren:
Ook kan je een triggergroep gebruiken. Een triggergroep evalueert de condities van twee of meer triggers als één trigger. De triggergroep activeert pas nadat alle geselecteerde triggers minstens één keer zijn geactiveerd. Dus als je in de trigger je bestaande trigger én de 'trytagging_user_data' trigger toevoegt, wordt de triggergroep pas geactiveerd als beide triggers plaatsgevonden hebben.
Als je een trigger van een GA4 event tag aanpast, moet je ook goed checken of je deduplicatie van o.a. Facebook, TikTok of Pinterest nu nog wel goed loopt. Als je namelijk de trigger van je GA4 page_view tag aanpast, maar niet die van je Facebook Pixel PageView tag ga je twee verschillende event_IDs genereren waardoor Meta Ads dubbele page_views gaat meten. Als je dus een trigger aanpast van een GA4 event tag die gededupliceerd moet worden, zal je diezelfde trigger van je marketing platform ook moeten vervangen met de nieuwe trigger.
Onderstaande voorbeeld mag dus niet voorkomen in jouw GTM web container:
Open je GTM server container
Ga naar je Tags toe
Selecteer je GA4 tag en verwijder deze
Ga naar 'Beheer' bovenin het menu
Klik op 'Container importeren'
Download dit JSON-bestand: GA4 Webhooks Server Container
Bij het importeren van een container moet je een container file selecteren, selecteer dit gedownloade JSON-bestand
Kies je bestaande Werkruimte
Selecteer de optie 'Samenvoegen'
Selecteer de optie om conflicterende clients, tags, transformaties, triggers en variabelen te hernoemen
Klik onderaan op de 'toevoegen aan werkruimte' knop.
Je hebt nu naast de GA4 client ook een AdPage Webhook client in je GTM server container.
Ook heb je nu 2 nieuwe tags aan je werkruimte toegevoegd, een GA4 events tag en een GA4 purchase tag.
Open je variabelen in je GTM server container.
Zie je een nieuwe variabele genaamd "@ GA4 ID_import_1"? Zorg er dan voor dat je de twee nieuwe GA4 tags opent en de variabele voor het Measurement ID vervangt van {{@ GA4 ID_import_1}} naar {{@ GA4 ID}}.
Zie je een nieuwe variabele genaamd "@ GA4 ID"? Open deze variabele dan en vul het GA4 Measurement-ID in.
Open de server container binnen het AdPage trytagging-platform.
Ga naar de Webhook Logs
Op de Trytagging-omgeving heb je de mogelijkheid om de payload van alle ontvangen Webhooks te bekijken. Dat doe je in de Webhook Logs. Daar kan je van alle ontvangen webhooks zien welke transactie-ID deze hebben en op welke dag en tijdstip deze ontvangen zijn door je server container. Daarnaast kan je via de Acties de webhook openen om de payload te bekijken, of de Webhook opnieuw af laten spelen in je sGTM container preview mode.
Om een Webhook Replay uit te voeren klik je op onderstaande knop van een specifieke webhook. Er opent dan een popup waarin je de preview header toe moet voegen.
Open je GTM server container in de preview mode
Rechtsboven klik je op de 3 puntjes en klik je op 'Send requests manually'.
Kopieer de 'x-gtm-server-preview HTTP header' en plak deze in het invoerveld binnen de Webhook Replay popup.
Klik in Trytagging op de 'Replay' knop en de Webhook wordt opnieuw afgespeeld in je sGTM preview mode.
Binnen de GTM server container preview mode komt er nu als het goed is een webhook binnen, deze wordt verwerkt door de AdPage Webhook Client en laat de GA4 purchase tag afvuren. Dat hoort er op deze manier uit te zien:
Zie je bovenstaande screenshot niet? Zie je andere/extra tags afgevuurd worden of helemaal geen tags afgevuurd worden? Dan heb je ergens in bovenstaande stappen een fout gemaakt.
Als alles goed verlopen is in de test via de preview mode, kan je beide GTM containers publiceren.
Houdt wel in de gaten dat een cookiebanner roet in het eten kan gooien, dus na het publiceren moet je de week erna constant checken of het aantal purchase events in GA4 overeenkomt met wat je in de backend van de webshop ziet en of de purchase events toegeschreven worden aan bepaalde kanaalgroepen. Als alle purchase events toegeschreven worden aan Unassigned, dan zal je even in contact moeten komen met support@adpage.io zodat wij mee kunnen kijken met je setup en de setup van de CMP (cookiebanner).
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.
Hoe stel je Webhooks in voor een bestaande Server-Side Tagging setup?
De Google Tag aanpassen
Open je GTM web container
Open je Google Tag met de server-side configuratie parameters
Als het goed is, ziet die Google Tag er ongeveer zo uit (je kan andere optionele parameters hebben of andere benamingen gebruiken):
Voeg hier een nieuwe parameter toe. De naam van de parameter is "x_client_id".
Als waarde voor deze nieuwe parameter klik je op het lego-blokje met het plusje om een nieuwe variabele aan te maken. Klik hier op het blauwe plusje rechtsboven.
Als variabele configuratie kies je voor Data Layer Variable. Als Data Layer Variable Name vul je "marketing.client_id" in. Geef de variabele een duidelijke naam en sla deze op.
Voeg nog een nieuwe parameter toe. De naam van de parameter is "x_session_id".
Als waarde voor deze nieuwe parameter klik je op het lego-blokje met het plusje om een nieuwe variabele aan te maken. Klik hier op het blauwe plusje rechtsboven.
Als variabele configuratie kies je voor Data Layer Variable. Als Data Layer Variable Name vul je "marketing.session_id" in. Geef de variabele een duidelijke naam en sla deze op.
Voeg nog een nieuwe parameter toe. De naam van de parameter is "x_session_count".
Als waarde voor deze nieuwe parameter klik je op het lego-blokje met het plusje om een nieuwe variabele aan te maken. Klik hier op het blauwe plusje rechtsboven.
Als variabele configuratie kies je voor Data Layer Variable. Als Data Layer Variable Name vul je "marketing.session_count" in. Geef de variabele een duidelijke naam en sla deze op.
Nu ziet je Google Tag, als het goed is, er zo uit (het kan zijn dat je andere benamingen voor je variabelen gebruikt hebt):
Nu gaan we de trigger aanpassen. Verwijder je 'Initialization' trigger.
Voeg een nieuwe trigger toe. Heb je al een 'user_data' of 'trytagging_user_data' trigger, selecteer die dan uit de lijst van triggers. Anders mag je een nieuwe trigger aanmaken, Custom Event als type trigger kiezen en "trytagging_user_data" als Event Name invullen.
Nu ziet je Google Tag, als het goed is, er zo uit (het kan zijn dat jouw trigger een andere naam heeft):
Sla de Google Tag op.
De trigger volgorde van GA4 event tags checken
Check in het overzicht van je Tags op de GTM web container of je GA4 event tags hebt met een van de volgende trigger-iconen:
In het geval van onderstaande screenshot is er dus één tag die geactiveerd zou worden vóór de Google Tag en dus niet naar de server container verstuurd zou worden:
Je kan een trigger die voor de Google Tag afgevuurd wordt op twee manieren vervangen:
Je kan een trigger vervangen door een 'trytagging_user_data' trigger. In het geval van een page_view tag, of bij een gebeurtenistag die je op een specifieke bedankpagina laat triggeren, kan je de trigger het beste vervangen met een Custom Event trigger met de Event Name "trytagging_generate_lead". Dus op één van de onderstaande twee manieren:
Ook kan je een triggergroep gebruiken. Een triggergroep evalueert de condities van twee of meer triggers als één trigger. De triggergroep activeert pas nadat alle geselecteerde triggers minstens één keer zijn geactiveerd. Dus als je in de trigger je bestaande trigger én de 'trytagging_user_data' trigger toevoegt, wordt de triggergroep pas geactiveerd als beide triggers plaatsgevonden hebben.
Als je een trigger van een GA4 event tag aanpast, moet je ook goed checken of je deduplicatie van o.a. Facebook, TikTok of Pinterest nu nog wel goed loopt. Als je namelijk de trigger van je GA4 page_view tag aanpast, maar niet die van je Facebook Pixel PageView tag ga je twee verschillende event_IDs genereren waardoor Meta Ads dubbele page_views gaat meten. Als je dus een trigger aanpast van een GA4 event tag die gededupliceerd moet worden, zal je diezelfde trigger van je marketing platform ook moeten vervangen met de nieuwe trigger.
Onderstaande voorbeeld mag dus niet voorkomen in jouw GTM web container:
De Webhook Client en GA4 purchase tag op de server container instellen
Open je GTM server container
Ga naar je Tags toe
Selecteer je GA4 tag en verwijder deze
Ga naar 'Beheer' bovenin het menu
Klik op 'Container importeren'
Download dit JSON-bestand: GA4 Webhooks Server Container
Bij het importeren van een container moet je een container file selecteren, selecteer dit gedownloade JSON-bestand
Kies je bestaande Werkruimte
Selecteer de optie 'Samenvoegen'
Selecteer de optie om conflicterende clients, tags, transformaties, triggers en variabelen te hernoemen
Klik onderaan op de 'toevoegen aan werkruimte' knop.
Je hebt nu naast de GA4 client ook een AdPage Webhook client in je GTM server container.
Ook heb je nu 2 nieuwe tags aan je werkruimte toegevoegd, een GA4 events tag en een GA4 purchase tag.
Open je variabelen in je GTM server container.
Zie je een nieuwe variabele genaamd "@ GA4 ID_import_1"? Zorg er dan voor dat je de twee nieuwe GA4 tags opent en de variabele voor het Measurement ID vervangt van {{@ GA4 ID_import_1}} naar {{@ GA4 ID}}.
Zie je een nieuwe variabele genaamd "@ GA4 ID"? Open deze variabele dan en vul het GA4 Measurement-ID in.
Webhooks testen
Open de server container binnen het AdPage trytagging-platform.
Ga naar de Webhook Logs
Op de Trytagging-omgeving heb je de mogelijkheid om de payload van alle ontvangen Webhooks te bekijken. Dat doe je in de Webhook Logs. Daar kan je van alle ontvangen webhooks zien welke transactie-ID deze hebben en op welke dag en tijdstip deze ontvangen zijn door je server container. Daarnaast kan je via de Acties de webhook openen om de payload te bekijken, of de Webhook opnieuw af laten spelen in je sGTM container preview mode.
Om een Webhook Replay uit te voeren klik je op onderstaande knop van een specifieke webhook. Er opent dan een popup waarin je de preview header toe moet voegen.
Open je GTM server container in de preview mode
Rechtsboven klik je op de 3 puntjes en klik je op 'Send requests manually'.
Kopieer de 'x-gtm-server-preview HTTP header' en plak deze in het invoerveld binnen de Webhook Replay popup.
Klik in Trytagging op de 'Replay' knop en de Webhook wordt opnieuw afgespeeld in je sGTM preview mode.
Binnen de GTM server container preview mode komt er nu als het goed is een webhook binnen, deze wordt verwerkt door de AdPage Webhook Client en laat de GA4 purchase tag afvuren. Dat hoort er op deze manier uit te zien:
Zie je bovenstaande screenshot niet? Zie je andere/extra tags afgevuurd worden of helemaal geen tags afgevuurd worden? Dan heb je ergens in bovenstaande stappen een fout gemaakt.
Publiceren
Als alles goed verlopen is in de test via de preview mode, kan je beide GTM containers publiceren.
Houdt wel in de gaten dat een cookiebanner roet in het eten kan gooien, dus na het publiceren moet je de week erna constant checken of het aantal purchase events in GA4 overeenkomt met wat je in de backend van de webshop ziet en of de purchase events toegeschreven worden aan bepaalde kanaalgroepen. Als alle purchase events toegeschreven worden aan Unassigned, dan zal je even in contact moeten komen met support@adpage.io zodat wij mee kunnen kijken met je setup en de setup van de CMP (cookiebanner).
Bijgewerkt op: 21/05/2025
Dankuwel!