AppsFlyer OneLink and Instagram's in-app browser

Why can OneLink fail inside Instagram?

• Nothing is misconfigured. A OneLink is an HTTPS link, so inside Instagram it opens in Instagram’s in-app browser like any other link.
• From there, the hand-off to the App Store can fail without reporting anything. The visitor sees a blank page and leaves.
• Attribution is not involved. The failure happens before the install, in a web view. Your SDK is not running yet and could not intervene if it were.
• So no SDK version, OneLink template or dashboard setting is the fix. What has to change is where the visitor is standing when they reach your OneLink.

Check whether this is your problem

It takes two minutes on a real phone, from a real profile: tap your OneLink from Instagram and watch what happens, then paste the same link into Safari or Chrome on the same phone to compare.

1. Tap your OneLink from Instagram. Watch what happens after the page starts loading.
2. Paste the same OneLink into Safari or Chrome on the same phone.

If the second opens the store and the first does not, this page is about you. If clicks in AppsFlyer look healthy while installs from that channel do not, that gap is the same failure counted from the other end — the click is recorded, the user never arrives.

Why no SDK can reach this

A measurement platform earns its keep after the store: it recognises the install, matches it to the click, and hands your app the campaign that produced the user. All of that requires the app to exist on the device.

The in-app browser failure happens one step earlier. Instagram opens your link in a web view inside its own app; reaching the App Store means leaving that web view and handing the visitor to another application, and in-app browsers frequently decline that hand-off without reporting anything. No error, no fallback, no install — and therefore nothing for AppsFlyer to attribute. The click is in your dashboard. The user is not.

Adding, upgrading or reconfiguring an SDK cannot change this, because at the moment it fails there is no app to run the SDK.

AppsFlyer does publish guidance on in-app browsers, and it points at OneLink’s landing page templates. Whether that clears Instagram for your app is something to tap through on a phone, not something to assume — for their answer or for anyone else’s.

What you can do

Three options exist, in the order most teams should consider them: telling people to open the link in a browser, trying the landing-page templates AppsFlyer already includes, or putting something in front of the OneLink that leaves the web view before the hand-off.

1. Tell people to open the link in a browser. Free, immediate, and it works. It also costs you a large share of the traffic you paid for, because the instruction is one more thing between a curious person and your app.
2. Try the landing page templates you already have. They are included in what you are paying AppsFlyer for. Test one from a real Instagram profile before you believe it.
3. Put something in front of the OneLink that leaves the web view. The visitor does nothing, and your measurement setup does not change.

If you take the third option

The two products do not overlap: the failure is in the web view, and the attribution is after the install. So one can sit in front of the other.

1. Keep your OneLink exactly as it is. Same template, same parameters, same reporting. Nothing about your AppsFlyer setup changes.
2. Create an AppIn link whose destination is that OneLink. The four attribution providers’ link domains are accepted as iOS and Android targets by name, so this pairing is a supported use rather than a workaround.
3. Publish the AppIn link where in-app browsers are the norm: Instagram and TikTok bios, stories, direct messages. Everywhere else, the OneLink is fine on its own.
4. Verify on a real device. Tap it from a real Instagram profile, and confirm both that the store opens and that the click shows up where you expect it.

What changes is where the visitor is standing when they reach your OneLink: a normal browser rather than a web view, which is the environment it was designed for.

Two things we will not claim. We do not do install attribution, deferred deep linking or fingerprinting — that is AppsFlyer’s half and we are not an alternative to it. And we will not predict what your attribution numbers do afterwards; we do not measure installs, and a promise about another vendor’s reporting is not ours to make. Read it in your own dashboard.

One note on the first row: the way out is an escape from the in-app browser, not a better attempt at the hand-off from inside it. The page asks the host app to reopen itself in the phone's real browser and the store opens from there, on load, with nothing for the visitor to tap. Where there is no in-app browser to leave, the link opens the store the ordinary way.

This is not specific to AppsFlyer

Branch, Adjust and Singular links meet the same wall inside an in-app browser, for the same reason: they are HTTPS links that have to hand off to a store app from a web view. If you use one of those instead, everything above is identical.

The full explanation of what fails and why