The festive campaigns that lose the most money are rarely the ones with bad creative. They are the ones where the tap worked and the landing did not.
A user sees a Diwali offer, taps it, and arrives on your home screen. They now hold an intent you created and no obvious way to act on it. Most of them leave. The campaign reports a click, an install, and a conversion rate that looks like a creative problem.
It is not a creative problem. It is a routing problem, and festive is when it is most expensive.
Why festive is the hardest deep linking week of the year
Festive deep linking is the practice of verifying that every sale, offer and category surface built for a seasonal campaign routes users to the right in-app destination, including users who do not yet have the app.
The difficulty is structural rather than technical. During an ordinary quarter you might add one or two new landing surfaces. During festive you add them weekly: sale pages, category pages, offer pages, countdown pages, one-day-only pages, and a different set for each of the three spend waves.
Every one of those is a new routing path that has never carried traffic. And they are built under time pressure, by people who are also building creative, in the weeks when the auction is repricing.
So the failure rate rises at exactly the moment the cost of failure rises. That is the whole problem in one sentence.
The four routing paths, and where each breaks
Deep linking during a sale is not one path. It is four, and they fail differently.
1. Ad to app, existing user. The simplest case. The user has your app, taps, and should land on the offer. Breaks when URI scheme handling changes between app versions, or when the new sale page has no corresponding in-app route. Verify against the app build that will actually be in production during the window, not the one on your development device.
2. Ad to store to app, new user. The user does not have the app. They tap, install, open, and should still land on the offer. Without deferred deep linking the context is lost at the store boundary and they land on a generic first-run screen. This is the highest-value path to get right during festive and the one most often skipped.
3. Web sale page to app. Highest volume during festive for anyone with a mobile web presence. The user is browsing your sale on mobile web and should be moved into the app with the same product in front of them. Our web-to-app conversion guide covers the mechanics.
4. Offline and messaging. QR codes on packaging and in-store, WhatsApp broadcasts, SMS blasts. These have the longest lead times, so they get built first and tested least, and a printed QR code cannot be fixed once it ships. Our guide to routing SMS and WhatsApp traffic covers the messaging cases.
Universal Links on iOS and App Links on Android behave differently under each of these, which is why the test matrix below splits by platform rather than assuming parity. The iOS failure modes in particular are numerous and specific, and our post on why deep links break on iOS is worth reading before you build the matrix.
What it costs when the context is lost
The user does not tell you the link was broken. They just leave.
What you see instead is a campaign with acceptable click-through, acceptable install volume, and a conversion rate that disappoints. The natural diagnosis is that the creative overpromised or the audience was wrong. Teams then rewrite creative and retarget audiences, which fixes nothing, while the actual fault sits in a routing table.
This misdiagnosis is expensive in an ordinary month. During festive it is expensive at peak prices, and you have weeks rather than quarters to notice.
The tell is a drop in activation without a corresponding drop in install volume. If installs held and the share of users reaching your first meaningful in-app event fell, look at routing before you look at creative. Across the India apps we measure, activation rates vary enormously between apps, and routing is one of the few causes that can move the number sharply within a single campaign rather than gradually.
The pre-festive QA pass
Run this before mid September, ahead of the first spend wave.
Build the test matrix. Every festive surface, crossed with:
-
New install and existing install
-
iOS and Android
-
App installed and app not installed
-
Logged in and logged out
That is more combinations than teams expect, which is the point. Our step-by-step deep link QA checklist covers the procedure in detail.
Test on a genuinely fresh device. The single most common QA failure is testing deferred deep linking on a phone that has had the app before. Residual state makes a broken deferred path look like a working one. Use a fresh device or a fully reset one.
Define fallback routing before you need it. Some users will tap and never install. Some will be on desktop. Some will be on a platform you do not support. Each needs a defined destination rather than a dead end, and deciding this in advance is much cheaper than deciding it during the sale. Our post on fallback routing for non-installers covers the options.
Freeze the routing configuration. Once tested, it stops changing. New offers should reuse tested route patterns rather than introducing new ones mid-window.
Deferred deep linking for festive new users
If you fix one thing, fix this one.
A user taps a Diwali offer, does not have your app, installs it, opens it, and lands on a generic welcome screen. You paid full acquisition price for that install, you had their intent at the moment of highest interest, and you spent it on a first-run tutorial.
Deferred deep linking preserves the destination through the install, so they arrive on the offer they tapped. During festive this is disproportionately valuable because the share of new installs is higher than in an ordinary month, which means the share of users hitting exactly this path is higher too.
The deferred deep linking documentation covers implementation, and our explainer on preserving context through app install covers the concept. If you are driving traffic from Meta or Google web placements, the Meta web-to-app and Google web-to-app setups are the relevant configuration.
Measuring whether routing actually worked
Three cuts will tell you whether the problem is routing or demand:
-
Link opens against installs, by surface. A surface where clicks arrive but opens do not is a routing failure, not an interest failure.
-
Activation rate by landing destination. If one festive surface activates well below the others, the route is probably wrong even when nothing errors.
-
Deferred deep link resolution rate. The share of new installs that received their intended destination. This is the number that catches a silently broken deferred path, and it is invisible in campaign reporting.
Our guide to deep link analytics and the metrics that show health covers building these views. During the window, check them daily rather than weekly. A routing break costs a day of spend if you catch it on the day and a week if you catch it at the Monday review.
If you want these cuts on your own festive surfaces before the traffic arrives, request a demo and we will go through the routing with you.
Build the matrix this week
The QA pass takes a couple of days. The window for doing it calmly closes in mid September, before Big Billion Days.
Start by listing every surface your festive campaigns will point at, including the ones that do not exist yet. That list is the test matrix, and writing it down in August is most of the work.
FAQ
What breaks most often in deep links during a sale campaign?
New landing surfaces built under time pressure that have no matching in-app route, and deferred deep linking that was only ever tested on a device which already had the app. Both produce users landing on a generic screen rather than the offer they tapped, and neither throws a visible error.
How do I send a new user to a sale page after they install?
Deferred deep linking. It holds the intended destination through the install and store boundary, so the user opens the app on the offer they originally tapped rather than a first-run screen. It needs configuring and testing before the campaign, not during.
Do deep links behave differently on iOS and Android during high traffic?
The volume itself is rarely the issue. The platform difference is: iOS Universal Links and Android App Links have distinct verification and fallback behaviours, so a route working on one platform tells you nothing about the other. Test both separately in your matrix.
Should each festive offer have its own deep link?
Each offer needs its own destination, but not necessarily a new route pattern. Reusing tested patterns with different parameters is safer than building new paths mid-window, because a tested pattern has known failure modes and a new one does not.
How far before a campaign should deep links be QA'd?
Complete the pass before your measurement freeze, which for the 2026 festive window means mid September, ahead of Big Billion Days in late September. Printed and physical surfaces such as QR codes need longer, since they cannot be corrected after production.