Tot 40% van je bezoekers blokkeert GA4. Server-side tracking geeft je datakwaliteit terug via sGTM, first-party data en Measurement Protocol. Zo pak je het aan.
E-commerce analytics voorbij Google Analytics — server-side tracking
Gemiddeld 30 tot 40 procent van je bezoekers blokkeert client-side tracking. Bij technisch publiek loopt dat op tot 60 procent. Dat betekent dat jouw GA4-data structureel onvolledig is — en dat alle beslissingen op basis van die data ook onvolledig zijn.
Server-side tracking lost dit grotendeels op. Niet als magische fix, maar als architectuurkeuze die meer controle geeft over je eigen data. In dit artikel leggen we uit waarom het werkt, hoe je het opzet en wanneer je er beter nog niet aan begint.
Waarom client-side tracking structureel faalt
De klassieke setup: een tag laadt de Google Analytics snippet in de browser van de bezoeker. Vervolgens stuurt die browser events naar Google's servers. Eenvoudig, maar kwetsbaar op drie fronten.
Wij zien bij klanten dat het verschil tussen gemeten en werkelijke conversies soms 20 tot 35 procent bedraagt. Dat is geen randgeval — dat is structurele ondermeting.
Hoe server-side tracking werkt
Bij server-side tracking verplaats je de meetlogica van de browser naar een server die jij beheert. De bezoeker stuurt events naar jouw endpoint. Jouw server verwerkt ze en stuurt ze door naar GA4, Meta, of welke tool dan ook.
Browser → jouw server-side endpoint → GA4 Measurement Protocol
→ Meta Conversions API
→ Andere destinations
Twee architecturen zijn gangbaar:
Server-side Google Tag Manager (sGTM). Je draait een Google Tag Manager container op een server. Client-side GTM stuurt events naar jouw sGTM-endpoint (doorgaans een subdomain alsgtm.jouwdomein.nl). sGTM verwerkt, verrijkt en distribueert naar destinations. Voordeel: vertrouwde GTM-interface. Nadeel: je betaalt voor de serverinfrastructuur en Google's hosted optie kost geld boven een bepaald volume.
Direct Measurement Protocol. Je stuurt events rechtstreeks vanuit je backend naar GA4 via de Measurement Protocol API. Geen extra laag, maximale controle. Nadeel: meer development effort, minder visuele interface.
Voor de meeste e-commerce setups is sGTM de pragmatische keuze.
De datalaag: de basis die alles bepaalt
Server-side tracking is zo goed als je datalaag. Een slechte datalaag geeft je een server-side slechte datalaag — sneller en betrouwbaarder afgeleverd, maar nog steeds rommel.
Een correcte e-commerce datalaag pusht gestructureerde events:
// Voorbeeld: purchase event in de datalaag
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'ORD-20240601-9821',
value: 249.95,
tax: 43.54,
shipping: 0,
currency: 'EUR',
items: [
{
item_id: 'SKU-8821',
item_name: 'Hyva Theme License',
price: 249.95,
quantity: 1
}
]
},
user_data: {
email_hash: 'sha256_gehashed_email', // voor first-party matching
customer_type: 'returning'
}
});
Kritische punten voor je datalaag:
- Push events na de server-bevestiging, niet na de klik. Zo mis je geen conversies bij snel wegklikken.
- Hanteer consistente
item_id's die matchen met je product-feed. Dit is noodzakelijk voor ROAS-rapportage. - Hashed e-mailadressen toevoegen vergroot de match rate bij Meta Conversions API significant. In de praktijk zien we match rates stijgen van 40 naar 70-80 procent.
First-party data: de echte waarde
Server-side tracking is meer dan een technische omweg om adblockers te omzeilen. Het is de infrastructuur voor first-party data.
Wat je ermee kunt doen:
- Verrijken van events. Jouw server kent de klant. Je kunt lifetime value, klantsegment, of B2B-klantgroep meesturen bij elk event. Dat is informatie die de browser nooit had.
- Deduplicatie. Als je zowel client-side als server-side meet (wat we aanraden als overgangsstrategie), moet je dedupliceren. Gebruik daarvoor een consistente
event_iddie je aan beide kanten meestuurt. - Server-side cookies zetten. Via sGTM kun je cookies instellen vanuit je server op een first-party domein. Deze cookies vallen niet onder ITP-restricties op de manier waarop client-side cookies dat wel doen.
Bij Laravel-backends is het relatief eenvoudig om purchase-events direct te dispatchen via de Measurement Protocol na een geslaagde order:
// Laravel: purchase event naar GA4 Measurement Protocol
use Illuminate\Support\Facades\Http;
class SendPurchaseToGA4
{
public function handle(OrderPlaced $event): void
{
$order = $event->order;
Http::post('https://www.google-analytics.com/mp/collect', [
'measurement_id' => config('analytics.ga4_measurement_id'),
'api_secret' => config('analytics.ga4_api_secret'),
])->withBody(json_encode([
'client_id' => $order->ga_client_id, // opgeslagen bij sessie-start
'events' => [[
'name' => 'purchase',
'params' => [
'transaction_id' => $order->number,
'value' => (float) $order->total_excl_tax,
'currency' => 'EUR',
'items' => $this->mapItems($order->items),
],
]],
]), 'application/json');
}
}
Dit geeft je server-side een 100 procent betrouwbaar purchase event, onafhankelijk van wat de browser doet.
Vergelijking: client-side vs. server-side vs. hybride
| Aspect | Client-side | Server-side | Hybride |
|---|---|---|---|
| Adblocker-resistent | Nee | Grotendeels ja | Ja |
| Implementatie-effort | Laag | Hoog | Middel |
| Data-verrijking | Beperkt | Uitgebreid | Uitgebreid |
| Kosten infrastructuur | Geen | €30–€150/mnd (sGTM) | €30–€150/mnd |
| Deduplicatie nodig | Nee | Nee | Ja |
| Realtime debug | Eenvoudig | Complexer | Complexer |
| Geschikt voor | Kleine shops | High-volume, privacy-gevoelig | Migratiefase of beide nodig |
De hybride aanpak — client-side blijft draaien, server-side stuurt de kritische conversie-events — is vaak de pragmatische keuze. Je verliest geen historische data en je voegt betrouwbaarheid toe op de events die er het meest toe doen.
De pragmatische opzet: waar te beginnen
Niet elke webshop heeft server-side tracking nodig. Begin met deze vragen:
- Hoe groot is je adblocker-gap? Vergelijk GA4-sessies met server-side sessie-data (of je eigen serverlogging). Een gap van minder dan 10 procent? Waarschijnlijk geen prioriteit.
- Wat is de waarde van één conversie? Bij hoge AOV of B2B-deals is elke gemiste conversie pijnlijk in je attributie. Bij lage marges is de ROI van de implementatie pas later zichtbaar.
- Heb je development-capaciteit? Server-side GTM instellen kost een paar dagen. Een volledige server-side datalaag met deduplicatie kost eerder twee tot vier weken. Dat is realtime, geen onderschatting.
Als je groen licht hebt, is de volgorde:
- Audit de bestaande datalaag. Zijn alle e-commerce events correct en consistent? Los dit eerst op.
- Zet sGTM op op een subdomain. Gebruik de Google Cloud Run-optie of een zelf-gehoste Docker-container voor kostenbeheer.
- Migreer de conversie-events als eerste. Purchase, add-to-cart en lead-submission zijn prioriteit één.
- Schakel Meta Conversions API in via sGTM. Dit is de snelste win voor advertentieprestaties.
- Voeg server-side purchase events toe vanuit je backend. Zo heb je twee bronnen en maximale zekerheid.
Voor Magento- en Shopify-setups zijn er kant-en-klare GTM-extensies die een goede datalaag uitsturen. Controleer altijd of de transaction_id uniek en deterministisch is — dubbele conversies in je rapportage zijn lastiger te repareren dan ondermeting.
Wanneer server-side tracking NIET de juiste keuze is
Eerlijkheid: server-side tracking is geen oplossing voor alles.
- Je hebt geen technisch team. sGTM instellen en onderhouden vereist kennis van containers, servers, en tag-configuratie. Zonder dit zit je snel met een gebroken setup die je minder data geeft dan daarvoor.
- Je conversiewaarden zijn laag. Als de gemiddelde orderwaarde €30 is en je draait 500 orders per maand, is de businesscase voor een implementatie van drie weken zwak.
- Je datalaag is een puinhoop. Server-side transport over een slechte datalaag geeft geen betere data. Begin met opschonen.
- Je verwacht privacy-magie. Server-side tracking maakt je niet automatisch AVG-compliant. Je verwerkt nog steeds persoonsgegevens. Zorg voor correcte consent-implementatie en verwerkersovereenkomsten.
Veelgestelde vragen
Maakt server-side tracking mij AVG-compliant?Nee. Server-side tracking verandert niets aan je juridische verplichtingen. Je verwerkt nog steeds gebruikersdata. Consent is nog steeds nodig voor analytics-cookies. Wat verandert: je hebt meer controle over welke data je doorstuurt en naar wie. Dat kan helpen bij data minimalisatie, maar vervangt geen DPA of cookiebanner.
Wat kost server-side GTM in de praktijk?Google's eigen hosted sGTM-optie (App Engine) kost bij lage volumes relatief weinig — reken op €20 tot €50 per maand voor een gemiddelde webshop. Zelf-hosten op Cloud Run of een VPS kan goedkoper zijn maar vereist meer beheer. Stijg je boven de 1 miljoen events per maand, dan loopt dit op.
Kan ik server-side tracking combineren met mijn bestaande GA4-setup?Ja, en dat is zelfs de aanbevolen aanpak. Gebruik de hybride strategie: client-side GTM blijft werken voor paginaviews en browse-events, server-side neemt de conversie-events over. Zorg wel voor deduplicatie via een consistente event_id.
Indirect wel. Minder third-party JavaScript in de browser betekent een lichtere pagina. Dat kan je Core Web Vitals positief beïnvloeden. Geen directe ranking-factor, maar een snellere pagina converteert beter — en dat is al het argument.
Wil je weten of server-side tracking de juiste stap is voor jouw e-commerce setup? We kijken graag mee naar je huidige analytics-architectuur. Neem contact op — geen verkooppraatje, gewoon een technisch gesprek.

Geschreven door Ruthger Idema
15+ jaar ervaring in e-commerce development. Gespecialiseerd in Magento, Shopify en Laravel maatwerk.
Meer over ons team →