Why Meta Ads purchases vanish in GA4: the in-app browser

Meta Ads Manager says your campaign drove 47 purchases this week. You open GA4, filter to facebook / cpc and instagram / cpc over the same range, and find 12. The other 35 sit in (direct) / (none) or under a mollie.com / referral row nobody put there on purpose.

Nothing is broken in your tags. It is a structural problem in how Meta opens links, how payment providers behave on mobile, and how GA4 reads cookies.

When someone taps a link inside Facebook or Instagram, Meta does not open Safari or Chrome. It opens its own embedded browser: a WKWebView on iOS, a Chromium-based one on Android.

That browser has its own cookie jar, fully sandboxed from the system browser. Cookies set in one cannot be read by the other. They behave as if they belong to different devices. Meta keeps users in-app because it preserves session metrics and produces first-party signal, which matters more since App Tracking Transparency gutted IDFA-based measurement.

A typical mobile path from Meta ad to purchase on iOS:

1. The user taps your ad in Instagram.
2. The landing page opens in the in-app browser. GA4 fires, the _ga cookies land in the in-app cookie jar, and fbclid sits on the URL.
3. The user browses, adds to cart, goes to checkout. Cookies still live in the in-app browser, GA4 still tracks the same session.
4. Checkout redirects to the payment provider: Mollie, Adyen, Stripe, Klarna, PayPal, an iDEAL acquirer.
5. The provider runs 3DS, or opens the banking app for iDEAL or Apple Pay.
6. The return URL opens in the system browser, not back in the in-app browser. That is the OS deciding where a universal link lands, and most banking apps and providers force it.
7. The user reaches your thank-you page in Safari. GA4 fires, but the cookie from step two lives elsewhere. GA4 sees a brand new visitor, a brand new client_id, a brand new session.
8. The referrer is the payment provider, so the purchase gets attributed to (direct) / (none) or provider / referral.

By the time the purchase fires, the original Meta click is invisible to GA4. Meta still counts it, because its Pixel and CAPI pipeline leans on fbclid and the deduplicated server-side event rather than on cookies in the system browser. That is why Ads Manager looks healthy while GA4 does not.

This is not theoretical. On the average Dutch store with iDEAL as the dominant payment method, this one mechanism accounts for most of the (direct) purchase share above the noise floor.

Plenty of people browse from the in-app browser without breaking anything. Reading an article, signing up, even adding to cart all stay inside the same cookie jar and attribution survives.

It breaks at payment because iDEAL on mobile launches the banking app, and the return runs through a universal link that the OS opens in the default browser. The in-app browser is never re-entered.

3DS challenges open in the system browser on some integrations, especially when the in-app browser fails the device-fingerprint checks the issuer wants. Apple Pay and Google Pay sheets can complete in-app, but the success redirect still pops out. PayPal's app-switch forces the return URL into the system browser on iOS outright.

Providers differ. Mollie with iDEAL is the most consistent offender on Dutch stores, with Adyen, Klarna and Stripe producing the same broken handoff.

Four checks, each a few minutes:

1. The Direct share of purchases. In Traffic acquisition, filter the event to purchase. Above 30% Direct on an ecommerce site means something systemic is breaking.
2. The referrers behind them. Switch to Session source / medium and look for mollie.com / referral, adyen.com / referral, pay.klarna.com / referral, checkout.stripe.com / referral, paypal.com / referral or banking domains.
3. The user agent. Build a free-form exploration with Browser and Operating system. Meta's iOS in-app browser carries FBAN, FBIOS or Instagram in the user-agent string and shows up under Browser as Facebook or Instagram.
4. Reconcile with Ads Manager. Compare the deduplicated Purchase events over the same range against facebook / cpc plus instagram / cpc in GA4. A gap over 50% is normal when this is active; under 20% means it is not your main problem.

Server-side purchase events via Meta CAPI with the original fbclid. The single biggest win, and what makes Ads Manager show the right number. Capture fbclid on the landing page, store it on the cart or order, and send it server-side with the purchase.

A custom channel group for payment redirects. Capture mollie.com, adyen.com, pay.klarna.com, checkout.stripe.com, paypal.com and the banking domains as a Payment redirect channel. Your Direct bucket stops lying and you can see the size of the problem.

Payment provider domains in Unwanted Referrals. A partial fix. It handles the case where the user returns to the same browser, such as a desktop checkout. It does nothing for the in-app to system-browser jump, because that is a new cookie jar rather than a referral.

Partly:

• Passing the original UTMs and fbclid through the redirect URL. Some providers let you append parameters that come back on return. If they survive the round trip, GA4 can be configured to read them.
• user_id stitching, if the user logs in before checkout, which most flows do not. It will not change the session source but it does repair the user-level picture.
• Server-side GA4 through the Measurement Protocol with the original client_id. Possible in theory, hard in practice.

Does not:

• Adding fbclid as a session-source parameter without server-side reinforcement. GA4 does not read fbclid the way it reads gclid.
• First-party cookies on your own subdomain. Cookies are scoped per app on iOS regardless of domain, so your cookie in Instagram's browser stays invisible to Safari.
• Asking users to open the page in Safari before buying. The conversion impact is negative. Skip it.

1. Server-side Meta CAPI with fbclid captured at landing and sent at purchase. This is the load-bearing fix.
2. Payment provider domains in the Unwanted Referrals list. Cheap and obvious.
3. A custom channel group with a Payment redirect bucket, so you stop pretending those sessions are Direct.
4. Optionally pass fbclid and the UTMs through the redirect URL, and test the round trip on a real iPhone with Instagram installed.
5. Accept that GA4 will under-report Meta paid traffic on mobile, document the gap once you have reduced it, and use Ads Manager with CAPI deduplication as the source of truth for Meta ROAS.

This is not a tagging mistake on your site. It is a structural mismatch: Meta wants users in-app, payment providers want them in the system browser for security, and the cookies in between cannot follow.

You cannot make Meta stop opening links in its own browser, and you cannot make iDEAL stop launching the banking app. What you can do is fix Meta's measurement through CAPI, stop pretending the lost sessions are Direct, and pass the original campaign through the redirect where your provider allows it.