Write down the source of truth first
Expected-versus-observed test matrix
| Visitor context | Expected | Observed | Evidence | Result |
|---|---|---|---|---|
| iPhone · Safari | App Store listing | ________________ | ________ | Pass / Fix |
| iPhone · campaign in-app browser | App Store listing | ________________ | ________ | Pass / Fix |
| Android · Chrome | Google Play listing | ________________ | ________ | Pass / Fix |
| Android · campaign in-app browser | Google Play listing | ________________ | ________ | Pass / Fix |
| Desktop · Chrome, Safari, or Edge | Website fallback | ________________ | ________ | Pass / Fix |
| Unsupported or unknown device | Website fallback | ________________ | ________ | Pass / Fix |
| Printed QR · iPhone camera | Device-appropriate route | ________________ | ________ | Pass / Fix |
| Printed QR · Android camera | Device-appropriate route | ________________ | ________ | Pass / Fix |
If a route fails, isolate the cause
1. Open the destination directly
Confirm the store or fallback URL works without the smart link. Check the app name, publisher, country, and listing status.
2. Compare the saved destination
Look for an old app ID, package name, regional URL, accidental whitespace, or a missing fallback.
3. Review rule priority
A custom condition may match before the normal iOS, Android, or fallback route. Record the rule that should win.
4. Retest the original context
Use the same device, browser, placement, and final URL. Then test one control browser to see whether the problem is context-specific.
AppRoute uses the configured destinations and best-effort device detection. In-app browsers and iPad desktop mode can behave differently, so keep the web fallback useful and test the actual campaign context.