GA4 troubleshooting-gids: de 4 meest voorkomende data-discrepanties (2026)

Vier discrepanties komen in vrijwel elke GA4-account terug die een bureau beheert: cijfers die niet matchen met Google Ads, (not set)-waarden die je rapporten vervuilen, dubbele transacties die de omzet opblazen, en je eigen of een betaaldomein dat als referral binnenkomt. Drie ervan zijn sluipfouten — ze breken stil, zonder foutmelding, en je ziet het pas als de klant ernaar vraagt.

De eerste is geen fout. GA4 en Google Ads matchen structureel nooit 1:1, omdat ze conversies anders crediteren, andere vensters hanteren en in een ander moment boeken. Dat moet je begrijpen en documenteren, niet 'oplossen'. De andere drie zijn wel oplosbaar — maar pas als je weet welke van de meerdere mogelijke oorzaken in jouw setup speelt.

Deze gids behandelt elk probleem op operator-niveau: symptoom, de oorzaken (meestal meerdere), en een fix die je vandaag in GTM of de GA4-admin kunt uitvoeren. Verifieerbaar in GTM Preview en DebugView, niet op gevoel.

GA4 vs Google Ads: de cijfers matchen nooit 1:1 (en dat is normaal)

Symptoom: de klant legt het Ads-conversierapport naast het GA4-key-eventsrapport en de cijfers wijken af — soms 10%, soms 40%. De reflex is 'er zit een bug in de tracking'. In de meeste gevallen is dat niet zo. Dit is een structureel verschil tussen twee systemen die conversies fundamenteel anders behandelen. Je doel is niet een absolute match, maar een stabiele, verklaarbare delta.

De oorzaken stapelen op, en meestal spelen er meerdere tegelijk. Attributiemodel: Google Ads crediteert standaard op de ad-interactie, terwijl GA4 voor key events een eigen reporting-attributiemodel gebruikt (standaard data-driven, of paid/organic last click). Een conversie die in Ads als '1' telt, kan in GA4 fractioneel (bijvoorbeeld 0,3) of aan een ander kanaal toegewezen zijn omdat ook organic, e-mail of direct de journey raakten. Sinds de 'key events vs conversions'-update van 2024 zijn de definities deels uitgelijnd, maar het reporting-attributiemodel blijft per platform verschillen.

Conversie-datum: Ads boekt een conversie terug op de datum van de ad-klik (click date), GA4 op de datum waarop het event plaatsvond (event date). Klik op maandag, aankoop op donderdag: in Ads valt de conversie op maandag, in GA4 op donderdag. Op dag- en weekniveau loopt dat altijd uiteen, zeker bij langere overwegingsperiodes. Vensters: GA4 hanteert voor acquisitie-key-events standaard 30 dagen lookback en voor overige key events standaard 90 dagen (instelbaar in Attribution settings); Ads gebruikt een apart, per-conversieactie instelbaar conversievenster (vaak 30 dagen voor click-through). Verschillende vensterlengtes verklaren vaak een groot deel van de delta.

Tel-methode: triggert een gebruiker na één klik twee keer hetzelfde key event, dan telt GA4 dat als 2. Bij import naar Ads bepaalt de 'Count'-instelling het resultaat — 'One' rapporteert 1, 'Every' rapporteert 2. Verwerkingstijd en tijdzone: data-overdracht tussen GA4 en Ads kan tot 48 uur duren, en een afwijkende tijdzone tussen property en account laat dezelfde conversie op een andere kalenderdag vallen. Tot slot modeled conversions: bij geweigerde consent kan Ads gaten opvullen met modellering, terwijl GA4 primair observeerde events rapporteert met beperktere modellering. In high-rejection markten (Consent Mode v2) ligt Ads daardoor vaak structureel hoger — dat is modellering, geen meetfout.

De fix is deels mindset, deels configuratie. Behandel dit als structureel en vergelijk appels met appels. Zet in GA4 onder Admin > Attribution settings het reporting-model expliciet (bijvoorbeeld 'Paid and organic last click' als je dichter bij de Ads-last-click-logica wilt). Importeer waar mogelijk GA4-key-events als Ads-conversies zodat beide systemen dezelfde event-definitie delen. Stem de vensters bewust af: zet de GA4-lookback-windows en het Ads-conversievenster op vergelijkbare lengtes. Controleer per conversieactie de Count-instelling ('Every' voor aankopen, 'One' voor leads). Zorg dat de tijdzone van de property exact gelijk is aan die van het Ads-account, en trek pas conclusies na minimaal 48 uur verwerking over een afgesloten periode — nooit op dag-niveau, nooit op verse dagen. Implementeer Consent Mode v2 correct zodat beide platforms consistente signalen krijgen. Leg vervolgens voor de klant vast dat een vast deltapercentage normaal is, en monitor de delta in de tijd in plaats van een absolute match na te jagen.

Attributiemodel verschilt: Ads = ad-interactie, GA4 = eigen reporting-model (data-driven of last click).
Click-date (Ads) vs event-date (GA4): vergelijk nooit op dag-niveau, altijd over een afgesloten ruime periode.
Vensters: GA4 30/90 dagen vs Ads-conversievenster (vaak 30) — stem ze bewust op elkaar af in Attribution settings.
Count 'One' vs 'Every' per conversieactie: zet 'Every' voor aankopen, 'One' voor leads.
Tijdzone GA4-property = Ads-account, en wacht minimaal 48u verwerking voor je conclusies trekt.
Bij data-driven attributie kunnen conversies tot 7 dagen herattribueerd worden — wacht tot de data is uitgehard.
Modeled conversions verklaren vaak een hogere Ads-telling in high-rejection markten; monitor de consent-acceptatiegraad apart.

Symptoom, oorzaak, eerste fix.

Symptoom	Meest waarschijnlijke oorzaak	Eerste fix
GA4- en Ads-conversies matchen niet 1:1	Verschillend attributiemodel + click-date vs event-date + andere vensters	Vergelijk over afgesloten periode; stem vensters af in Attribution settings; documenteer de delta
Ads telt hoger dan GA4 in NL/EU	Modeled conversions bij geweigerde consent (Consent Mode v2)	Consent Mode v2 correct implementeren; consent-acceptatiegraad apart monitoren
(not set) in Landing page	Sessie zonder page_view-event	Google-tag op Initialization-trigger; event-tags pas daarná; SPA page_view per history-change
(not set) in Source/medium of campaign	Ontbrekend session_start of incomplete UTM (alleen utm_campaign)	Initialization-trigger + altijd utm_source ÉN utm_medium taggen
(other) in rapport (geen (not set))	High cardinality (>500 waarden/dag) of rijlimiet/thresholding	Cardinaliteit verlagen; exploraties gebruiken of BigQuery koppelen
Purchase telt dubbel / omzet te hoog	Refresh bedankpagina, lege/ontbrekende transaction_id, of dubbele bron	Unieke niet-lege transaction_id + frontend-guard (cookie/localStorage); liefst server-side op order-status
Eigen (sub)domein als referral	Ontbrekende cross-domain measurement (_gl)	Configure your domains + Google-tag op alle domeinen + consistent cookie-domain
Betaaldomein (Mollie/Stripe/iDEAL) als referral	Payment-redirect zonder referral-exclusion (_gl werkt hier niet)	Domein toevoegen aan 'List unwanted referrals' met match type 'Domein bevat'

(not set): vier contexten, vier verschillende oorzaken

Symptoom: in een dimensie zie je een (not set)-rij — soms in Landing page, soms in Session source/medium of campaign, soms in een custom dimension. De fout is om (not set) als één probleem te zien. Het is een symptoom met per context een andere oorzaak, en je moet eerst bepalen welke dimensie het betreft voordat je iets aanpast.

(not set) in Landing page betekent: de sessie bevat geen page_view-event. Dat gebeurt als een sessie start op een ander event (bijvoorbeeld een ge-queued event dat vuurt vóór de page_view), bij timed-out sessies die hervatten zonder nieuwe page_view, of bij SPA's waar de eerste page_view niet correct triggert. (not set) in Session source/medium en campaign betekent: het session_start-event ontbreekt. Google noemt als hoofdoorzaak een verkeerd geconfigureerde trigger in Tag Manager — de Google-tag moet op Initialization vuren, niet later. Aanvullend: ontbrekende of foutieve UTM-tagging, want zonder utm_source én utm_medium (utm_campaign alleen is onvoldoende) kan GA4 de bron niet bepalen.

(not set) in custom event-parameters / dimensions heeft drie officiële oorzaken: (a) de eerste 24 uur na registratie van een nieuwe custom dimension toont GA4 (not set) terwijl verwerking loopt; (b) de parameter wordt met een lege string verstuurd; (c) de parameter staat niet op het event dat de sessie of het eerste event triggert — auto-collected events zoals session_start en first_visit accepteren bepaalde parameters (zoals content_group) niet. Consent Mode veroorzaakt zijn eigen variant: het 'default' consent-command gebruiken in plaats van 'update' kan verhinderen dat user_engagement vertrekt, waardoor initiële session_start-data verloren gaat; en events met denied consent ná initiële consent kunnen losse sessies zonder session_start creëren. Tot slot GTM-tagvolgorde: een event-tag (purchase, view_item) die vuurt vóór de Google-tag is geïnitialiseerd, mist de sessie-context en kan (not set) opleveren in source/medium.

Bij Google Ads-dimensies (campagne/keyword toont (not set) terwijl traffic uit Ads komt) zijn de officiële oorzaken: niet-gekoppelde Ads-accounts, uitgeschakelde auto-tagging (gclid ontbreekt), of onvolledige UTM's bij handmatig getagde Ads-URLs. Let op het verschil met (other): dat is géén (not set). Dimensies met meer dan 500 unieke waarden per dag (high cardinality) of rapporten die de rijlimiet overschrijden, condenseren overige waarden in de (other)-rij. Ook data thresholding (vooral met Google Signals aan) groepeert onderdrukte rijen. Leg dit verschil expliciet aan de klant uit — (other) en (not set) hebben verschillende oorzaken en verschillende fixes.

De fixes lopen per context. Voor Landing page en source/medium: zet de Google-tag in GTM op de Initialization-trigger zodat session_start en page_view gegarandeerd als eerste vuren, en laat alle event-tags pas daarná vuren. Voor SPA's: stuur een page_view bij elke history-change. Tag álle campagne-URLs consistent met minimaal utm_source én utm_medium via een vaste UTM-conventie. Voor custom dimensions: wacht 24-48u na registratie, stuur nooit lege strings, en zet de parameter op de events waar hij hoort thuis (verwacht (not set) op auto-collected events die hem niet ondersteunen). Voor Consent Mode: implementeer v2 met een correcte default- én update-flow en test in DebugView met consent denied en granted of session_start en source/medium meekomen. Voor Ads-dimensies: koppel het account (Admin > Product Links), zet auto-tagging aan, en vermijd handmatige UTM's die auto-tagging overschrijven. Voor (other): verminder cardinaliteit (geen unieke IDs/timestamps als dimensiewaarde), gebruik exploraties in plaats van standaardrapporten, of koppel BigQuery om cardinaliteit, sampling en thresholding volledig te omzeilen. Verifieer telkens in GTM Preview en DebugView dat de juiste hit als eerste vertrekt.

Landing page (not set) → ontbrekende page_view: Google-tag op Initialization, event-tags daarná, SPA page_view per history-change.
Source/medium (not set) → ontbrekend session_start of incomplete UTM: Initialization-trigger + altijd utm_source ÉN utm_medium.
Custom dimension (not set) → 24u verwerking, lege string, of parameter op verkeerd event: wacht 24-48u, stuur geen lege strings.
Consent Mode (not set) → gebruik 'update' (niet alleen 'default'); test denied/granted in DebugView.
Ads-dimensies (not set) → koppel het account, zet auto-tagging aan, geen handmatige UTM's over auto-tagging.
(other) ≠ (not set): high cardinality (>500 unieke waarden/dag), rijlimiet of thresholding — los op met exploraties of BigQuery.
Leg het verschil tussen (other) en (not set) expliciet aan de klant uit; het zijn andere oorzaken.

Dubbele transactions: purchase telt (en omzet) dubbel

Symptoom: de omzet in GA4 ligt structureel hoger dan in het backend/ordersysteem, of je ziet in de DebugView twee purchase-events met dezelfde transaction_id. Dubbele transacties blazen niet alleen het aantal op, maar ook de revenue — en daarmee elke ROAS-berekening die de klant op GA4 baseert. Er zijn vier veelvoorkomende oorzaken, en de robuuste oplossing combineert meestal een frontend-guard met server-side validatie.

Oorzaak één: refresh van de bedankpagina. De gebruiker landt na betaling op de bevestigingspagina, purchase vuurt, en daarna refresht de gebruiker (screenshot, twijfel, gewoonte). Bij elke herlaad vuurt de tag opnieuw, inclusief dubbele omzet. Oorzaak twee: transaction_id ontbreekt of is leeg. GA4 dedupliceert purchase-events met dezelfde transaction_id, maar alleen als die uniek en aanwezig is. Google waarschuwt expliciet dat álle purchase-events met transaction_id="" als duplicaten worden behandeld en samengevoegd — wat juist legitieme transacties wegfiltert. Dezelfde id over verschillende gebruikers heen is óók fout.

Oorzaak drie: native dedup vangt niet alles. Omdat GA4 data in batches verwerkt, is er een verwerkingsvenster waarin twee identieke transacties beide door de ingestie kunnen glippen (dubbelklik op 'bestellen' binnen milliseconden). En de native dedup werkt praktisch alleen binnen een kort venster: een gebruiker die de bedankpagina dagen later opnieuw opent, wordt vrijwel zeker als tweede purchase geteld. Native dedup geldt bovendien alleen voor web-streams, niet voor app-streams. Oorzaak vier: dubbele tag-configuratie of dubbele bron. De purchase-tag vuurt op meerdere triggers, of zowel via hardcoded gtag als via GTM, of een dataLayer-push gebeurt twee keer. Variant hierop: in een hybride opzet sturen client-side (gtag/GTM-web) én server-side (Measurement Protocol of server-GTM) beide hetzelfde event in — zonder gedeelde identieke transaction_id telt GA4 dat als twee transacties en verdubbelt de omzet.

De fixes, gelaagd. Eerst de data: zorg dat elk purchase-event een unieke, niet-lege transaction_id meekrijgt die per order uniek is en nooit hergebruikt wordt over gebruikers (cijfers, letters, streepjes en spaties mogen). Valideer in GTM Preview en DebugView dat de parameter daadwerkelijk gevuld is vóór de tag vuurt — stuur nooit een lege string. Dan de frontend-guard tegen refresh: schrijf de transaction_id na de eerste purchase weg in een cookie of localStorage, en laat de purchase-tag alleen vuren als de huidige transaction_id níet al is opgeslagen (via een custom JavaScript variable als trigger-conditie). Audit daarnaast de container: zorg dat purchase via precies één route binnenkomt (alleen GTM, niet daarnaast een hardcoded gtag), dat de trigger maar één keer per pageview kan vuren en dat de dataLayer-push niet dubbel staat.

De robuustste route is purchase server-side vuren op basis van een bevestigde order-status, in plaats van op het laden van de bedankpagina — dan kan geen enkele refresh een extra transactie genereren. Stuur purchase dus bij voorkeur via één bron; gebruik je toch client én server, geef dan exact dezelfde transaction_id mee zodat GA4 kan ontdubbelen. Voeg waar het kan server-side validatie tegen de order-database toe, zodat een order maar één keer als purchase geteld kan worden ongeacht hoe vaak de pagina herlaadt. Voor app-streams moet je dedup volledig zelf regelen — native dedup geldt daar niet. Voor de e-commerce-context in den brede staat de aanpak in GA4 e-commerce tracking.

Unieke, niet-lege transaction_id per order, nooit hergebruikt over gebruikers — stuur nooit transaction_id="".
Frontend-guard: schrijf transaction_id weg in cookie/localStorage en blokkeer de tag als de id al bestaat.
Audit de container: purchase via precies één route (alleen GTM, niet ook hardcoded gtag), trigger 1× per pageview.
Client + server: identieke transaction_id meegeven, anders verdubbelt de omzet.
Robuustste fix: purchase server-side vuren op bevestigde order-status — refreshes kunnen dan niets toevoegen.
Native dedup vangt batch-window en late refresh niet; leun er niet uitsluitend op. App-streams: dedup volledig zelf regelen.
Verifieer in GTM Preview én DebugView dat er exact één purchase per order binnenkomt.

Self-referrals: je eigen domein of een betaaldomein als referral

Symptoom: in het Traffic acquisition-rapport zie je je eigen (sub)domein als referral source, of een betaaldomein (mollie.com, checkout.stripe.com, paypal.com, een bank-redirectdomein bij iDEAL) verschijnt als referrer — vaak precies op de sessies die converteren. Het gevolg is dubbel pijnlijk: je krijgt losse sessies in plaats van één gestitchte journey, én het betaaldomein overschrijft de oorspronkelijke bron, zodat je niet meer ziet welk kanaal de aankoop bracht.

Er zijn drie verschillende situaties met elk een eigen fix, en het is belangrijk ze niet door elkaar te halen. Eén: self-referral van je eigen domein of subdomein. Cross-domein- of subdomein-navigatie creëert losse sessies in plaats van een gestitchte sessie. GA4 herkent self-referrals automatisch alléén als cross-domain measurement is geconfigureerd én de bestemmings-URL de _gl linker-parameter bevat. Zonder die setup (of bij verkeerde cookie-domain-instellingen) ziet GA4 de tweede pagina als nieuwe referral.

Twee: payment-gateway redirect. Bij een redirect naar een extern betaaldomein dat je niet bezit (checkout.stripe.com, Mollie-hosted checkout, iDEAL-bankpagina's, paypal.com) en terug, ziet GA4 de terugkeer als nieuwe sessie met het betaaldomein als referrer. Cross-domain _gl werkt hier níet, omdat je de gtag op het betaaldomein niet beheert. Bij Stripe Checkout speelt bovendien dat third-party-cookierestricties de GA-sessie kunnen resetten, waardoor je naast de self-referral ook een gebroken purchase-funnel na terugkeer krijgt. Drie: echte externe domeinen die je wél bezit maar waar geen tag staat. Cross-domain measurement dekt die niet, dus zonder vermelding op de unwanted-referrals-lijst blijven ze binnenkomen.

De beslisregel voor bureaus is simpel: domein dat je beheert en kunt taggen → cross-domain measurement (domains list + _gl). Domein dat je níet kunt taggen (payment gateways, externe portals) → 'List unwanted referrals'. Combineer beide waar nodig. Voor cross-domain: Admin > Data Streams > Web > Configure tag settings > Configure your domains, voeg alle eigen domeinen toe, zorg dat de Google-tag op álle pagina's en domeinen staat met een consistent cookie-domain, en verifieer dat uitgaande links de _gl-parameter krijgen.

Voor de betaaldomeinen: voeg ze toe aan 'List unwanted referrals' (Admin > Data Streams > Web > Configure tag settings > Show all > List unwanted referrals; max 50 per stream, OR-logica). Gebruik match type 'Domein bevat' zodat je regionale subdomeinen zoals uk.paypal.com in één keer vangt. Voor NL voeg je toe wat in jouw flow daadwerkelijk als referrer opduikt — typisch mollie.com, checkout.stripe.com, paypal.com en bij iDEAL de bank-redirectdomeinen die je in het Referrals-rapport ziet. GA4 voegt dan ignore_referrer=true toe aan matchende events. Let op: dit werkt niet retroactief — het geldt alleen vooruit, en je verifieert achteraf in Traffic acquisition dat het domein niet meer als referral verschijnt (alleen voor nieuwe data). Specifiek voor Stripe Checkout heb je twee aparte fixes nodig: (1) referral exclusion om de referral te onderdrukken, én (2) sessie-continuïteit — geef ga_client_id en ga_session_id mee als query-parameters in de success-URL en herstel ze bij terugkeer, zodat de purchase aan dezelfde sessie en bron gekoppeld blijft. Exclusion alleen herstelt de funnel-attributie niet.

Eigen (sub)domein als referral → cross-domain measurement: Configure your domains + _gl op uitgaande links + consistent cookie-domain.
Payment-gateway (Mollie/Stripe/iDEAL/PayPal) → 'List unwanted referrals'; _gl werkt hier niet (je beheert het domein niet).
Match type 'Domein bevat' vangt regionale subdomeinen (uk.paypal.com) in één regel; max 50 entries per stream, OR-logica.
Voeg alleen toe wat daadwerkelijk in jouw Referrals-rapport opduikt — typisch mollie.com / checkout.stripe.com / paypal.com / bank-domeinen.
Beslisregel: kun je het taggen → cross-domain; kun je het niet taggen → unwanted referrals. Combineer waar nodig.
Stripe Checkout: exclusion + sessie-continuïteit (ga_client_id/ga_session_id in success-URL) — beide zijn nodig.
Referral exclusion werkt niet retroactief; verifieer achteraf in Traffic acquisition op nieuwe data.

Waarom dit blijft terugkomen

Hier is het eerlijke deel. Je kunt elk van deze vier problemen vandaag oplossen — de vensters afstemmen, de Google-tag op Initialization zetten, een transaction_id-guard inbouwen, de betaaldomeinen excluden. En toch staan ze over drie maanden weer in een ander deel van de account. Niet omdat je het verkeerd deed, maar omdat een tracking-setup geen eenmalig product is. Het is een levend systeem dat meebeweegt met elke deploy, elke nieuwe campagne-URL, elke wijziging in de CMP, elke betaalprovider die zijn redirectdomein aanpast.

Dat is de gemene deler onder alle vier: het zijn symptomen van ontbrekende continue monitoring. Een setup die vandaag klopt, breekt morgen stil — zonder foutmelding, zonder waarschuwing. Een ontwikkelaar haalt per ongeluk de dataLayer-push weg, een nieuwe landingspagina mist de page_view-volgorde, iemand zet een campagne live zonder utm_medium, de consent-acceptatiegraad zakt en de delta met Ads groeit. Je merkt het pas als de klant naar een raar cijfer wijst, en dan ben je weken aan data kwijt die je niet retroactief kunt repareren.

Dit is precies wat tracking operations oplost: niet één keer goed opzetten, maar doorlopend bewaken dat het goed blíjft. Geautomatiseerde checks op of purchase-events dubbel binnenkomen, of (not set) ineens stijgt, of er nieuwe referraldomeinen opduiken, of de consent-flow nog doet wat hij moet. We zeggen niet dat je dit niet zelf kunt — een goede operator kan dit handmatig bijhouden. Maar handmatig schaalt slecht over tientallen accounts, en stille fouten zijn juist de fouten die je handmatig het laatst opmerkt. Daar zit de waarde van structurele monitoring: niet in het oplossen, maar in het op tijd zién.

Wil je weten waar je accounts nu staan? Begin met een de gratis audit of de de Consent Mode v2 Checker voor een snelle check op de consent-kant. Voor de bredere aanpak van doorlopende bewaking: tracking operations. En voor de fundamenten staan er aanvullende gidsen klaar: GA4-audit voor bureaus, Consent Mode v2 en GA4 e-commerce tracking.

Alle vier de problemen zijn symptomen van ontbrekende continue monitoring, niet van een eenmalige fout.
Een correcte setup breekt stil bij elke deploy, nieuwe campagne-URL, CMP-wijziging of provider-update — zonder foutmelding.
Stille fouten merk je handmatig het laatst; je bent dan data kwijt die je niet retroactief kunt herstellen.
Tracking operations bewaakt doorlopend: dubbele purchases, stijgende (not set), nieuwe referrals, brekende consent-flow.
Start praktisch: de gratis audit, de Consent Mode v2 Checker, en voor de structurele aanpak tracking operations.

Veelgestelde vragen.

Waarom verschillen GA4 en Google Ads altijd in conversies?

Omdat de twee systemen conversies fundamenteel anders behandelen, niet door een bug. Ads crediteert op de ad-interactie en boekt op de klikdatum; GA4 gebruikt een eigen reporting-attributiemodel (data-driven of last click) en boekt op de eventdatum. Daar bovenop komen verschillende lookback-vensters (GA4 30/90 dagen vs het Ads-conversievenster), verschil in tel-methode (One vs Every), verwerkingstijd tot 48 uur, mogelijke tijdzone-mismatch, en modeled conversions bij geweigerde consent. Een vaste delta is normaal — stem de vensters af, vergelijk over een afgesloten periode en monitor de delta in plaats van een 1:1-match na te jagen.

Wat betekent (not set) in GA4?

Dat GA4 voor die dimensie geen waarde kon bepalen — maar de oorzaak verschilt per context. In Landing page betekent het een sessie zonder page_view-event. In Source/medium of campaign een ontbrekend session_start (vaak een GTM-trigger die niet op Initialization staat) of incomplete UTM-tagging. In een custom dimension: de eerste 24u na registratie, een lege string, of een parameter op een event dat hem niet ondersteunt. Bepaal dus altijd eerst welke dimensie (not set) toont voordat je iets aanpast. Let op: (other) is iets anders — dat komt van high cardinality of rijlimieten, niet van een meetfout.

Hoe voorkom ik dubbele transacties in GA4?

Begin bij de transaction_id: elk purchase-event moet een unieke, niet-lege id meekrijgen die per order uniek is en nooit hergebruikt wordt over gebruikers — stuur nooit een lege string. Bouw daarnaast een frontend-guard in GTM: schrijf de transaction_id na de eerste purchase weg in een cookie of localStorage en laat de tag alleen vuren als die id nog niet bestaat, zodat een refresh van de bedankpagina niets toevoegt. Audit de container op dubbele bronnen (alleen GTM, geen hardcoded gtag erbij). De robuustste oplossing is purchase server-side vuren op een bevestigde order-status. Leun niet uitsluitend op GA4's native dedup — die mist het batch-window en late refreshes.

Hoe sluit ik een self-referral of betaaldomein uit in GA4?

Dat hangt af van of je het domein kunt taggen. Je eigen domeinen en subdomeinen los je op met cross-domain measurement: Admin > Data Streams > Web > Configure tag settings > Configure your domains, met de Google-tag op alle domeinen en een consistent cookie-domain. Betaaldomeinen die je niet beheert (mollie.com, checkout.stripe.com, paypal.com, iDEAL-bankdomeinen) kun je niet via _gl koppelen — die voeg je toe aan 'List unwanted referrals' (Show all in de tag settings, max 50 per stream). Gebruik match type 'Domein bevat' om regionale subdomeinen in één keer te vangen. Let op: dit werkt niet retroactief, alleen vooruit.

Werkt de native transaction_id-deduplicatie van GA4 niet?

Hij werkt, maar niet volledig. GA4 dedupliceert op transaction_id, maar omdat data in batches verwerkt wordt, kunnen twee identieke transacties binnen het verwerkingsvenster beide door de ingestie glippen (denk aan een dubbelklik op 'bestellen'). Bovendien werkt de native dedup praktisch alleen binnen een kort venster: opent een gebruiker de bedankpagina dagen later opnieuw, dan wordt dat vrijwel zeker als tweede purchase geteld. En native dedup geldt alleen voor web-streams, niet voor app-streams. Vandaar dat je een eigen frontend-guard en bij voorkeur server-side validatie tegen de order-database toevoegt.

Moet ik in Google Ads de Count op 'One' of 'Every' zetten?

Dat hangt af van het type conversie. Zet 'Every' voor e-commerce en aankopen, waar elke transactie afzonderlijk moet tellen. Zet 'One' voor leads, waar één conversie per gebruiker logisch is — anders telt een gebruiker die twee keer hetzelfde formulier invult als twee conversies. De instelling moet aansluiten op hoe het key event in GA4 telt, want een mismatch tussen wat je in GA4 ziet en wat Ads optimaliseert ontstaat puur door deze Count-instelling, niet door een trackingfout.

Waarom telt Google Ads hoger dan GA4 in Nederland?

Meestal door modeled conversions in combinatie met Consent Mode v2. Als consent geweigerd wordt, kan Ads de gaten opvullen met modellering, terwijl GA4 primair observeerde events rapporteert met beperktere modellering. In markten met hoge weigeringsgraad — zoals veel NL/EU-verkeer — rapporteert GA4 daardoor vaak structureel lager dan Ads. Dat is modellering, geen meetfout. Implementeer Consent Mode v2 correct zodat beide platforms consistente signalen krijgen, en monitor de consent-acceptatiegraad apart: een dalende acceptatie verklaart een groeiende delta zonder dat de tagging stuk is.

Vier GA4-data-discrepanties — en hoe je ze vandaag oplost