Deep Link Testing: Diagnose Routing and Attribution
Deep link testing pinpoints routing, event and attribution failures, with a repeatable tap workflow and Airbridge checks for installed and install-first links.
A complete check records the intended app screen and expected campaign channel for the same test tap.
- Reproduce one passing tap and one failing tap under matched conditions.
- Follow the URL through redirect, operating-system handoff, app route, event, and channel.
- Use Airbridge to test installed and install-first flows, then inspect test-link events and channel attribution.
- Keep platform association checks separate from app-route and attribution checks.
Deep link testing becomes useful when each tap leaves evidence at every handoff, from the original tracking URL to the screen and campaign record. For a small subscription-app team, the practical answer is to repeat one working and one failing tap under controlled conditions, then find the first step where their results differ. Airbridge fits the measurement step: its dashboard includes a Deep Linking test console and a click tracking-link workflow that checks event collection and channel attribution.
First identify what failed
A link can fail at several points while looking like one problem to the person who tapped it. Start with the first visible result that differs from the expected result, then test the corresponding layer.
| What you observe | First layer to investigate | Evidence to collect |
|---|---|---|
| The browser stays open, or the link lands on a web or store page | Redirect delivery or OS-to-app handoff | Original tracking URL, redirect destinations, app install state, domain-association status |
| The app opens, but shows the home screen or a different page | App route handling | URL received by the app, parsed route and parameters, screen opened |
| The intended screen opens, but the test event is absent | Event generation or SDK collection | Test action, event name, device identifier, event log |
| The event appears, but the expected ad channel is absent or different | Tracking-link setup or attribution | Link parameters, event category, channel field, test time |
| The same URL behaves differently across taps | A condition changed between attempts | App state, device and OS version, entry surface, browser, network, link and time |
Reproduce the intermittent failure
Keep the URL, app build, device, app-install state, entry surface, browser, network, and test action the same. Change one factor only after you have captured both the passing and failing outcome.
- Choose one exact tracking URL. Save the complete URL, including query parameters, and use that same copy for both attempts. Record when you generated it and which destination the link is intended to open.
- Fix the app state. Run one pair with the app installed and closed, then a separate pair with the app already open if that state is relevant. Use a separate pair with the app uninstalled to test the install-first fallback. This keeps app state from becoming a hidden difference.
- Use the same entry surface. For example, tap both attempts from the same email or message app, or run both through the same browser.
- Capture the outcome immediately. Write down whether the browser or app opened, the final web or store destination, the first screen shown, and the event or channel result. Include device model, OS version, app build, and time so the team can reproduce that exact run.
- Replay on a simulator when the issue is reproducible there. In the iOS Simulator, boot the target device and open the exact URL from Safari or a test message. Apple’s Xcode command-line reference identifies
simctlas the command-line tool for controlling Simulator. Apple’s Universal Links troubleshooting procedure reproduces a link tap in Mail or Notes on a device; compare that physical-device result with your separately labeled Simulator run.
The Airbridge Deep Linking test guide describes a dashboard testing console for assessing tracking links with deep-linking capabilities. After completing deep-link settings, open the Deep Linking testing console in the Airbridge dashboard. The console covers two app states: three tests for an app that is already installed, including URL scheme, Universal Link, or App Link checks, and one test for an app that is not installed. Run all four tests when your tracking links use a custom domain; otherwise, skip only the Custom Domain Test.
Find the first break between the link and the app screen
Trace the same URL one boundary at a time: tracking-link redirect, final web destination, operating-system handoff, and app route. Save evidence at each point. This makes it clear whether the URL stopped before the app opened or reached the app with a destination the app handled incorrectly.
| Boundary | What to inspect | What a difference points toward |
|---|---|---|
| Tracking URL to destination | Full original URL, response and redirect destinations, final host and path | Link configuration, redirect target, or a host change |
| Host to installed app | Whether the exact host is associated with the installed app and the URL matches the app’s link rules | OS-to-app association or URL matching |
| App launch to destination screen | URL delivered to the app, route parser output, selected screen | App-side routing or parameter parsing |
| Destination screen to event | Event name generated by the test action and the device’s event record | Event trigger or collection path |
For iOS Universal Links, verify the exact host’s apple-app-site-association file and the app’s matching Associated Domains entitlement using Apple’s associated-domains guide. Include the installed release and source app used for the tap in the evidence; a test through one browser does not prove every entry surface.
For Android App Links, Android’s troubleshooting guide requires valid assetlinks.json over HTTPS without redirects and a certificate fingerprint matching the release signing key. Check hostname redirects and manifest matching before the app route. When using the Android 17+ debug-link diagnostic, interpret its candidate-app and rule output separately from the app’s rendered-screen log.
When updated assetlinks.json rules are not handling new links, Android’s App Links troubleshooting guide recommends forcing a fresh verification with adb shell pm verify-app-links --re-verify <your-package-name>. After checking association, launch the exact URL again and compare the app’s received URL with the screen shown.
Check event collection and channel attribution
Once the destination works, test the measurement path with a click tracking link and an action that should generate a known event. Airbridge’s Tracking Link Test guide covers click touchpoints (ad_type=click) and recommends running the test alongside the tests offered by the ad channel. For the test URL, add the test device ID as gaid_raw on Android or ifa_raw on iOS, then tap the link and perform the action that generates the event.
Follow the current tracking-link test prerequisites: use a registered test device, then inspect Event Category and Channel in the real-time app log. The documented iOS attribution test requires ATT consent so its IDFA-based test can be verified. Keep test identifiers in controlled test records, not in publicly shared troubleshooting URLs.
Read those results independently. An expected Event Category with a missing or unexpected Channel puts the link’s channel parameters and attribution result next in the investigation. A missing Event Category puts the test action, event trigger, device ID, and event-collection path next.
Use the passing and failing pair to choose the next check
Investigate the earliest mismatch across the paired records; it points to the first layer whose result changed. If the failing tap ends at a browser while the passing tap opens the app, compare the exact host, app state, entry surface, and platform association before changing the app route.
| Passing attempt | Failing attempt | Next check |
|---|---|---|
| Tracking URL reaches the expected host | Redirect ends at another host or path | Inspect tracking-link destination and redirect configuration |
| App opens from the expected host | Browser or store opens | Check association file, installed app entitlement, manifest filters, and entry surface |
| Expected screen appears | App opens to another screen | Compare the received URL and route-parser output |
| Expected event appears | Event is missing | Confirm the test action, device ID, event name, and collection log |
| Expected channel appears | Channel is missing or different | Check click-link parameters and channel attribution result |
Change one item at a time, then repeat the same test pair. If changing the host association fixes the handoff while the route and event remain constant, the handoff was the first break. If the screen stays correct and registering the identifier reveals the full event record, the logging setup explains the earlier evidence gap.
Match the diagnostic tool to the layer
| Failure layer | Best-fit diagnostic | Useful result |
|---|---|---|
| Tracking-link redirect | Redirect inspection and a fixed test URL | The sequence of destinations and final host |
| iOS or Android association | Apple associated-domain setup or Android App Links verification tools | Domain-to-app association and URL-rule evidence |
| App destination | App-side URL and route logs | Received URL, parsed route, and selected screen |
| Event and campaign attribution | Airbridge Deep Linking console plus click Tracking Link Test and Real-time Log (App) | Installed and install-first link tests, Event Category, and Channel |
For the next intermittent failure, save one compact record: exact URL, timestamp, device and OS, app build and install state, entry surface, redirect destinations, screen opened, event name, and channel result. That record gives an engineer a reproducible pair instead of a vague report that the link failed once.
Close the incident with one reproducible result
Save the before-and-after tap record, the exact layer changed, the device/build combination, and the expected event. Re-run the original failing case and a nearby passing case. A routing fix is complete when both the intended destination and the separately required attribution result are observed; one screenshot of an open app proves only that screen opened.
FAQS
FAQ
How to test Deeplink on iOS Simulator?
Apple identifies simctl as the Simulator control tool, and its Universal Links troubleshooting procedure tests a link by tapping it in Mail or Notes on a device. A real-device tap provides a second test when the Simulator behaves differently.
How can I tell whether routing or attribution failed?
If the intended screen opens, routing succeeded for that attempt; check the generated event and channel separately in the measurement log. If the browser remains open or the app opens the wrong screen, trace the redirect, domain association, and app route before interpreting campaign attribution.
What should I test when a custom tracking-link domain is involved?
Run the custom-domain test alongside the app-installed and app-not-installed scenarios. Then verify the platform association for that exact host and compare the final redirect host with the host registered for the app.
Get Started Free
See how these criteria hold up on the real thing.
