A playable ad earns something no other format does: the user tells you what they want. They pick a character, a colour, a plan, a destination. Then they tap Install, and almost every implementation throws that information away and drops them on a generic store page or homepage. This guide covers how to carry the choice through the click — what genuinely works, and the two widely-repeated approaches that quietly do not.
The part everyone gets wrong: store links
The intuitive approach is to append a parameter to the store URL. It does not work, for different reasons on each platform.
- iOS has no install referrer at all. Attribution runs through SKAdNetwork and Apple passes no arbitrary payload from a store link into a fresh install. Nothing you append survives.
- Google Play does record an install referrer — but it records the one from whichever click URL actually reached the store. In a network campaign that is the ad network's own tracking URL, not yours. Your parameter is replaced before it arrives.
This is why a dressed-up store link tests perfectly on your own device and silently delivers nothing in a live flight. You clicked it directly; a real user's click went through the network first.
What this rules out
Any tool or guide offering "deep links on your App Store URL" for playable ads is describing something that works on a bench and not in a campaign. Ask specifically what happens when the network's own click URL is in the chain.
What does work: a web destination
If your click-through goes to a web page, everything is straightforward. Choices append as ordinary query parameters and the landing page reads them:
- https://yourbrand.com/build?colour=midnight-blue&trim=m-sport
- https://shop.com/p/air-max?colour=blue&size=9
- https://book.com/search?to=lisbon&nights=4
Values should be sanitised before they travel — spaces converted, punctuation stripped — so nothing breaks the URL. A parameter can also sit in the path rather than the query if your routing prefers it.
What works for apps: the MMP tracking link
To reach an app with the choice attached, the click has to go through your mobile measurement partner's link rather than the store directly. The tracking link is the click: it redirects to the correct store per platform, and the MMP hands your value to the app on first open. That is deferred deep linking, and it is the only mechanism that survives an install.
Each provider reads a different parameter, and — this catches people out — expects a different shape of value:
- AppsFlyer OneLink — deep_link_value, plus deep_link_sub1 through sub10 for additional values. Takes a bare token such as 3series.
- Adjust — deep_link. Expects a full URI such as myapp://product/3series, not a bare token.
- Branch — $deeplink_path. Expects a path such as product/3series.
- Singular — _dl (with _ios_dl and _android_dl variants). Expects a full URI, and URL-encoding is mandatory.
- Kochava SmartLink — deeplink. Expects a full URI.
The AppsFlyer detail worth knowing
For a newly installed app, AppsFlyer's Unified Deep Linking returns only deep_link_value and deep_link_sub1–10. Arbitrary custom parameters come back empty on a deferred install — the exact journey the feature exists for. If you are sending three choices as three custom parameters, two of them are silently lost for every new user.
Do you still need store URLs?
No. A tracking link routes to the correct store itself when the app is not installed, and handles desktop and web fallbacks through settings in your MMP dashboard. Once one is configured, store URLs become optional — the click never uses them.
The network limitation to plan around
Three networks decide the click destination themselves and pass no URL: Google Ads, Meta and Mintegral. On those, neither a custom destination nor a dynamic parameter can travel, because there is no URL to attach it to. Unity, AppLovin and ironSource honour a URL but their specs ask for a store destination, which a tracking link satisfies. Plan the feature for the networks that can carry it, and expect a good export tool to warn you where it will be ignored rather than letting you assume otherwise.
Agree the vocabulary before the campaign
A value like blue only means something if your app has been built to route on it. The MMP delivers the value; what it opens is your app's code. Settle the list of expected values with your developer before the flight rather than after, and keep it short — a handful of stable tokens beats a sprawling schema nobody implements.
More than one choice, and lists
Most real creatives record several things — a product, a size, a colour — and some record a set rather than a single value, such as a basket built from three taps. Two patterns cover almost everything.
- Set — one value that replaces the previous one. Correct for a colour, a plan tier, a destination. A second tap should overwrite the first, not add to it.
- Accumulate — a growing list, joined into one parameter such as items=112,349,507. This is the e-commerce case, and it is impossible with set-only handling because the second tap wipes the first.
- Toggle — add on tap, remove on second tap. What users expect from a selectable tile, and worth having if your interaction involves choosing multiple items from a grid.
Whichever you use, sanitise values before they travel and keep the total payload short. Long payloads get truncated somewhere in the redirect chain — often silently, and usually at the end, so you lose the last parameter rather than getting an error.
Placing a value in the path
Not every destination reads query parameters. If your landing page routes on the path — /p/12345 rather than /product?id=12345 — a placeholder pattern is cleaner than appending. Define the destination as a template such as https://shop.com/p/{{sku}} and let the recorded value fill it. The same applies to MMP links that expect a URI or path shape rather than a bare token, which is exactly what Adjust, Singular, Kochava and Branch require.
One value can only appear once
If a URL already carries the parameter you are setting — common when a tracking link is copied from a dashboard with a sample payload on it — appending a second copy means the same key is present twice. Most servers read the first occurrence, so the dashboard's frozen sample beats the player's real choice. The live value has to replace the sample, not sit after it.
What to measure
The point of this feature is downstream, so measure downstream. Compare conversion rate on sessions that arrived with parameters against those that did not, and segment by the value itself — the users who chose the premium tier in the ad are a different cohort from those who chose the entry tier, and often worth targeting differently. If your landing page can report on the incoming parameters, you also get a free read on which options the creative is actually driving demand for, which is useful merchandising information regardless of the campaign.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker