How it works
The user taps the link. The link service sees that the app is not installed, records the click with its destination and redirects to the store. After installation, the SDK asks the service on first launch whether this install matches a recent click. If it does, the service returns the destination and any parameters, and the app routes the user there instead of showing the default start screen. On Android the match can rely on the Play Install Referrer, which the store passes to the app. iOS offers no such referrer, so the match depends on other signals and is less certain.
Why it matters for an app team
New users are the ones most likely to drop off, and a generic welcome screen after a specific promise is a common reason. Deferred deep links keep the context of the ad or invitation: the promised product, a referral code, a discount.
In practice
Example with made-up numbers: 2,000 new users install from an ad for a particular recipe. Half open the app on its home screen and half are taken to the recipe by a deferred deep link. Comparing how many in each group open the recipe shows what the deferred link adds.
Common confusion
Deferred deep linking needs both a link service and code in the app that asks for the destination on first launch and handles it; the link alone does nothing. It is also different from a direct deep link, which only works when the app is already installed. Most marketing links combine both behaviours behind one URL.