Device-Targeting Redirects: One Link, iOS, Android, Desktop

Three operating systems, one link, one revenue total: device-targeting redirects read the user-agent on every click and route iOS, Android, and desktop visitors to the destination that actually works for each of them.

Instead of forcing an iPhone user, an Android user, and a laptop user through the same generic page, a device-targeting redirect sends the iPhone to the App Store, the Android device to Google Play, and the desktop to your web sign-up — from a single URL you share once, with every routed click still rolling up into the channel each visitor came from.

This article covers how device detection works, the app-store and deep-linking patterns, the powerful QR-plus-device combination for physical placements, and where user-agent detection reaches its limits.

It is the device counterpart to routing by location — most real setups combine the two, sending each visitor to the right platform and the right country from the same link.

See cross-device attribution for the journeys that span a phone tap and a desktop purchase.

Why this matters for your revenue

The cost of a wrong-device destination is highest at the exact moment intent is highest.

When someone taps a link to get your app, they are ready to install — and dropping an iPhone user onto a web page, or worse onto the wrong platform’s store, spends that readiness on friction.

Some of those visitors recover by searching the store manually; many simply do not, and the intent evaporates between the tap and the search box.

The problem multiplies because your audience is genuinely mixed.

A social post, an email, an ad, or a printed code reaches iPhone users, Android users, and desktop users in unknown proportions, and you cannot make three separate links for a single tweet or a single QR code on a poster.

So teams either pick one destination and accept that it is wrong for most of the audience, or build a manual chooser page that adds a click and leaks visitors at the interstitial.

Device targeting removes the trade-off: one link, correct routing per device, no interstitial.

Every tap lands on the install button or sign-up flow appropriate to the device it came from, which is the difference between a mobile campaign that converts the intent it created and one that squanders it on a platform mismatch.

Across a launch or an always-on acquisition link, that recovered friction is real installs and real revenue rather than a rounding error.

What device-targeting redirects are

A device-targeting redirect is a single tracked link whose destination is chosen at click time from the visitor’s device type, read from the request’s user-agent.

The link is constant; the destination depends on whether the click came from an iPhone, an Android device, a tablet, or a desktop browser.

How device detection works

Every browser and app sends a user-agent string that identifies the operating system and device class.

The redirect server parses that string, classifies the visitor — iOS, Android, desktop, and often tablet — and matches the classification against your rules before issuing the redirect. Like geo-targeting, this happens server-side in milliseconds and needs no JavaScript on the destination.

Because the user-agent arrives with the raw request, the decision is made before any page loads, so the visitor perceives one seamless jump to the correct place.

iOS versus Android versus desktop routing

The core rule set has three branches.

iOS devices route to your App Store listing; Android devices route to your Google Play listing; desktop browsers route to a web destination, because there is no app to install and a store link would frustrate them.

Each branch is a destination you set once.

The desktop branch is the one teams most often forget — sending a laptop user to a mobile app store is a dead end, and the right desktop destination is usually your web sign-up or pricing page.

Tablets and the in-between cases

Tablets complicate the neat three-way split. An iPad runs iPadOS and may or may not have a tablet-optimised app; a large Android tablet is similar.

Decide explicitly how tablets should route rather than letting them fall through to an unintended branch — usually to the same store as the matching phone platform, unless you have a specific tablet experience.

The same care applies to less common cases: desktop Linux, smart-TV browsers, and in-app webviews all send user-agents that your rules should either handle or send to a safe default.

Device targeting versus a manual chooser page

The alternative most teams reach for without device targeting is a manual chooser — a page that asks “iPhone or Android?” and lets the visitor pick.

It works, but it inserts an extra click and an interstitial where visitors leak, exactly at the moment of highest intent.

A device-targeting redirect removes that step: the visitor goes straight to the right store in one hop, and you still capture which platform they were on automatically rather than relying on them to self-select.

The table contrasts the three common approaches.

App-store routing and deep links

Getting a visitor to the right store is the baseline. Deep linking is the upgrade that carries them past the store to the exact place in your app, when they already have it installed.

Deep links into the app when installed

A deep link opens your app directly to a specific screen rather than to the store or the app’s home.

For a visitor who already has your app, a store link is friction — they do not need to install anything — so the ideal mobile rule tries to open the app via a deep link and only falls back to the store if the app is absent.

Done well, an existing user taps your link and lands on the exact content you pointed at, inside the app, in one step.

This is the difference between “go find this in our app” and “here is this, in our app.”

Deferred deep links for new installs

A deferred deep link handles the harder case: a visitor without the app taps a link to specific content, installs from the store, and then — on first open — is taken to that same content rather than a generic onboarding screen.

The intent that drove the install survives the install.

Deferred deep linking is more involved to set up than a plain store redirect and depends on platform mechanisms, so treat it as an enhancement for high-value flows rather than something every link needs.

Where it matters — a campaign driving installs to a specific offer — preserving intent through the install is worth the setup.

QR codes plus device targeting

Device targeting and QR codes are natural partners, because a printed code is the one placement where you truly cannot make a separate link per device.

One printed code, right destination per scanner

A QR code encodes a single URL, and whoever scans it could be on any device.

Point the code at a device-targeting redirect and each scanner is routed correctly — the iPhone scanner to the App Store, the Android scanner to Google Play, the occasional desktop-webcam scanner to the web.

You print one code and it behaves correctly for everyone who scans it, forever, without you knowing in advance what device each person will use.

Combine it with geo-targeting and the same printed code also sends each scanner to their country’s storefront.

Print, packaging, and event use

This is why device-targeted QR codes dominate physical marketing: packaging, posters, business cards, conference booths, product manuals. The code is committed to print and cannot be changed per audience, so the routing has to be smart behind it.

A booth code that sends every visitor to the right store, a packaging code that opens the app for existing customers and the store for new ones — these turn a static printed asset into an intelligent entry point, and because it is a tracked link, you also learn how many scans each placement drove and what they earned.

The device routing matrix

The table shows a typical rule set. The desktop row and the tablet row are the ones most often left unhandled — set them deliberately.

Setting up a device-targeting redirect

The setup pattern is short and reusable across every device link you build. The steps below assume you want app-store routing with an optional deep link and a QR code.

The setup pattern, step by step

Create the tracked link, set a destination per operating system, optionally add a deep link for installed users, generate a QR code from the same link, and verify on real devices.

The verification step is not optional in practice: user-agent parsing has edge cases, and the only way to be sure an iPhone, an Android phone, and a laptop each land correctly is to click and scan from each.

A rule that reads correctly in the dashboard can still misroute an in-app webview or an unusual browser.

The honest limits of device targeting

User-agent detection is reliable for the common cases and imperfect at the edges. Two limits are worth designing around.

User-agent spoofing and unusual browsers

User-agents can be changed. A user with a desktop browser set to request mobile sites, a privacy tool that alters the user-agent, or an in-app webview with a non-standard string can be misclassified.

These are a small minority, but they exist, so — as with geo-targeting — every destination should be independently usable and there should be a safe default for user-agents your rules do not recognise.

Never make a device rule the only path to something a visitor needs; make it the smart default with an escape hatch.

Detection cannot see installed apps directly

A redirect server cannot reliably know from the user-agent alone whether a visitor already has your app installed — that is why deep linking uses platform mechanisms that attempt to open the app and fall back to the store.

Treat “open the app if present, else the store” as a best-effort behaviour rather than a guarantee, and make sure the store fallback is always correct.

The device class is knowable from the request; the install state is not, and honest setups plan for the fallback path.

How TrackRev handles device targeting

TrackRev routes by device at the redirect and keeps every device link on the same revenue model as the rest of your tracking.

Server-side routing, one revenue model

Each device-targeting redirect is a tracked link on your own branded domain, classified server-side from the user-agent before any page loads.

Because the same first-party pixel records the click, a device-targeted link’s taps tie back to Stripe revenue like any other link — so you get platform-correct routing and per-platform revenue from one object.

For journeys where a visitor taps on a phone and pays on a laptop, see cross-device attribution, which stitches the two into one person.

When NOT to use TrackRev

If you have no mobile app and only a web product, device targeting has little to route — everyone should reach the web, and a plain link is simpler.

If your audience is effectively single-platform, the routing solves a problem you do not have.

And TrackRev is not a mobile attribution SDK for deep in-app event modelling the way a dedicated mobile-measurement partner is — it routes and tracks links to and from your app rather than instrumenting every in-app screen.

It fits teams who share one link across a mixed-device audience and want each device sent to the right place and measured to revenue.

Routing a tap to the right store is only worth doing if you can also see which platform earned — and that needs the click and the charge in one tool.

The default stack splits them: Bitly Growth at ~$35/month can device-route and count taps, but the revenue sits in Rewardful Starter at ~$49/month or a separate analytics tool, $84+/month for two systems you reconcile by platform.

TrackRev is $39/month for link tracking, revenue attribution, and the affiliate programme on one billing connection, so a device-targeting redirect routes each visitor and reports each platform’s revenue in the same dashboard.

One link to share, one number per platform to trust — only when routing and revenue live together.