2026-07-10

Het iDEAL-attributiegat: waarom je GA4-data liegt (2026)

Je GA4 zegt dat "Direct" je beste verkoopkanaal is. Dat klopt niet. iDEAL maakt je meting kapot: ruim 70% van je Nederlandse checkout loopt via de bank-app, en die redirect breekt precies de sessie waaraan Meta en Google Ads hun conversie zouden koppelen. Je beste kanalen zien er slechter uit dan ze zijn, omdat iDEAL hun omzet stilletjes doorschuift naar Direct.

In Nederland is dit geen randgevalletje, het is de norm. iDEAL is met een online marktaandeel van rond de 70% verreweg de meestgebruikte betaalmethode[1][2]. Elke keer dat een klant naar zijn bank-app springt om te betalen, verlaat hij je site. Bij terugkomst ziet GA4 vaak een nieuwe sessie zonder herkomst. De aankoop landt dan onder Direct of onder de bank als verwijzende bron[3]. Browser-side pleisters lossen dat op een mobiele bank-app-hop meestal niet op. De echte fix zit op je server.

In het kort

  • iDEAL is de norm. Rond de 70% van alle online betalingen in Nederland loopt via iDEAL, met meer dan een miljard transacties per jaar[1][2].
  • De bank-app-redirect breekt je GA4-sessie. De klant springt naar de app van ING, Rabobank of ABN AMRO; bij terugkeer is de sessie- en cookiecontext weg.
  • GA4 verzint dan een bron. De aankoop wordt toegeschreven aan Direct of aan de bank als referral in plaats van aan de klik die hem veroorzaakte[3].
  • Browser-side pleisters overleven de hop niet. Referral-uitsluiting en de _gl-linker helpen bij een gewone gateway-redirect, maar niet betrouwbaar bij de sprong naar een aparte bank-app[5].
  • De echte fix is server-side. Sla bij checkout de GA4 client_id, gclid en fbp op bij de order; stuur de aankoop via de Mollie- of Adyen-webhook terug met die identifiers, zodat de conversie aan de oorspronkelijke klik blijft plakken[7][8].

iDEAL is de norm — en je attributie weet dat niet

Eerst de schaal, want die maakt dit een specifiek Nederlands probleem. iDEAL heeft een online marktaandeel van rond de 70% en is daarmee de meestgebruikte betaalmethode van het land[1][2]. Grofweg zeven op de tien checkouts lopen erlangs, goed voor meer dan een miljard transacties per jaar[1]. Elders in Europa domineert de kaart of PayPal, en daar valt dit gat kleiner uit. Hier raakt het je grootste betaalstroom.

En dat is precies het venijn. Analyticssetups en tutorials komen vaak uit landen waar creditcard de standaard is. Die scenario's houden geen rekening met een betaalmethode die de gebruiker fysiek uit je site en in een aparte bank-app trekt. Jij draait dat model wél op je grootste kanaal.

~70%online marktaandeel van iDEAL in NL[1]
>1 mldiDEAL-transacties per jaar[1]
7 op 10checkouts lopen grofweg via iDEAL[2]
iDEAL is de dominante betaalmethode in Nederland — en dus de plek waar je attributie het hardst lekt. Source: iDEAL, 2024; Statista, 2026; Betaalvereniging Nederland.
iDEAL~70%
Alle andere methoden samen (kaart, PayPal, overig)~30%
De Nederlandse betaalmix is extreem scheef: één methode draagt het leeuwendeel van je checkouts — en dus van je attributierisico. Source: Betaalvereniging Nederland[2].
Je "beste kanaal" in GA4 is geen kanaal. Het is een verzamelbak voor conversies die hun herkomst kwijtraakten in een bank-app.

Wat er echt gebeurt als iemand met iDEAL betaalt

Het breekt stap voor stap, en elke stap ziet er onschuldig uit. Iemand klikt op je Meta- of Google Ads-advertentie, landt op je productpagina, legt iets in de mand en gaat afrekenen. Tot hier klopt alles: GA4 heeft de klik, de bron en de sessie netjes vast.

Dan kiest hij iDEAL en zijn bank. En daar knapt het. De betaling opent de app van ING, Rabobank of ABN AMRO — een aparte app, buiten je browser. Je site is op dat moment weg uit beeld. Na het bevestigen stuurt de bank de klant terug naar je bedankpagina, maar vaak in een nieuwe browsercontext of nieuwe sessie[3]. GA4 ziet iemand "opnieuw binnenkomen" zonder herkomst, opent een nieuwe sessie en schrijft de aankoop toe aan Direct — of aan de bank als verwijzende bron[3][4]. De oorspronkelijke advertentieklik? Die staat in de vorige sessie, en die is losgekoppeld.

stap 1 Klant klikt op je Meta- of Google Ads-advertentie en landt op je site. GA4 legt bron, gclid/fbclid en sessie vast.
stap 2 Hij vult de mand en start de checkout. Nog steeds één ononderbroken sessie.
stap 3 Hij kiest iDEAL → redirect naar de bank-app (ING / Rabobank / ABN AMRO), buiten de browser.
stap 4 Sessie- en cookiecontext breken: de browser die terugkomt is niet gegarandeerd dezelfde context[3].
stap 5 Terug op de bedankpagina ziet GA4 een nieuwe sessie zonder herkomst[4].
stap 6 De conversie wordt toegeschreven aan Direct of aan de bank als referral — niet aan de advertentieklik[3].

Het kapotte pad van klik tot miscredit bij een iDEAL-betaling. Source: Snifflytics, 2026[3].

Waarom je Meta- en Google Ads-cijfers te laag lijken

Zie je waar dit heen gaat? Elke conversie die naar Direct of de bank verhuist, wordt afgepakt van het betaalde kanaal dat hem eigenlijk leverde. Google Ads en Meta krijgen minder omzet toegewezen dan ze veroorzaakten. Je ROAS in het platform ziet er slechter uit dan de werkelijkheid.

En dan neem je de verkeerde beslissing. Je ziet een campagne die "onder de 2x ROAS" scoort en zet hem uit — terwijl die campagne in werkelijkheid gewoon presteerde, maar de helft van zijn iDEAL-omzet bij Direct zag belanden. Je snijdt in wat werkt. Dat is de dure fout: niet dat de data ontbreekt, maar dat je erop stuurt alsof ze klopt.

Dit is ook precies waarom losse platformcijfers je in Nederland zo snel misleiden, en waarom slimme webshops sturen op omzet over álle advertentie-uitgaven samen. Over dat verschil tussen ROAS en MER schreven we eerder in van ROAS naar MER voor webshops. Het iDEAL-gat is een van de grootste redenen dat je platform-ROAS en je werkelijke marge uit elkaar lopen.

Reken hieronder zelf uit hoeveel betaalde conversies bij jou maandelijks risico lopen om verkeerd toegeschreven te worden.

Verdwijnt jouw iDEAL-omzet in Direct?

?Het totale aantal bestellingen dat je per maand haalt. Een grove schatting uit je eigen backend is prima.
?Welk deel van je bestellingen via iDEAL betaalt. In Nederland is dat grofweg 7 op de 10, dus 70% is een reële standaard.
?Welk deel van je bestellingen komt uit Meta- en Google Ads. Kijk in GA4 of je platform-rapportage; weet je het niet, houd dan een schatting aan.
— Vul je bestellingen, je iDEAL-aandeel en je aandeel betaald verkeer in.

Zo rekenen we: risico = bestellingen × iDEAL% × betaald%. Dit is een bovengrens, geen exacte telling: niet elke iDEAL-transactie breekt de attributie — dat hangt af van device, browser en je huidige setup. Zie het als "zoveel betaalde conversies staan maximaal op het spel om aan Direct of de bank te worden toegeschreven" als je niets repareert.

De browser-side pleisters — en waarom ze niet genoeg zijn

Als je dit googelt, krijg je drie standaardadviezen: zet betaal-gateways op je referral-uitsluitingslijst, zorg dat de _gl-linkerparameter de redirect overleeft, en schakel cross-domain tracking in[5]. Prima adviezen, voor het probleem waarvoor ze bedacht zijn. Dat probleem is een redirect binnen de browser, naar het domein van een gateway en weer terug.

iDEAL is dat niet. De klant springt naar een aparte bank-app, buiten de browser. En daar sneuvelen die pleisters. De _gl-parameter reist mee in een URL, maar de bank-app opent zijn eigen context en geeft die parameter niet gegarandeerd terug. Cookies die aan de browsersessie hingen, zijn bij terugkeer niet betrouwbaar aanwezig[3][5]. Een referral-uitsluiting voorkomt dat de bank als bron verschijnt, maar het herstelt de oorspronkelijke klik niet — dan valt de conversie gewoon terug op Direct[4].

PleisterWat het doetWaarom het bij iDEAL vaak faalt
Referral-uitsluitingHoudt de gateway/bank van je bronnenlijst[5]Voorkomt de bank-referral, maar de klik is al losgekoppeld — conversie valt terug op Direct[4]
_gl cross-domain linkerDraagt de client-context mee in de redirect-URL[5]De bank-app opent zijn eigen context en geeft de parameter niet gegarandeerd terug[3]
Cross-domain trackingDeelt cookies tussen je site en de gateway[5]Werkt tussen domeinen in dezelfde browser, niet over een sprong naar een aparte app[3]

Browser-side pleisters zijn gebouwd voor een redirect binnen de browser, niet voor een mobiele bank-app-hop. Source: OptimizeSmart, 2026[5].

Doe ze toch. Referral-uitsluiting van je gateways en banken is gratis en houdt je bronnenrapport schoner. Zie het als het minimum — niet als de oplossing. Op de bank-app-hop knappen ze, en dat is precies waar je iDEAL-verkeer doorheen gaat.

De echte fix: server-side webhooks

De oplossing is om de conversie niet meer afhankelijk te maken van de browser die terugkomt. Je legt de identiteit van de klik vroeg vast en speelt hem later server-to-server terug. Concreet, in volgorde:

1. Vang de identifiers bij checkout. Op het moment dat de klant afrekent — vóór de redirect — lees je uit de _ga-cookie de GA4 client_id en session_id[8], plus de gclid (Google Ads), de fbp en fbc (Meta). Dat kan nog netjes, want de browser is op dat moment gewoon aanwezig.

2. Sla ze op bij de order. Schrijf die identifiers als metadata weg bij de bestelling in je backend[8]. Nu hangt de klik-identiteit aan de order, niet aan een vluchtige browsersessie die zo de bank-app in verdwijnt.

3. Laat de webhook de conversie sturen. Wanneer Mollie of Adyen de betaling bevestigt, vuurt hun webhook server-side af naar jouw backend. Dat is je trigger. Je stuurt dan het purchase-event via het GA4 Measurement Protocol (en Meta CAPI) mét de opgeslagen client_id, session_id, gclid en fbp[7][8].

4. De conversie plakt terug aan de oorspronkelijke klik. Omdat je de client_id en session_id meestuurt, koppelt GA4 het event aan de sessie waarin de advertentieklik zat — niet aan een nieuwe Direct-sessie[8]. Google Ads en Meta krijgen hun credit terug.

Je repareert de meting niet in de browser die wegvalt. Je verplaatst hem naar de webhook die altijd afvuurt.

Dit is meteen de aanbevolen aanpak voor betrouwbare e-commerce-meting in het algemeen: het purchase-event server-side sturen via webhook en Measurement Protocol geeft schonere checkout-data dan een event dat afhangt van of de bedankpagina wel volledig laadt[7].

Waarom een webhook betrouwbaarder is dan de browser

Het grote voordeel is simpel: de webhook vuurt server-to-server af, los van de browser van de klant. Geen afgebroken sessie, geen gemiste bedankpagina, geen adblocker die het event tegenhoudt. De betaling is bevestigd, dus het event kómt — punt.

Maar wees eerlijk over de keerzijde, want die is de reden dat stap 1 en 2 hierboven niet optioneel zijn. Op het moment dat de webhook afvuurt, is de browser van de klant onbereikbaar. De webhook heeft geen _fbp-cookie, geen echte User-Agent en geen betekenisvol client-IP meer[6]. Vuur je "kaal" af, dan mist je event precies de identiteit die attributie mogelijk maakt.

De nuance die het maakt of breekt: een webhook is alleen zo goed als de identifiers die je erin stopt. Sla je bij checkout niet vooraf de client_id, gclid en fbp op, dan levert de webhook een conversie zonder herkomst — net zo blind als de browser die je probeerde te vervangen[6]. Vastleggen en terugspelen: dat is de hele truc.

Dit is trouwens dezelfde server-side aanpak die een ander datalek dicht: het verlies door cookieweigeringen onder de AVG. Ander gat, zelfde medicijn. Daarover schreven we apart in AP-proof tracking zonder conversieverlies. Ga je toch server-side bouwen, dan pak je die twee lekken het slimst in één keer aan.

Hoe begin je

Geen half jaar aan bouwwerk. Dit is een gerichte ingreep van zo'n 30 dagen, in vijf stappen die op elkaar voortbouwen.

Stap 1: audit je self-referrals in GA4. Kijk in je bronnenrapport of banken en gateways (mollie, adyen, ideal, ing, rabobank) als source/medium opduiken[4]. Zie je die, dan lekt je iDEAL-attributie aantoonbaar. Twijfel je of je meting überhaupt klopt, draai dan eerst een gratis tracking checker voordat je op deze cijfers gaat sturen.

Stap 2: zet gateways op de referral-uitsluiting. Voeg je banken en betaal-gateways toe aan de uitsluitingslijst[5]. Dit is het minimum, geen eindstation — het houdt de bank uit je bronnen, maar redt de klik nog niet.

Stap 3: leg de identifiers vast bij checkout. Lees vóór de redirect de client_id en session_id uit de _ga-cookie, plus gclid en fbp, en sla ze op bij de order[8].

Stap 4: koppel de Mollie/Adyen-webhook aan Measurement Protocol en Meta CAPI. Laat de payment-confirmed-webhook het purchase-event server-side sturen mét de opgeslagen identifiers[7][8].

Stap 5: valideer in GA4 DebugView. Doe een testaankoop met iDEAL en controleer dat het purchase-event binnenkomt op de juiste sessie en bron, niet op Direct. Meet je het niet, dan weet je niet of het werkt.

FAQ

Waarom staat mijn iDEAL-omzet onder Direct?+
Omdat de iDEAL-betaling de klant naar een aparte bank-app stuurt, buiten je browser. Bij terugkeer op je bedankpagina ziet GA4 vaak een nieuwe sessie zonder herkomst en start het een verse sessie (Snifflytics, 2026). De oorspronkelijke advertentieklik zat in de vorige sessie en raakt losgekoppeld, dus de aankoop valt terug op Direct of op de bank als referral. Het is geen fout in je omzet, maar in de toewijzing ervan.
Lost een referral-uitsluiting het niet gewoon op?+
Deels. Een referral-uitsluiting van je gateways en banken voorkomt dat de bank als bron in je rapport verschijnt (OptimizeSmart, 2026), en die zet je zeker aan als minimum. Maar het herstelt de oorspronkelijke klik niet: op de mobiele bank-app-hop is de sessiecontext al gebroken, dus de conversie valt dan terug op Direct in plaats van op Google of Meta (Snifflytics, 2026). Voor echt herstel heb je server-side terugspelen nodig.
Heb ik hiervoor Mollie of Adyen nodig?+
Nee, elke betaal-gateway met server-side webhooks werkt. Mollie en Adyen zijn in Nederland gangbaar, maar het principe is universeel: je laat de "betaling bevestigd"-webhook het purchase-event server-side sturen via GA4 Measurement Protocol en Meta CAPI (Tracklution, 2026). Zolang je gateway een betrouwbare webhook heeft die na betaling afvuurt, kun je deze fix bouwen.
Verlies ik data door de bank-app-redirect zelf?+
De omzet verlies je niet — de betaling gaat gewoon door en de order komt binnen. Wat je verliest is de attributie: de koppeling tussen de aankoop en de klik die hem veroorzaakte. Bij een off-domain redirect naar de bank en terug start GA4 een nieuwe sessie en schrijft het de conversie toe aan de gateway/bank of aan Direct (Snifflytics, 2026). Je marketingcijfers liegen dus, niet je kassa.
Is server-side tracking hiervoor legaal en AVG-proof?+
Ja, mits je toestemming netjes afhandelt. Server-side tracking is een techniek, geen omzeiling van de cookiewet: je stuurt alleen door wat de gebruiker heeft toegestaan. Sterker nog, dezelfde server-side aanpak dicht ook het datalek door cookieweigeringen onder de AVG — daarover schreven we in AP-proof tracking zonder conversieverlies. Zorg dat je consent-signaal meereist en dat je vóór toestemming geen persoonsgegevens verstuurt, dan zit je goed.

Bronnen

  1. iDEAL (Currence/EPI) — Latest & kerncijfers: jaarlijks worden circa 1,3 miljard transacties via iDEAL verwerkt (primaire bron voor het transactievolume); marktaandeel ~70% cf. Statista. ideal.nl; statista.com
  2. Betaalvereniging Nederland — Online payment methods (iDEAL de meestgebruikte online betaalmethode in NL, rond de 70% marktaandeel). betaalvereniging.nl
  3. Snifflytics — PayPal, Stripe and checkout attribution leaks: auditing GA4 for the 4 gateway patterns that break tracking (off-domain redirect start een nieuwe sessie en schrijft de gateway/bank als bron; de echte bron verliest credit), 2026. snifflytics.com
  4. OptimizeSmart — Self-referral in GA4 & referral exclusion (sessiebreuken/redirects fragmenteren sessies en verstoren attributie; betaal-gateways zijn een klassieke oorzaak). optimizesmart.com
  5. OptimizeSmart — Setup cross-domain tracking in Google Analytics 4 (referral-uitsluiting van betrokken domeinen, de _gl cross-domain linkerparameter en het delen van de client_id-cookie tussen domeinen). optimizesmart.com
  6. Sweetcode — WooCommerce Conversion API quality (bij het afvuren van de gateway-webhook is de browser onbereikbaar: geen _fbp-cookie, geen User-Agent, geen betekenisvol client-IP; identifiers moeten eerder zijn opgeslagen). sweetcode.com
  7. Tracklution — Server-side tracking for GA4 (purchase-event server-side sturen via webhook + Measurement Protocol geeft betrouwbaardere checkout-data dan browser-load-events), 2026. tracklution.com
  8. Analyzify — Server-side tracking for GA4 (server-side purchase-setup vereist de GA client_id en session_id om het event aan de juiste sessie/bron te koppelen). docs.analyzify.com

Back to all posts