Hier is een situatie die ik in bijna elke winkel zie waar ik mee werk: de winkelbeheerder toont 100 bestellingen voor de week, Google Analytics 4 toont 70, Google Ads rapporteert 60 conversies en Meta rapporteert weer een ander aantal.
Een klein verschil is normaal. Maar grote verschillen betekenen dat je advertentieplatforms optimaliseren op onvolledige gegevens, en dat je budgetbeslissingen in het duister neemt. Deze gids legt uit waarom dit gebeurt en hoe je de kloof kunt dichten.
Verwacht enige verschillen, maar niet te veel
Analytics zullen nooit exact overeenkomen met uw orderdatabase. Redenen die normaal en onvermijdelijk zijn:
- Bezoekers die cookies weigeren (afhankelijk van uw toestemmingsinstelling)
- Advertentieblokkers en privacygerichte browsers
- Verschillende attributiemodellen tussen platforms
- Tijdzone- en rapportagedatumverschillen
Wat niet normaal is: gemiste aankopen door een gebroken implementatie. Dat is wat we als eerste oplossen.
Veelvoorkomende oorzaken van ontbrekende GA4-aankopen
1. De aankoopgebeurtenis hangt af van de bedankpagina
Als het purchase evenement alleen wordt geactiveerd wanneer de bedankpagina laadt, verlies je elke bestelling waarbij de klant het tabblad sluit na betaling, of waarbij een externe betalingsprovider (PayPal, iDEAL, Klarna, bankomleidingen) hen niet terugstuurt.
2. Dubbele of ontbrekende transactie-ID’s
Zonder een unieke transaction_id veroorzaken herlaadacties duplicaten. Met verkeerde ID’s kun je GA4 niet reconciliëren met je winkel.
3. Gebroken datalaag na een thema- of checkoutwijziging
Een nieuwe checkout, thema-update of one-step checkout-plugin breekt vaak de datalaag stilletjes.
4. Toestemmingsmodus niet correct ingesteld
In de EEA vereist Google Consent Mode v2-signalen voor zijn advertentiefuncties. Als je cookiebanner en tags niet correct zijn aangesloten, kunnen tags helemaal niet worden geactiveerd, of worden ze geactiveerd zonder de juiste toestemming, wat een juridisch risico met zich meebrengt.
5. Cross-domain problemen
Als de checkout of betaling op een ander domein plaatsvindt, worden sessies verbroken en worden conversies toegeschreven aan “verwijzing” van de betalingsprovider. Voeg betalingsproviders toe aan de lijst met uitsluitingen voor verwijzingen (ongewenste verwijzingen) en stel cross-domein metingen in waar nodig.
Stap 1: Controleer de huidige opstelling
- Vergelijk bestellingen in uw winkel met GA4 aankopen per dag voor de laatste 30 dagen
- Verdeel de kloof per betaalmethode en apparaat. Een kloof die alleen bij één betaalmethode verschijnt, wijst op een omleidingsprobleem.
- Controleer de datalaag op de bestelbevestigingspagina met GTM Preview of de browserconsole
- Controleer het toestemmingsgedrag: wat wordt er geactiveerd voordat en nadat de bezoeker accepteert?
Stap 2: Los de basisprincipes aan de clientzijde op
- Stuur een complete
purchasegebeurtenis mettransaction_id,value,currency,tax,shippingenitems - Zorg ervoor dat het evenement slechts één keer per bestelling wordt geactiveerd.
- Implementeer Consent Mode v2 correct met uw toestemmingsbeheerplatform
- Exclusief betaalprovider-domeinen als verwijzingen
Deze oplossingen alleen sluiten vaak een groot deel van de kloof.
Stap 3: Voeg server-side tagging toe
Met server-side Google Tag Manager verzendt de browser gegevens naar je eigen taggingserver (bijvoorbeeld metrics.yourstore.com) in plaats van rechtstreeks naar Google, Meta en anderen. De server stuurt de gegevens vervolgens door naar elk platform.
Voordelen:
- Meer controle over gegevens: u beslist wat naar elke leverancier wordt gestuurd en kunt persoonlijke gegevens verwijderen
- Minder scripts in de browser: betere paginasnelheid en INP
- Duurzamere meting: de first-party setup wordt minder beïnvloed door bepaalde browserbeperkingen
- Server-naar-server conversies: je kunt aankopen vanuit je backend verzenden, zodat bestellingen meetellen, zelfs als de klant nooit terugkeert naar de bedankpagina
Belangrijk: server-side tagging verwijdert de noodzaak voor toestemming niet. Het is een technische verbetering, geen manier om privacywetgeving te omzeilen. Respecteer ook de keuze van de gebruiker in de servercontainer.
Stap 4: Stuur aankopen vanuit de backend
De meest betrouwbare setup verzendt het aankoop evenement wanneer de bestelling daadwerkelijk is aangemaakt of betaald, vanuit de backend van je winkel:
- GA4 Meetprotocol voor analytics
- Google Ads offline of verbeterde conversies voor advertenties
- Meta Conversies API voor Meta
Gebruik dezelfde gebeurtenis-ID in browser- en servergebeurtenissen, zodat platforms ze kunnen dedupliceren.
Stap 5: Continu monitoren
Tracking breaks stilletjes. Stel een eenvoudige dagelijkse controle in die winkelbestellingen vergelijkt met GA4-aankopen en je waarschuwt wanneer de kloof boven een afgesproken drempel komt. Dit is eenvoudig te automatiseren met een kleine workflow (zie mijn n8n vs Zapier vs Make vergelijking).
Veelgestelde vragen
Hoe groot is een acceptabele kloof?
Het hangt af van je publiek en toestemmingspercentages. Belangrijker dan één cijfer is dat de kloof stabiel en verklaarbaar is. Plotselinge veranderingen betekenen altijd dat er iets kapot is.
Is server-side tracking duur?
Je betaalt voor het hosten van de taggingserver, wat voor de meeste winkels bescheiden is in vergelijking met de advertentie-uitgaven. De grotere kosten zijn het correct instellen ervan.
Helpt server-side tracking de prestaties van Google Ads?
Betere conversiegegevens helpen over het algemeen geautomatiseerd bieden betere beslissingen te nemen, omdat het algoritme leert van meer complete en nauwkeurige signalen.
Wil je tracking waarop je kunt vertrouwen?
Ik controleer en herbouw e-commerce tracking: GA4, Google Ads, Meta, Consent Mode v2 en server-side tagging. Bekijk mijn technische SEO en meetdienst en digitale marketingdienst, of vraag een tracking audit aan.