Re-engagement deep links that don't dump users on 'Welcome back'

Acquisition teams obsess over deep links. Lifecycle teams, strangely, often don't — and it shows. The push notification that says 'your cart is waiting' frequently opens the app to… the home tab. The one moment a churning user gave you their attention, spent on a screen that makes them find their way back.

The neglected half of deep linking

Every reactivation surface — push, email, SMS, in-app inbox — should carry a deep link to the specific thing the message is about. The copy promises a cart, a match, a new episode; the tap should deliver exactly that, instantly.

• Abandoned cart push — open the cart, not the store home.
• Price-drop alert — open the watched item with the new price visible.
• Content re-engagement — open the next episode or the unfinished article.

Installed, churned, or reinstalled?

Re-engagement has a wrinkle acquisition doesn't: the user might still have the app, or they might have deleted it and need to reinstall. The same link must handle both — open directly if installed, and defer the destination through a reinstall if not.

{
  "deepLinkPath": "/cart",
  "customData": {
    "campaign": "winback-d30",
    "incentive": "FREESHIP",
    "lastItem": "air-zoom-9"
  }
}

Should a push notification use a deep link or a URL?

Use a link that works in both worlds, because your push payload will eventually be reused in an email or an SMS and a custom scheme dies the moment it leaves the device. A custom scheme like yourapp://cart is fine inside a push payload and useless everywhere else — tapped from a web page or a mail client it does nothing at all, and it cannot survive a reinstall.

An https smart link covers every case: the OS opens the installed app directly, and if the user has churned and deleted the app, the same URL takes them through the store and lands them on the cart after reinstall. One link format across push, email, SMS, and the in-app inbox is also one fewer thing for lifecycle to get wrong.

How do you re-engage a user who uninstalled?

Through the channels that survive the uninstall — email and SMS — carrying a deferred deep link rather than a store URL. Push is gone the moment the app is deleted, which is precisely why win-back programmes lean on owned channels, and precisely why those channels need deferred links to be worth anything.

1. 1Send to email or SMS, since push is unavailable to a user who no longer has the app.
2. 2Use a smart link carrying the destination and the incentive in its payload.
3. 3The user reinstalls; the SDK delivers the payload on first open.
4. 4Land them on the cart, the saved item, or the unfinished episode — with the incentive already applied, not typed.
5. 5Attribute the reinstall to the win-back campaign, and mark it as a returning user rather than a fresh acquisition.

That last step matters more than it sounds. If reinstalls are counted as new installs, your acquisition numbers absorb your win-back performance and both become uninterpretable — the same reporting error described in the post-IDFA playbook, just from the other direction.

Measure reactivation, not opens

An app open is a vanity metric for lifecycle. Measure the action the campaign was trying to revive — the completed checkout, the resumed subscription — attributed back to the link, and compare against generic-landing control sends. Contextual landings win this comparison consistently.