Wat is een Webhook? (webhooks)

Wat zijn Webhooks voor Serverside Tagging?

Webhooks zijn een krachtig mechanisme dat wordt gebruikt in de context van Serverside Tagging om real-time communicatie mogelijk te maken tussen verschillende systemen en applicaties. Met behulp van Webhooks kunnen servers automatisch berichten sturen naar andere systemen wanneer bepaalde gebeurtenissen plaatsvinden, waardoor informatie direct en efficiënt kan worden uitgewisseld.

Hoe werken Webhooks in Serverside Tagging?

In het geval van Serverside Tagging worden Webhooks vaak gebruikt om belangrijke gebeurtenissen zoals aankopen en refunds van gebruikers op een website te detecteren en door te sturen naar een externe tracking- of analytics-tool. Wanneer een gebeurtenis plaatsvindt, genereert de server een HTTP-verzoek met relevante gegevens en verzendt deze naar de vooraf geconfigureerde URL van de externe tool via een Webhook.

Voordelen van het gebruik van Webhooks voor Serverside Tagging

1. Real-time tracking: Webhooks zorgen voor directe en real-time overdracht van gegevens, waardoor tracking en analyse van gebruikersinteracties onmiddellijk kunnen plaatsvinden.

2. Schaalbaarheid: Door gebruik te maken van Webhooks kunnen servers gemakkelijk en efficiënt communiceren met verschillende tools en systemen, waardoor de schaalbaarheid van het trackingproces wordt verbeterd.

3. Minder afhankelijkheid van de client-side: Serverside Tagging met behulp van Webhooks vermindert de afhankelijkheid van de client-side implementatie, waardoor tracking-consistentie en nauwkeurigheid worden gegarandeerd, zelfs bij complexe websites of applicaties.

4. **Webhooks kunnen ook worden gestuurd vanuit externe systemen zoals een kassasysteem (offline) of fullfilment, waardoor ze een flexibele en veelzijdige manier bieden om real-time informatie en gegevens te delen tussen verschillende applicaties en platforms.

5. **Webhooks kunnen zorgen voor 1-op-1 meting in GA4 en analytische tools. Mocht de conversie niet te herleiden zijn omdat er bijvoorbeeld geen client id is meegestuurd dan is deze unassigned. Het is daarom belangrijk om de DataLayer parameters altijd toe te voegen aan het Webhook event.

De webhooks worden ontvangen in de Google Tag Manager Serverside container en kunnen dan worden doorgestuurd naar platformen zoals GA4, Google Ads, Meta Ads, en nog veel meer.

Wil je een begin maken met Webhooks? Dan kun je een van de onderstaande artikelen volgen voor verschillende Shop systemen of je kunt er voor kiezen om het maatwerk te installeren:

WooCommerce & Wordpress: Purchase webhooks instellen

Magento: Purchase webhooks instellen

Shopify: Purchase webhooks instellen

Maatwerk: AdPage Pixel + DataLayer + Webhooks instellen

Veelgestelde vragen en verduidelijking

Waarom wordt er een eigen Client ID en Session ID aangemaakt?

Vraag: Bij jullie implementatie wordt er een eigen Client ID en Session ID aangemaakt, waarmee de standaard Client ID en Session ID worden overschreven. Kunnen jullie toelichten waarom dit op deze manier is ingericht?

Antwoord: Wij kunnen de IDs van Google niet ophalen en met de webhook payloads opsturen. Omdat webhooks server-to-server communicatie zijn (zonder browser context), hebben we geen toegang tot de originele Google Analytics Client ID en Session ID die normaal in de browser worden gegenereerd. Daarom creëren we onze eigen consistente identificatiestructuur die:

• Een unieke user tracking mogelijk maakt over verschillende sessies
• Sessie-informatie bewaart die anders verloren zou gaan bij webhook events
• Zorgt voor data continuïteit tussen website events en webhook purchase events

Waarom worden x-ga-gcd en x-ga-gcs parameters overschreven?

Vraag: Ik zie dat de waarden voor x-ga-gcd en x-ga-gcs eveneens worden overschreven. Wat is hiervoor de precieze reden?

Antwoord: Deze parameters worden overschreven zodat GA4 de webhook events accepteert, ook van gebruikers die geen consent hebben gegeven. Hier is waarom:

Het probleem: Wanneer gebruikers geen tracking consent geven, weigert GA4 normaal gesproken hun purchase events te accepteren. Dit resulteert in:

• Incomplete revenue data in GA4
• Gemiste conversie tracking
• Onnauwkeurige ROI berekeningen

Onze oplossing: Door de consent parameters (x-ga-gcd en x-ga-gcs) te overschrijven, zorgen we ervoor dat:

• 100% van je aankopen meetbaar worden in GA4
• Revenue data compleet blijft, ongeacht consent status
• Je alsnog accurate business metrics hebt

Belangrijke nuances:

• We implementeren dit in GTM (niet direct in de server container) zodat klanten zelf kunnen kiezen
• Klanten die consent-weigerende aankopen NIET in GA4 willen zien, kunnen deze Lookup table variabele eenvoudig verwijderen
• Het enige wat verloren gaat bij consent-weigerende users is de koppeling aan specifieke gebruikerssessies, maar de purchase data zelf blijft behouden

Privacy overwegingen:

• Deze aanpak zorgt voor volledige revenue tracking zonder extra privacy-gevoelige data te verzamelen
• De purchase events van consent-weigerende gebruikers zijn niet koppelbaar aan hun browsing gedrag
• Klanten behouden volledige controle over of ze deze functionaliteit willen gebruiken

Deze implementatie biedt de perfecte balans tussen compliance met privacy regelgeving en het behouden van accurate business intelligence data.

Bijgewerkt op: 14/09/2025