Device-targeted links: sending iOS, Android and desktop apart

The redirect path gets one shot at deciding who this visitor is, and it has to decide in the time it takes to read a cached record. No database write, no network call, no user-agent parsing library. That budget is why device targeting has three branches instead of thirty, and it is worth understanding before you plan a campaign around it.

The three branches

ios matches a user-agent string containing iPhone, iPad or iPod. android matches Android. Everything else is desktop.

That is the whole classifier: two case-insensitive regular expressions and a fallback. A Windows laptop, a Linux server, a smart TV, a fridge browser and a user agent that is an empty string all land in desktop.

The honest framing is that this answers one question well — which app store, or which mobile experience — and refuses to pretend it can answer others. A rule set that needed to tell a Samsung tablet from a Pixel phone would need a parsing library on the hot path, and a parsing library on the hot path is a database of regular expressions run on every single redirect.

When a device rule earns its place

App campaigns. iOS to the Universal Link, Android to the App Link, desktop to the web page. This is the case the feature exists for.

Anything with an app-only feature. A "book a table" flow that only works in your app on mobile and only works on the web on desktop.

Print that ends up in both hands. A conference badge QR scanned by a phone should open the schedule; the same short link typed into a laptop at the hotel should open the full agenda page.

Store listings you want kept honest. Send both mobile branches to your store pages and desktop to a page explaining the app, rather than to a store listing that desktop cannot install from.

When it does not

A responsive site does not need device rules. If the destination already adapts, adding a rule creates a second place where the routing lives and a second place for it to go stale. The test we use internally: if the two destinations would show the same content, delete the rule.

Nor should a device rule be used to hide something from desktop. Anyone can change a user-agent string in two clicks of a browser's developer tools, so a device branch is a convenience, never a control.

Setting it up

1. 1

   Write down the default first

   The default is what desktop and every unrecognised agent will get. Everything else is an exception to it.

2. 2

   Add only the branches that differ

   Leave a branch empty when its destination would equal the default. Fewer rules, fewer things to update when a URL changes.

3. 3

   Check each destination on its own

   A device rule cannot be tested by clicking the short link from your desk. Check each target URL directly — status, certificate and redirect chain — and confirm it does not itself redirect by device.

4. 4

   Read the variant breakdown after a day

   Each click records which branch it took as device:ios, device:android or device:desktop. If a branch has no traffic, the rule is either wrong or unnecessary.

The interaction people miss

Rules are evaluated in one fixed order: country, then device, then any A/B split, then the default. The first match wins and stops evaluation.

So a link carrying a geo rule for India and a device rule for iOS sends an Indian iPhone to the India destination and never looks at the device rule. This is not a bug we intend to fix — a first-match ladder is predictable, and predictable is what you want from something that decides where a printed QR code goes. If you genuinely need both dimensions, the second one belongs inside the first one's destination.

Device targeting is a Business feature and applies to the same branded links as everything else, so the alias, the QR code and the editable destination all still work on a link that routes by device.