AppsFlyer OneLink vs AppIn: they are not the same kind of thing

First: which OneLink are you comparing?

Two products share the name and they are not related. AppsFlyer OneLink is the deep-linking and attribution link inside AppsFlyer’s measurement platform, and it is the subject of this page. onelink.to is a small app-link tool with published $10/mo pricing; if that is the one you meant, the onelink.to comparison is the page you want.

Four questions that settle it

Answer these before reading any table.

1. Do you buy installs from ad networks and need to know which network produced which user?
2. Does a brand-new install have to land on a specific screen with a payload attached — an invite or referral flow?
3. Do you need fraud filtering, or do partners need their own reporting?
4. Does somebody in your organisation reconcile ad spend against cohort revenue?

Any yes: you need AppsFlyer, and nothing on this page is trying to talk you out of it. Those capabilities require code running inside your app after the install, and AppIn does none of them. Skip to the last section, which is about running both.

All no, and you do not want an SDK in your app: the rest of this page is for you.

What each product actually is

AppsFlyer OneLink is one component of a mobile measurement platform. Its job is to carry a user from a click through the store and into your app with the campaign context intact — deferred deep linking, install attribution, and the reporting your acquisition budget is defended with. For any of that to work, the AppsFlyer SDK has to be in your app and your account has to be on a plan sized to your install volume.

AppIn is a link. You paste an App Store or Play URL, you get back one URL to publish, and nothing is added to your app. It routes by device, renders a page built from your store listing, and composes the campaign parameters the stores themselves report on. No SDK, no integration work, no sales call.

Different categories of product — which is why the useful comparison is job-by-job, not feature-by-feature.

The comparison, by job

AppsFlyer rows are from their own site and documentation as read on 2026-08-10. “Not documented” means their public materials do not describe the feature — it is not a claim that the platform lacks it, and nothing in that column is a test result. We are not quoting an AppsFlyer figure for your account because we have not been billed one; ask them for the number that applies to your volume.

What OneLink does that AppIn will never do

AppIn does no install attribution, no deferred deep linking and no fingerprinting. Not “not yet” — those capabilities need code running inside your app after the install, and putting an SDK in your app is precisely the cost our users are trying to avoid. A product promising them without an SDK would be a product lying to you.

That is the whole of the gap, stated plainly so you do not have to infer it from a table.

The failure that puts both products in the same setup

This is the part that surprises people, and it is why the answer is often “both” rather than “either”.

A OneLink is an HTTPS link. Published in an Instagram bio, it opens in Instagram’s in-app browser like any other link — a web view running inside the Instagram app. Reaching the App Store from there 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 lands in your dashboard; the user does not land in your app.

An SDK cannot help, because at the moment it fails there is no app on the device to run it. Branch, Adjust and Singular links meet the same wall, for the same reason.

An AppIn link leaves the web view before the store hand-off: the page asks the host app to reopen it in the phone’s real browser, and the hand-off then happens where it works. It runs on load, so the visitor has nothing to tap. This runs on iOS and on Android where the host app uses an in-app browser too — measured on real devices, not assumed. Where there is no in-app browser to leave — a real browser — it opens the store the ordinary way.

AppsFlyer does publish guidance on in-app browsers, and it points at OneLink’s landing page templates rather than at anything that leaves the web view. We have not tested those templates and will not imply a result we do not have — tap one through from a real profile on a real phone and you will know in two minutes. That is also the right way to test ours.

Campaign separation without an SDK

Apple’s App Store reads a campaign token (ct) alongside a provider token (pt) — leave the provider token out and the campaign never appears in App Store Connect at all. Google Play reads UTM values inside a referrer parameter. Both are easy to assemble slightly wrong, which is why so many published links carry a campaign token that shows up in no report anywhere.

An AppIn link composes the Apple ct and the Play referrer — utm_source and utm_campaign — on every click, from the campaign name on the link and the source it can see. The provider token stays yours: you paste your pt in once, and it is sent with every click after that. It is not a value anyone can generate on your behalf.

None of that is attribution and we do not call it that: it tells you which campaign the traffic came from in the reporting you already have, and it stops there.

It is worth being exact about the overlap, because “AppsFlyer already does this” is the obvious objection and it is only half right. AppsFlyer does put its own click data in Play’s install referrer — that is how it attributes Android installs, and it is documented as their primary Android method. What their materials do not describe is composing the parameters the stores’ own consoles report on: App Store Connect’s campaign and provider tokens appear nowhere in their help centre, and the Play referrer they send is theirs, not your utm_source. So if the report you read is AppsFlyer’s dashboard, this adds nothing. If it is App Store Connect or Play Console, it is the difference between a campaign that appears there and one that does not.

Running both, which is a supported setup

Because the failure is in the web view and the attribution is after the install, the two products do not overlap: one can sit in front of the other by keeping the OneLink as it is, pointing a new AppIn link at it, publishing that AppIn link where in-app browsers are the norm, and verifying on a real phone from a real profile.

1. Keep your OneLink exactly as it is. Same template, same parameters, same reporting — your AppsFlyer setup does not change.
2. Create an AppIn link whose destination is that OneLink. Four attribution providers — AppsFlyer, Branch, Adjust and Singular — have their link domains accepted as iOS and Android targets by name, so this is a supported pairing 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 phone from a real profile, and check both that the store opens and that the click appears 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. What we will not do is predict what your attribution numbers do afterwards. We do not measure installs and we will not make promises about another vendor’s reporting — read it in your own dashboard.

Which one to pick

• AppsFlyer OneLink, if you answered yes to any of the four questions at the top. Nothing here replaces that.
• AppIn, if you have no SDK and do not want one, and your links live where in-app browsers eat them.
• Both, if you have AppsFlyer and your social traffic underperforms every other channel by a margin nobody has been able to explain.