Facebook ad clicks that never reach the App Store

The dashboard shows clicks. The store shows nothing. Between them sits Facebook's own browser, which cannot pass an App Store link to the App Store, and which blocks every workaround more often than any other platform we measure.

5 August 2026 by PAD team. Escape rates measured on 730 routed taps.

Which campaigns lose taps and which do not

The split is clean, and it explains why some advertisers never see this while others lose a fifth of their traffic.

App install campaigns are safe because Meta never opens a browser: the Install button talks to the store directly. Everything else routes through the WebView, and an App Store URL inside a WebView is a dead end.

There is an awkward second-order effect here. Meta refuses raw apps.apple.com URLs as destinations in traffic campaigns, so advertisers put a landing page or a tracker link in between. That workaround is precisely what drops the tap into the in-app browser.

Why the tap dies

Apple answers every request for a store URL with a redirect into a custom scheme:

GET https://apps.apple.com/us/app/example/id123456789
→ 302 Found
  Location: itms-appss://apps.apple.com/us/app/example/id123456789

Safari treats that as an instruction to close the page and open the App Store. A WebView has no handler for the scheme and no permission to hand it to another app, so navigation stops. The page stays blank, no error is raised, and the visitor closes it.

The full mechanism, including what Apple and Meta each get out of the arrangement, is in the main write-up.

Facebook is the hardest platform to escape

Instagram ships an undocumented scheme, instagram://extbrowser/?url=, that hands a URL to the system browser. Facebook has no working equivalent. That single difference shows up in the numbers:

One Facebook tap in five cannot be routed automatically by any method we know of. Those visitors have to be asked to open the page in their browser, and about half of them do it.

It got harder recently. Since iOS 26, some Facebook builds have stopped adding FBAV or FBAN to the user agent, so the browser no longer announces itself. Detection now has to treat an unmarked iOS WebView as suspicious rather than assume it is Safari. If your own detection code was written before that change, it is currently sending Facebook traffic down the wrong branch.

What this costs

Work it through with round numbers. A traffic campaign at $0.40 a click, 10,000 clicks, $4,000 spent. Every tap lands in the in-app browser. If a fifth cannot be rescued, that is $800 spent on taps that reached nothing, and the ad dashboard still reports 10,000 clicks and a healthy CTR.

This is why the problem survives so long in accounts. Nothing in Ads Manager marks a dead tap. The click is counted, charged and reported. The gap only shows up as a mismatch between click volume and installs, which most teams attribute to creative or to product-page conversion.

If your click-to-install ratio looks bad on traffic campaigns but fine on install campaigns, the creative is not the problem. The browser is.

What to change

1. Use install objectives where you can. They bypass the browser entirely. Everything below is for the cases where you cannot.
2. Put a routing link at the end of the funnel, not a raw store URL. The tap has to leave the WebView before Apple's redirect fires.
3. Show the manual button early. On Facebook, waiting two seconds for a scheme that will not fire just costs you the visitor. Around 1.4 seconds is where we settled.
4. Keep the attribution link. Point the escape at your OneLink, Branch or Adjust URL rather than at the store, and the tracker keeps working.
5. Measure the escape, not the click. Until you count how many taps actually left the browser, you are optimising against a number that includes the dead ones.