Een klant betaalt, maar de aankoop ontbreekt in GA4. Ik begin dan met drie vragen: is de betaling bevestigd, is meting toegestaan en kan het event aan het bezoek worden gekoppeld?
Dat zijn verschillende problemen. Een betaalredirect verklaart ze niet automatisch.
Wat de betaalmethoden beschrijven
De iDEAL-handleiding beschrijft terugkeer naar de opgegeven returnUrl. De winkel ontvangt de betaalstatus apart via een callback of haalt die op.
Bancontact beschrijft onder meer QR-betalingen, appkoppelingen en statusmeldingen. Niet iedere klant doorloopt dus dezelfde browserredirect.
Geen van die handleidingen zegt dat de winkel zijn consentcookies verliest. Ik behandel verdwenen opslag als een hypothese die we testen. Ook een verkeerd terugkeerdomein of een ontbrekende consent-update kan het probleem zijn.
Controleer eerst de browserroute
Ik vergelijk de toestand vóór betaling met die op de terugkeerpagina: browsercontext, domein, opgeslagen keuze, toegepaste consentstatus en de purchase-tag.
Google zegt dat Consent Mode keuzes niet zelf bewaart. De consentoplossing moet dat doen en de keuze op volgende pagina’s opnieuw toepassen.
Een betaalprovider kan ook als ongewenste referral verschijnen. Google’s verwijzingsuitsluiting helpt dat attributieprobleem aan te pakken. Ze herstelt geen consent, verdwenen cookies of ontbrekend purchase-event.
Als de browserroute goed werkt, is een extra serverroute niet vanzelf nodig. De purchase correct versturen blijft de eerste controle.
Een serverroute met een duidelijke grens
Als de browser onvoldoende dekking geeft, kan ik een aanvullende route ontwerpen:
- Bevestig de betaling. Gebruik een gecontroleerde servermelding of statuscontrole. Een aangemaakte bestelling of terugkeerpagina is onvoldoende.
- Controleer toestemming per doel. Bewaar alleen noodzakelijke gegevens en controleer geldigheid en latere intrekking. Onbekende of geweigerde toestemming blokkeert de verzending in dit ontwerp.
- Behoud de koppeling waar toegestaan. Voor een GA4-webstream gebruik ik de bestaande
client_iden, waar beschikbaar,session_id. UTM en referrer alleen garanderen geen sessieattributie. - Maak verwerking herhaalbaar zonder extra aankoop. Gebruik hetzelfde niet-lege
transaction_id, verwerk herhaalde meldingen één keer en stem de browserroute af.
GA4 dedupliceert webaankopen met dezelfde transactie-ID voor dezelfde gebruiker. Een nieuwe client-identiteit kan die aanname breken. Daarom test ik beide routes samen.
Wat Measurement Protocol niet repareert
Google positioneert het protocol als aanvulling op tagging. Een server-only ontwerp kan gedeeltelijke rapportage opleveren.
Het verzoek heeft aparte consentvelden voor ad_user_data en ad_personalization. Die zijn geen vervanging voor mijn controle of analyticsverzameling is toegestaan. Ik leid toestemming niet af uit het bestaan van een bestelling.
Het terugdateervenster is 72 uur. Voor verwerking samen met client-events noemt Google daarnaast ontvangst binnen 48 uur van het oorspronkelijke client-event. Ik ontwerp verzending zo snel mogelijk na bevestiging en behandel deze vensters niet als garantie voor attributie.
Advanced Consent Mode kan bij denied cookieless pings sturen. Mijn voorgestelde serverroute gebruikt een strengere grens: zonder geldige toestemming geen verzending.
De proef is de afstemming
Ik vergelijk betaalde orders met de ontvangen events en label elk verschil: bewust niet gemeten, betaling niet bevestigd, verzending mislukt of sessiekoppeling ontbreekt. De afstemming op bestelniveau beschrijft die methode.
Een technisch geslaagd event bewijst nog geen advertentieattributie. Ik beloof geen teruggewonnen advertentiecredits zonder bewijs uit het platform.
Ik kan dit voor je bouwen
Dit valt onder mijn server-side trackingwerk: eerst de oorzaak vaststellen, daarna toegestane events en afstemming bouwen. Is het bereik duidelijk, dan kan ik direct offreren. Anders spreken we een afzonderlijk diagnostisch traject af.
