There's a pattern that shows up regularly in attribution audits. A campaign launches on Monday. By Thursday, the spend report shows strong click volume and reasonable install numbers, but conversion rates are lower than expected. On investigation, the deep links are routing new users to the home screen instead of the promoted destination. The deferred routing test wasn't run before launch.
The fix is straightforward. The cost is three days of misdirected spend and weeks of skewed cohort data. For a campaign with a ₹10 lakh weekly budget, even a 20% conversion improvement from correct routing represents ₹2 lakh in recoverable performance per week. Most teams that run pre-launch deep link QA systematically find at least one routing issue before go-live.
This guide is that QA process, structured as a reusable checklist. It covers the tests that matter, the device matrix to run them on, and the specific in-app browser environments that cause the most silent failures.

Why Deep Links Break at Campaign Scale

A link that works in your testing environment can fail in production for reasons that have nothing to do with the link's configuration. The environments where users actually tap your ads are more varied than most testing setups account for.
Instagram's in-app browser, for example, does not support Universal Links on iOS. A link that routes correctly in Safari will silently fail in Instagram and take the user to a web fallback. If your campaign runs on Instagram and your fallback destination is poorly configured, users hit a generic landing page or a blank screen, and the ad spend registers as a click with no downstream conversion.
In-app browser failures are one category. Deferred routing failures are another. AASA (Apple App Site Association) file caching issues are another. Attribution parameter drop-off is yet another. Each requires a different test, and each is covered in the checklist below. Teams who want to understand the full range of iOS-specific deep link failure modes will find a diagnostic breakdown useful alongside this pre-launch process.

The Pre-Launch Deep Link Checklist

This is a 15-item checklist covering the core validation steps before any campaign that uses deep links goes live. Run it for every new campaign, not only for new link configurations.
Link creation and configuration:

• Destination screen is confirmed with the product team and is not assumed from the ad creative.

• Fallback URL is set and tested independently: does the fallback destination load correctly in a browser?

• Attribution parameters (UTM or MMP-specific) are appended and match the campaign configuration in your attribution dashboard.

• Dynamic link expiry date is set if the campaign has a defined end date.

• Link format is appropriate for campaign type: deferred deep link for acquisition, standard or Universal Link for re-engagement.
  iOS testing:

• Link opens the app correctly on iOS when app is installed, tested in Safari.

• Link routes to the correct destination screen, not the home screen.

• Link handles the app-not-installed case by redirecting to the App Store on click.

• Deferred install test: uninstall app, click link, install from App Store, open app, verify correct destination on first launch.

• In-app browser test: link tested from inside Instagram's in-app browser on iOS.
  Android testing:

• Link opens the app correctly on Android when app is installed, tested in Chrome.

• Deferred install test on Android: uninstall app, click link, install from Play Store, open app, verify correct destination.

• In-app browser test: link tested from inside Instagram's in-app browser on Android.
  Attribution and reporting:

• After completing the deferred install test, confirm the install appears in your MMP dashboard attributed to the correct campaign and channel.

• Confirm no "organic" or "unattributed" install was created where the test install should have been attributed.
  Running all 15 checks takes approximately 45-60 minutes per campaign with test devices ready. The weekly attribution audit process includes a condensed version of this for ongoing validation once a campaign is running.

Device Matrix: What to Test On

Not all devices behave identically. iOS versions have meaningful behavioural differences for Universal Links. Android fragmentation means in-app browser behaviour varies by manufacturer.
Minimum test matrix for iOS:

• Latest iOS version: test in Safari and Instagram's in-app browser.

• One iOS version two releases back: catches AASA caching and Universal Link handling differences that appear after OS updates.

• A real iPhone device: simulators cannot replicate the deferred install flow, which requires an actual App Store install.
  Minimum test matrix for Android:

• Latest Android version on a stock Android device (Pixel or equivalent): test in Chrome and Instagram's in-app browser.

• A Samsung device on a recent Android version: Samsung Internet browser handles App Links differently from Chrome, and Samsung devices represent a significant share of the Android user base in India.

• Android 12 or earlier if your user base includes older devices: App Link behaviour changed with Android 12's verification flow.
  If your user base is heavily Android (65-75% is typical for Indian consumer apps), prioritise Android test depth. More test coverage on the higher-volume platform reduces the risk of in-campaign failures.

In-App Browser Testing: The Most Commonly Skipped Step

In-app browsers are where most deep link failures occur in production. They're also the environment most commonly skipped during QA, because testing typically happens in Safari or Chrome.
Instagram (iOS and Android): Instagram's in-app browser does not support Universal Links on iOS. Tapping a link inside Instagram should either redirect to the App Store for new users, or trigger app opening via a different routing mechanism. If it opens a webpage instead, the fallback configuration needs review. This is the single most important in-app browser test for any Meta campaign.
Facebook (iOS and Android): Similar to Instagram. Facebook's webview on iOS does not support Universal Links. Test Facebook and Instagram separately, as they can behave differently despite sharing the same parent company's codebase.
WhatsApp (iOS and Android): Relevant for referral campaigns, D2C brands distributing links via support channels, and any campaign with a WhatsApp distribution component. WhatsApp links using HTTPS with Universal Links resolve inconsistently depending on iOS version and link format.
Gmail (iOS): Gmail on iOS uses its own webview. Universal Links within Gmail work inconsistently. Any campaign link that will appear in an email should be tested by opening it inside the Gmail app, not by clicking it from a desktop email client.
Chrome Custom Tabs (Android): Most Android apps use Chrome Custom Tabs for in-app browsing. These generally support App Links correctly, but the behaviour should be verified for your specific link format and Android version combination.
Document the result of each in-app browser test. If a specific environment fails, escalate before launch rather than after spend is committed.

Deferred Deep Link Validation: The End-to-End Test

The deferred deep link test is the most important test for acquisition campaigns and the one most frequently skipped. It requires temporarily uninstalling the app, which is why teams avoid it. The cost of skipping is campaigns that send new users to the home screen instead of the promoted destination.
Step-by-step process:

• Take a test device with the app uninstalled, or uninstall it now.

• Copy the exact campaign link URL.

• Paste it into the browser or app environment you are testing from.

• Click the link and verify it redirects to the App Store or Play Store.

• Install the app from the store.

• Open the app for the first time. The first screen that loads should be the campaign destination, not the home screen or an onboarding flow.

• Open your attribution dashboard and confirm the test install is attributed to the correct campaign.
  Repeat this test on both iOS and Android. Deferred deep linking behaviour differs by platform, and it is common for the Android flow to work correctly while iOS fails, or vice versa. For a full explanation of how deferred deep link resolution works on each platform, and why success rates differ between iOS and Android post-ATT, the deferred deep links explained guide covers the technical foundation.
  If deferred routing fails, the most common causes are: the SDK is initialising too late in the app launch sequence to retrieve stored parameters, the attribution match window is set too short, or the AASA file configuration is not routing clicks through the deep linking platform's server (which is required to store click parameters for later retrieval).

Attribution Parameter Verification

Every campaign link must carry attribution parameters that your MMP can read. Without them, installs generate no attribution data and appear as organic. This is a permanent data quality loss once a campaign has run: you cannot retroactively attribute installs that were never tagged.
What to verify:

• UTM parameters (utm_source, utm_medium, utm_campaign) are present and contain meaningful values, not placeholders or test strings.

• MMP-specific parameters match the campaign configuration in the attribution platform dashboard.

• After completing the test install, the install appears in the MMP attributed to the correct source, medium, and campaign name.

• No test installs appear as organic in the dashboard.
  For teams that track daily and weekly performance KPIs, an unexplained increase in the organic install bucket during an active paid campaign is often the first signal that attribution parameters have dropped off a running campaign link. Catching this at pre-launch QA prevents it entirely.

Automated vs Manual QA Approaches

Partial automation is possible and worth investing in once your team is running multiple campaigns per week. Manual testing is essential for the deferred install flow.
What can be automated:

• Installed-app routing tests can be scripted using mobile UI automation frameworks like Detox (React Native) or Espresso (Android). Automating the test that confirms a link opens the correct screen is straightforward if you have a test suite already in place.

• AASA file availability checks can be run as part of a deployment pipeline. A simple HTTPS check that confirms the file returns valid JSON with the correct Content-Type prevents deployment-related AASA outages.

• Attribution parameter presence checks can be validated against a configuration file that defines expected parameters per campaign.
  What cannot be reliably automated:

• Deferred install testing requires an actual App Store or Play Store install on a real device. This cannot be replicated in a simulator or automated environment because it depends on the store's install process.

• In-app browser testing requires manual interaction inside the actual social app environment. Automated webview tests do not replicate the exact conditions of Instagram's or Facebook's in-app browsers.
  For teams without engineering bandwidth to build automated checks, the manual 15-item checklist above provides sufficient coverage to prevent the most common pre-launch failures.

Post-Launch Monitoring: Catching Breaks After Go-Live

Deep links can break after launch due to iOS or Android OS updates, AASA file changes, app updates that rename or remove screens, or CDN configuration changes. Pre-launch testing validates the state of the link at launch. Post-launch monitoring catches breakage that occurs during the campaign.
Key signals to monitor:

• A sudden increase in unattributed or organic installs from a running campaign typically indicates attribution parameter breakage, either on the link itself or a postback configuration issue.

• A drop in D0 conversion events while install volume stays stable suggests routing failures: users are installing but not reaching the intended destination.

• An increase in negative app reviews mentioning "wrong screen on open" or "had to search for the product" is a consumer-facing signal of deferred routing failure at scale.

• Monitor AASA file availability if your links use Universal Links. The file should return valid JSON at all times. A CDN misconfiguration returning an error will cause all Universal Links to fall through to Safari.
  Set up alerts in your attribution dashboard for unattributed install spikes and D0 conversion rate drops by campaign. These two signals catch the majority of in-campaign deep link failures before they compound. Platforms like Linkrunner surface link-level routing analytics in real time, making it easier to track destination success rates without building separate monitoring infrastructure. Request a demo to see how link health monitoring works in practice.

Frequently Asked Questions

How often should we run this QA checklist?
Run the full 15-item checklist for every new campaign. Run a shortened version (items 1-5 and 14-15) when making changes to an existing campaign's creative or destination URL. Run the deferred install test any time the app receives a major update that changes screen routing logic.
Can we run QA without real test devices?
Some checks can be done without devices (AASA validation, attribution parameter inspection, fallback URL testing). The deferred install test and in-app browser tests require real devices. Simulators and emulators do not replicate the app store install process or the exact behaviour of social in-app browsers.
What should a good fallback destination look like?
A fallback should communicate the same offer as the ad and provide a clear path forward. A generic homepage fails because users lose the context that brought them there. The best fallbacks are lightweight landing pages that mirror the ad creative, include a prominent app store download CTA, and work correctly in the in-app browser environments where Universal Links don't resolve.
What happens if we find a failure during QA?
Document the specific failure (which device, which OS version, which environment) and escalate to engineering with the exact test steps to reproduce. Don't launch until the fix is deployed and the same test passes. A campaign delayed one day for a routing fix loses less than a week of misrouted spend.
Is the QA process different for retargeting campaigns?
Retargeting campaigns use standard deep links rather than deferred links because users already have the app installed. The QA process is simpler: test the installed-app routing across relevant devices and in-app browsers. Attribution parameter verification is still required. Skip the deferred install test (steps 8-9 and 12) for retargeting-only campaigns.