One link. Every device. The right screen.
Four things happen between a tap and the right screen. Watch them run on the right; here is what each one does.
- 1
Tap
Someone taps your link in an ad, an email, a QR code or a DM. It is the same link everywhere.
- 2
Detect
LinkTrail reads the device and browser on the tap itself. Nothing has to be installed for this to work.
- 3
Decide
A phone without the app goes to its store. A phone with the app opens it straight away. A desktop gets the web version.
- 4
Land
The first open lands on the screen they tapped for, promo applied, and the install is credited to its campaign.
Free up to 5,000 MAU · no card required · no advertising identifiers
User clicks link
LinkTrail detects device
We instantly identify the user’s device and browser
- iPhoneSafari
- AndroidChrome
- DesktopBrowser
Right destination, automatically
/promo/summerSUMMER50 applied
What happens at each step?
The animation shows the route. This is what LinkTrail does at each point on it.
What does the link carry?
A LinkTrail link is an ordinary https URL on your own link domain, or on a free linktrail.io subdomain. The link's identity is its short path, and everything else — the in-app destination, a fallback for each platform, and custom data such as a voucher code or a referrer ID — is configured on the link itself rather than carried in the query string. That is why one link can go in an ad, an email, an SMS, a QR code and a creator's bio and behave the same way in each.
How does LinkTrail know which device tapped?
From the tap itself. The platform comes from the request the browser makes when the link resolves, so nothing has to be installed on the phone for routing to work, and no advertising identifier is involved at any point.
Where does each device go?
Whether the app is installed decides almost everything. When it is, the operating system usually opens it before the web is involved at all: Universal Links on iOS and App Links on Android, verified through association files that LinkTrail generates and hosts for your link domain. When it isn't, the tap has to go through the store, and the job becomes carrying the destination across the install. Some in-app browsers never hand a URL to the operating system, so the hosted fallback page can still route onward through your app's custom scheme.
| Who taps | Where they go |
|---|---|
| iPhone with the app | The app opens at the linked screen, via Universal Links. |
| Android with the app | The app opens at the linked screen, via App Links. |
| iPhone without the app | The App Store — then the first open lands on the linked screen. |
| Android without the app | The Play Store — then the first open lands on the linked screen. |
| Desktop | The web fallback set on the link. |
How does the first open land on the right screen?
The SDK asks, on the app's first launch, whether this install belongs to a recent click. On Android the Google Play Install Referrer answers exactly; on iOS the primary signal is a click token the tapped link leaves on the clipboard, read by default only when the user taps a paste control. Where neither is available and the workspace has enabled it, matching falls back to the install's IP address and platform — consent-gated, and recorded as probabilistic rather than certain.
Once there is a match, one onLink handler receives the same link object a returning user's tap would deliver: the path to route to, plus the custom data. Consent gating is on by default, so attribution waits for your app's setConsent call; on Android a fresh install's deferred link waits for it too, while iOS and re-engagement links route immediately.
Go deeper
Each step has a page of its own: what deep linking is, how the destination survives the install, how the install is credited, and the exact matching rules.
Questions about your setup?
Email support@linktrail.io or see the plans, starting with a free tier.