Deep Linking for Push: Open to In-App Action

A re-engagement push lands on a user's lock screen, the user taps it, the app opens to the home tab, and the user has to remember which notification they tapped before they can act on it. The three seconds it takes to recall is enough to lose the conversion.

That gap between push tap and the right in-app screen is fixable. The mechanism is a deep link encoded into the push payload, read at app open, and routed before any default navigation runs. Most teams ship push without it and accept the conversion penalty as a normal feature of mobile.

This post walks through how to encode the route, handle the three notification states correctly, instrument the funnel, and QA before launch.

What "Deep Linking for Push" Actually Means

A push notification deep link is a routing parameter inside a notification payload that tells the app, on open, which in-app screen to navigate to. It replaces the default home-screen landing with the specific screen the notification is promoting.

Two things it is not:

• Not rich push. Rich push refers to media (images, videos, action buttons) rendered inside the notification itself. Deep linking is about where the tap lands.
• Not silent push. Silent push triggers background processing without showing the user anything. Deep linking only matters when there is a visible notification the user can tap.

The cost of skipping push deep linking shows up in three places: lower tap-to-action conversion, higher app abandonment within 10 seconds of open, and harder attribution because the route taken cannot be tied back to the campaign. This is the same routing-context-preservation problem covered in the deep linking for email and CRM campaigns guide, applied to push instead of inbox. For the broader catalogue of where deep links earn their keep beyond basic app opens, the 8 deep linking use cases guide is a useful map. Teams running QR or offline-to-app journeys, like abcoffee tracking offline users from QR to app, run into a similar context-preservation problem at the install boundary; push is the same logic for already-installed users.

The Three Failure Modes Push Routing Falls Into

Push routing breaks down differently depending on the app state when the user taps. Treat them as three distinct paths with three distinct handlers.

• Foreground tap. App is open and active. The OS hands the notification payload directly to the running app. Routing is the easiest case because the navigation stack is alive.
• Background tap. App is suspended but still in memory. The OS resumes the app and delivers the payload through the lifecycle callback. The navigation stack survives. Most routes work if the handler is registered.
• Cold start. App is not running. The OS launches the app from scratch and passes the payload through the launch arguments. This is where most push deep linking breaks because the router has to wait for SDK initialisation, the navigation stack starts empty, and a default screen often kicks in before the deep link handler reads the payload.

The cold start path is the one to instrument first because it accounts for the majority of failures and is the hardest to debug after launch.

How to Encode the Route in the Payload

The cleanest payload structure puts the route in a dedicated key, with optional UTM parameters attached for attribution.

Recommended fields:

• deep_link: a single URL the app parses to determine the destination. Example: myapp://product/sku-42?utm_source=push&utm_campaign=summer_sale
• route_id: optional fallback identifier used when URL parsing fails
• Standard UTM parameters appended for attribution

What to avoid:

• Burying the route inside the notification body text. The body should describe the value to the user, not carry routing logic.
• Encoding the route in a custom key that requires per-app parsing logic. A standard URL is portable.
• Skipping UTM parameters because "push is not a marketing channel". Push earns spend through CRM tools and deserves the same attribution rigour as paid.

Payload size constraints worth recognising:

• iOS APNs: 4KB for standard push, 5KB for VoIP push. The route URL plus UTMs typically sits under 200 bytes, so this is rarely a blocker.
• Android FCM: 4KB for the data payload. Same practical headroom.

If you are running push through MoEngage, WebEngage, or CleverTap, the deep link field is usually a first-class column on the campaign builder. Use it rather than overloading a custom payload key.

Handling Cold Start Correctly

Cold start is where most push deep linking breaks. The root cause is timing: the navigation stack starts running before the deep link handler is registered, so a default screen renders and the route gets dropped.

The pattern that works:

1. Block navigation until SDK init completes. The app launch sequence reads the notification payload before any default screen renders.
2. Register the deep link handler synchronously inside the app's launch path. Not inside the home-screen view that renders after launch.
3. Defer the first navigation decision until the handler has had a chance to inspect the launch arguments and signal whether a route is present.
4. Fall back to the home screen if no route is found, not as the default that always runs.

A pattern observed across audits of re-engagement push setups: the most common reason a deep-linked push fails is the route handler being registered after the navigation stack has already initialised on cold start. The fix is structural, not configuration. Once it is in place, the same code handles all three notification states.

Edge Cases That Generate Support Tickets

Past the three main states, four edge cases account for most production tickets.

• User force-quit the app between notification and tap. Behaves the same as cold start. Cold-start handler covers it.
• User uninstalled the app. The push will not deliver, but if the campaign sends a complementary email or SMS, a deferred deep link can preserve the route through reinstall. Same logic applies for tracking the reactivation; the attribution for re-engagement campaigns guide covers the channel-by-channel measurement workflow.
• User has multiple notifications stacked. Only the tapped notification carries the active payload. Make sure your handler reads the payload of the tapped notification, not the most recent one in the stack.
• Notification action buttons need different routes. Each action button needs its own deep link parameter. Most push platforms support this through a per-action payload override.

A practitioner pattern worth flagging: notification action buttons are routinely shipped with the same route as the main notification body, which makes the buttons useless. QA should explicitly test each action button as a separate route.

Measuring Push-to-Action Conversion

The push funnel is a single conversion path, not three separate metrics. Instrument it as one funnel from delivery to in-app action.

Events to track:

• notification_received: device received the push (fires from the SDK's silent processing)
• notification_opened: user tapped the notification
• route_resolved: deep link handler successfully read the payload and navigated to the target screen
• target_action: the in-app action the campaign was driving (purchase, content view, profile update, whichever applies)

Compute conversion as a single rate from notification_received to target_action. Two follow-on cuts:

• Compare deep-linked push opens against generic push opens. The lift on action rate is usually meaningful, often 2x or more.
• Split by campaign and creative to find which messages convert and which underperform.

Tools like Linkrunner make this measurable by letting the same deep link work in push payloads, email, and SMS with attribution baked in rather than added as a separate parameter, which keeps the funnel readable across channels.

Pre-Launch QA Checklist

Run through this before sending any deep-linked push to production traffic. Borrow the broader pre-launch discipline from our deep link QA checklist and add the push-specific cases below.

• Foreground tap routes correctly
• Background tap routes correctly
• Cold start routes correctly
• App removed from recents, then notification tapped, routes correctly
• Test on iOS and Android, each with at least two OS versions
• Notification permission newly granted: route still works
• Stacked notifications: the tapped notification's route is honoured
• Each action button on a multi-action notification routes to its own destination
• Deep link parameters are URL-encoded; special characters do not break routing
• UTM parameters arrive correctly on the attribution platform

Treat any failed case as a launch blocker. A broken deep link in a high-volume push campaign costs more than the campaign delivers.

FAQ

Why do my push deep links sometimes fail on cold start?

The router is starting a default navigation before the deep link handler reads the payload. The fix is to block navigation until SDK init completes and the handler has inspected the launch arguments.

How big can the deep link payload be on iOS and Android?

iOS APNs allows 4KB for standard push, 5KB for VoIP push. Android FCM allows 4KB. A route URL plus UTMs typically uses under 200 bytes, so headroom is not the blocker.

Can I use the same deep link in push, email, and SMS?

Yes, and you should. Using one canonical deep link across channels means attribution and routing share the same surface. Channel is identified through UTM parameters, not through a different link format.

Do push notification opens count as attribution events?

If you tag the deep link with UTM parameters, your MMP can attribute the open to the push campaign. Most MMPs treat push opens as a reattribution event rather than a fresh install.

Should I use deferred deep links inside push notifications?

Not for live users with the app installed; standard deep links handle them. Deferred deep links matter when the same campaign sends a fallback email or SMS to users who uninstalled, so the route survives reinstall.

What to Do Next

The highest-value action this week: pick one re-engagement push campaign, ship deep linking on it, measure tap-to-action conversion against your existing baseline, and treat the result as the cost of every push you ship without it.

If you would like to see how the same deep link can carry through push, email, SMS, and web with attribution baked in, request a demo from Linkrunner and we will walk you through the unified link setup for your project.