Deep links for app marketing: what a shortener can and cannot do

A campaign that sends every tap to an App Store listing throws away the people who already have the app. They land on a page offering to install what is already on their phone, tap Open, and arrive at the home screen with no memory of what they clicked.

That is the whole problem, and most of it is solved before a shortener is involved.

The four destinations one campaign needs

Write them down before you build anything.

Someone on iOS with the app installed should land on the screen the campaign is about. Someone on iOS without it should reach the App Store. Android splits the same way against Play. Desktop cannot open your app at all and should get the web version of the same content.

Universal Links on iOS and App Links on Android collapse the first two into one URL each. Both are ordinary https:// URLs that the operating system claims on behalf of the app, verified through a file your domain serves — apple-app-site-association for iOS, assetlinks.json for Android. Installed, the tap opens the app. Not installed, the same URL loads your web page, and your web page can carry a store banner.

Four cases become two rules and one default.

What gc.mw does with them

Device rules hold one destination for ios, one for android and one for desktop. The redirect path decides device family from the user agent with two regular expressions and no parsing library: iPhone, iPad and iPod are iOS, Android is Android, everything else is desktop. That is deliberately crude, and crude in the right direction — it never guesses wrong about which app store to send someone to.

Every destination, including each device target, goes through the same validator as any other link: it must be http or https. A custom scheme is refused at the schema. That is an opinion rather than a limitation. A custom scheme fails silently on a phone without the app, and silence is the worst outcome for a link you have already printed on a banner.

Building it

1. 1

   Get the association files serving first

   Your Universal Link and App Link do nothing until Apple and Google can fetch the verification files from your domain over https with no redirects. Test that before you create the short link, not after.

2. 2

   Create the link with the web page as the default

   The default destination is what desktop visitors and anything unrecognised will get. Make it the page a stranger should see, not a store listing.

3. 3

   Add the two device rules

   iOS gets the Universal Link, Android gets the App Link. If your app ships on only one platform, set that one rule and leave the other alone — an unset branch falls through to the default.

4. 4

   Trace every hop before you publish

   Store links redirect several times, and a chain that drops from https to http breaks the association check. Paste each of the three destinations into the redirect checker and read the codes.

What the numbers show afterwards

Each click records its device family, so the device and operating-system breakdowns split iOS from Android whether or not you set rules. When rules are set, the click also records which branch it took — device:ios, device:android, device:desktop — and that arrives as its own breakdown alongside the rest.

The comparison worth making is that branch split against your install numbers from App Store Connect and Play Console for the same days. A large iOS branch with flat installs usually means the Universal Link is opening the app for people who already have it, which is the campaign working. A large branch with no movement in either number means the link is being clicked and abandoned, which is a landing-page problem, not a targeting one.

Where this stops

A shortener sees one HTTP request and then never hears from the visitor again. It cannot know that a tap led to an install, and it cannot hand the app a destination after that install completes. Deferred deep linking is a different product category: an SDK inside your app asks an attribution service, on first launch, whether a pending link exists for this device.

If you need that, buy it. If what you need is iOS, Android and desktop pointed at three URLs you already have, behind one short link and a QR code you can repoint later, device rules are the whole job. They are a Business feature, set on the link, with no code anywhere.

Targeting sits on top of ordinary branded links, so the custom alias, the QR code and the editable destination all still apply to the same link.