Waarom Meta-aankopen verdwijnen in GA4: de in-app browser

Meta Ads Manager meldt 47 aankopen deze week. Je opent GA4, filtert op facebook / cpc en instagram / cpc over dezelfde periode, en ziet er 12. De andere 35 staan onder (direct) / (none) of bij een regel mollie.com / referral die niemand daar bewust heeft neergezet.

Er is niets mis met je tags. Het is een structureel probleem in hoe Meta links opent, hoe betaalproviders zich op mobiel gedragen, en hoe GA4 cookies leest.

Tikt iemand in Facebook of Instagram op een link, dan opent Meta geen Safari of Chrome maar zijn eigen ingebouwde browser: een WKWebView op iOS, een Chromium-variant op Android.

Die browser heeft een eigen cookiepot, volledig afgeschermd van de systeembrowser. Cookies uit de een zijn onleesbaar voor de ander. Ze gedragen zich alsof het twee apparaten zijn. Meta houdt gebruikers in de app omdat dat sessiecijfers behoudt en first-party signaal oplevert, wat zwaarder weegt sinds App Tracking Transparency het meten via IDFA grotendeels om zeep hielp.

Een typische mobiele route van Meta-advertentie naar aankoop op iOS:

1. De gebruiker tikt in Instagram op je advertentie.
2. De landingspagina opent in de in-app browser. GA4 vuurt, de _ga-cookies belanden in de in-app cookiepot, en fbclid staat in de URL.
3. De gebruiker kijkt rond, legt iets in de mand en gaat naar de checkout. De cookies zitten nog in de in-app browser, GA4 meet nog dezelfde sessie.
4. De checkout stuurt door naar de betaalprovider: Mollie, Adyen, Stripe, Klarna, PayPal of een iDEAL-acquirer.
5. Die draait 3DS, of opent de bank-app voor iDEAL of Apple Pay.
6. De terugkeer-URL opent in de systeembrowser, niet terug in de in-app browser. Dat bepaalt het besturingssysteem, en de meeste bank-apps en providers dwingen het af.
7. De gebruiker komt in Safari op je bedankpagina. GA4 vuurt, maar de cookie uit stap twee ligt ergens anders. GA4 ziet een gloednieuwe bezoeker, een nieuw client_id, een nieuwe sessie.
8. De verwijzer is de betaalprovider, dus de aankoop wordt toegewezen aan (direct) / (none) of provider / referral.

Tegen de tijd dat de aankoop afgaat, is de oorspronkelijke Meta-klik onzichtbaar voor GA4. Meta telt hem wel, want die pijplijn leunt op fbclid en het gededupliceerde server-side event, niet op cookies in de systeembrowser. Vandaar dat Ads Manager er gezond uitziet en GA4 niet.

Dit is geen theorie. Bij een gemiddelde Nederlandse webshop met iDEAL als voornaamste betaalmethode verklaart dit ene mechanisme het grootste deel van het aandeel (direct) boven de ruis.

Genoeg mensen browsen vanuit de in-app browser zonder dat er iets sneuvelt. Een artikel lezen, je aanmelden, zelfs iets in de mand leggen blijft binnen dezelfde cookiepot en de attributie overleeft dat.

Het breekt bij de betaling, omdat iDEAL op mobiel de bank-app opent en de terugkeer via een universal link loopt die het besturingssysteem in de standaardbrowser opent. In de in-app browser komt de gebruiker niet meer terug.

3DS-uitdagingen openen bij sommige integraties in de systeembrowser, zeker als de in-app browser niet door de apparaatcontroles van de uitgever komt. Apple Pay en Google Pay kunnen in de app afgerond worden, maar de succesredirect springt er alsnog uit. PayPal dwingt de terugkeer-URL op iOS ronduit naar de systeembrowser.

Providers verschillen. Mollie met iDEAL is bij Nederlandse shops de meest consistente veroorzaker, met Adyen, Klarna en Stripe die dezelfde gebroken overdracht opleveren.

Vier controles, elk een paar minuten:

1. Het aandeel Direct bij aankopen. Filter in Verkeersacquisitie op het purchase-event. Zit Direct boven de 30% bij een webshop, dan gaat er iets structureel mis.
2. De verwijzers erachter. Zet de dimensie op Sessiebron / medium en zoek naar mollie.com / referral, adyen.com / referral, pay.klarna.com / referral, checkout.stripe.com / referral, paypal.com / referral of bankdomeinen.
3. De user agent. Bouw een vrije verkenning met Browser en Besturingssysteem. De iOS in-app browser van Meta draagt FBAN, FBIOS of Instagram in de user-agent en verschijnt onder Browser als Facebook of Instagram.
4. Leg het naast Ads Manager. Vergelijk de gededupliceerde Purchase-events over dezelfde periode met facebook / cpc plus instagram / cpc in GA4. Een gat boven de 50% is normaal als dit speelt; onder de 20% is dit niet je hoofdprobleem.

Server-side purchase-events via Meta CAPI met de oorspronkelijke fbclid. Veruit de grootste winst, en wat ervoor zorgt dat Ads Manager het juiste getal toont. Vang fbclid op de landingspagina af, bewaar hem bij de bestelling en stuur hem server-side mee met de aankoop.

Een eigen kanaalgroep voor betaalredirects. Vang mollie.com, adyen.com, pay.klarna.com, checkout.stripe.com, paypal.com en de bankdomeinen af als kanaal Betaalredirect. Dan liegt je Direct-bak niet meer en zie je hoe groot het probleem is.

Betaaldomeinen in Unwanted Referrals. Een halve oplossing. Dit dekt het geval waarin de gebruiker in dezelfde browser terugkomt, zoals bij een desktopcheckout. Voor de sprong van in-app naar systeembrowser doet het niets, want dat is een nieuwe cookiepot en geen verwijzing.

Deels:

• De oorspronkelijke UTM's en fbclid meesturen door de redirect-URL. Sommige providers laten je parameters meegeven die bij terugkomst weer meekomen. Overleven ze de rondgang, dan kun je GA4 ze laten uitlezen.
• Koppelen op user_id, als de gebruiker vóór de checkout inlogt, wat de meeste flows niet doen. Het verandert de sessiebron niet, maar herstelt wel het beeld op gebruikersniveau.
• Server-side GA4 via het Measurement Protocol met het oorspronkelijke client_id. In theorie mogelijk, in de praktijk lastig.

Niet:

• fbclid als sessiebron-parameter toevoegen zonder server-side versterking. GA4 leest fbclid niet zoals het gclid leest.
• First-party cookies op je eigen subdomein. Cookies zijn op iOS per app afgeschermd, ongeacht het domein, dus je cookie in de Instagram-browser blijft onzichtbaar voor Safari.
• Gebruikers vragen de pagina in Safari te openen voordat ze kopen. Het effect op je conversie is negatief. Niet doen.

1. Server-side Meta CAPI met fbclid, afgevangen bij binnenkomst en meegestuurd bij de aankoop. Dit is de dragende oplossing.
2. Betaaldomeinen in de lijst met Unwanted Referrals. Goedkoop en voor de hand liggend.
3. Een eigen kanaalgroep met een bak Betaalredirect, zodat je niet langer doet alsof die sessies Direct zijn.
4. Eventueel fbclid en de UTM's meesturen door de redirect-URL, en de rondgang testen op een echte iPhone met Instagram erop.
5. Accepteer dat GA4 je betaalde Meta-verkeer op mobiel onderrapporteert, leg het resterende gat één keer vast, en gebruik Ads Manager met CAPI-deduplicatie als bron van waarheid voor je Meta-ROAS.

Dit is geen taggingfout op jouw site. Het is een structurele botsing: Meta wil gebruikers in de app houden, betaalproviders willen ze om veiligheidsredenen in de systeembrowser, en de cookies ertussen kunnen niet mee.

Je krijgt Meta niet zover dat het links buiten de eigen browser opent, en iDEAL gaat de bank-app niet links laten liggen. Wat je wél kunt: de meting van Meta via CAPI rechttrekken, ophouden te doen alsof de verloren sessies Direct zijn, en de oorspronkelijke campagne door de redirect meesturen als je provider dat toestaat.