How deep links route paid taps

What deep links do#

A deep link is the address that carries a tap from an ad to a specific custom product page rather than the default listing. Each ad variation carries the link for its page, so category searchers, brand searchers and seasonal shoppers each land on proof written for them. Without correct routing, tailored creative collapses into generic landings and the whole custom page library earns nothing. Apple own custom product page docs define how pages are addressed.

Start from the Apple Ads hub for the family view, with CPP setup building the destinations these links serve.

Universal links carry the tap#

On Apple platforms, universal links open app content or store pages smoothly where configured, and the same routing discipline applies to paid landings: one link, one destination, tested on device. Keep link tables explicit with each ad variation mapped to its page, rather than relying on memory or naming luck. Confirm current linking behaviour in Apple own App Store Connect guidance before launch, since platform handling evolves.

The Connect linking guide covers account wiring, while ad variations carry the links into live traffic.

One variation, one destination#

With 35 custom ads allowed per ad group, one group can serve many tailored messages, yet each variation needs exactly one verified destination. Map variations to pages in a sheet showing ad name, destination page, audience and launch date, and review it before every budget change. Stray edits that repoint variations without updating the sheet corrupt reporting for weeks, so lock editing rights to named owners. Treat the sheet as a live contract, not launch paperwork filed and forgotten.

Read routing results through creative reporting, which ties page performance back to the variations that fed it. Apple own ad variation docs describe how variations carry these links.

Preflight every link#

Test each link on a real device before launch: tap the ad preview, confirm the correct custom page opens, check frames and text match the promise, and verify back navigation behaves. Repeat after every page review approval and every app version release, since both can shift routing or content. Log test dates per link so audits can always prove coverage rather than assume it. A ten minute preflight routine prevents the most embarrassing spend in the account.

Pair link preflights with creative checks from the screenshots guide so destination proof always matches the ad promise exactly.

Breakage recovery playbook#

When routing breaks, symptoms show fast: tap through holds while page conversion collapses, or a page suddenly receives traffic its proof never promised. Pause affected variations first, verify the destination mapping, then repoint or rebuild before resuming spend. Keep one known good variation live per ad group during fixes so learning does not fully reset. Document every incident with cause and fix, because routing faults repeat across launches and seasons.

For bid and budget behaviour during pauses, see the TTR diagnostics guide before touching bids in panic.

Scale without tangles#

Scale by cloning proven routing patterns, not by improvising per launch: new audiences get new pages with new links following the same sheet discipline. Retire links alongside their pages so dead destinations never linger in trafficking docs. Quarterly, audit every live variation against its listed destination and prune orphans. Tidy routing compounds quietly into cleaner tests, faster launches and calmer reporting, which is exactly what growing accounts need most.

When the library outgrows its sheet, ask our team for a routing audit that reconciles variations, pages and links.

Frequently asked questions#