Device-targeting redirects: one link for the App Store, Google Play and the web

A device targeting redirect is one short link that reads the User-Agent header on each click and answers with a 302 that sends iPhones to the App Store, Android phones to Google Play and desktops to a web page.

Set one destination per device class plus a default. The header separates phones from computers reliably.

It can't tell whether the app is installed, and it misreads spoofed strings and iPads, which have sent a Macintosh string by default since Safari 13 in 2019.

How device targeting redirects work

The browser's GET request carries a User-Agent header. The server sorts it into a device class and replies with a 302 and a Location header, so the visitor sees one hop.

MDN Web Docs prefers feature detection and Client Hints such as Sec-CH-UA-Mobile, but a redirect has no page to run it in.

Its shortcut for phones is to look for Mobi anywhere in the string and treat the rest as desktop.

User-Agent strings and the rule for each device

Opening an installed app with Universal Links or App Links

Universal Links on iOS and Android App Links on Android 6 (API level 23) and later open an installed app straight from the tap. Apple Developer Documentation says the system skips the browser and your website.

The Android App Links guide adds that verified links skip the disambiguation dialog, and Dynamic App Links on Android 15 (API level 35) change the rules without an app release.

An app opened from the tap sends your server no request, so it logs no click unless the app reports the open.

Both files must sit on a domain you control, so a shared shortener can't open your app and a custom tracking domain can.

For a visitor who installs first, Android's Play Install Referrer API gives the app referral data for 90 days through client library 2.2, and the deep linking guide covers the rest.

One QR code for every phone

One QR code serves both stores when it points at a device-targeting redirect, and the destinations can change after the print run, as dynamic versus static QR codes explains.

The free QR code generator recommends printing at least 2 cm (0.8 in) wide with a 4-module margin.

I would scan the final artwork with the camera app before printing, since a scanner inside another app can open an in-app browser.

What changed in device detection: Safari 13 and Chrome 110

In-app browsers and link previews

Preview fetchers take the desktop or default branch, so put Open Graph tags on that page.

The post on bot traffic filtering explains why those clicks are flagged and still redirected, and link tracking not working on mobile covers the rest.

301 versus 302: redirect type and caching

A permanent redirect kept by a browser or CDN pins the first device's answer for everyone behind it, and MDN's redirection guide says crawlers replace the original URL after one.

Google Search Central names Vary: user-agent for URLs that differ by device, so key any CDN cache the same way or skip caching.

Routing by country as well

Country routing resolves the click's IP address to a country and picks the destination mapped to it. MaxMind's accuracy page estimates 99.8% for country, so route on country and nothing finer.

A VPN user appears at the VPN's server, so write a default for every unmatched country, route price by country and language by the Accept-Language header, and keep legal restrictions in the destination.

Setting up device rules in TrackRev

TrackRev stores the country and city of every click but routes by device only.

The Add device targeting option on the link form takes a mobile destination and a desktop destination, and a blank field falls back to the main URL.

Phones share the mobile field, tablets take the main URL and an iPad in default mode takes the desktop field.

One mobile field means one phone destination, so split iPhone from Android with a page on your own domain, or use one link per store. This route handler does the first.

1import { NextRequest, NextResponse } from "next/server";2 3const IOS = "https://apps.apple.com/app/id0000000000"; // your App Store listing4const ANDROID = "https://play.google.com/store/apps/details?id=com.example.app";5const WEB = "https://example.com/signup";6 7export function GET(req: NextRequest) {8  const ua = req.headers.get("user-agent") ?? "";9  if (/iPhone|iPod/.test(ua)) return NextResponse.redirect(IOS, 302);10  if (/Android/.test(ua) && /Mobi/.test(ua)) return NextResponse.redirect(ANDROID, 302);11  return NextResponse.redirect(WEB, 302);12}

Every click row keeps the device class, operating system, browser and country, so counts split by iPhone, Android and desktop on the free plan, which costs $0 and allows 50 links and 1,000 tracked events a month.

Paid plans add the revenue those clicks led to, synced from Stripe, Paddle, Polar or Lemon Squeezy: Starter is $39 a month, Growth $99 and Scale $199, as the pricing page lists.

To open an installed app, enter its identifiers under domain settings and TrackRev serves both association files on your verified custom domain.

It is not a mobile measurement partner, so in-app event attribution needs a tool such as AppsFlyer or Adjust.

Testing before you publish or print

Running curl with the iPhone string from the table prints the 302 status line and the Location header, so you can confirm the rule before picking up a phone.

curl -s -o /dev/null -D - \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1" \
  https://go.example.com/app