ROUTING REFERENCE
Product architecture and workflow
See how Smart Linker routes mobile app visitors through one stable public link. This page explains the public routing flow, device-aware behavior, and fallback model without exposing private infrastructure details.
What this page explains
One public Smart Link
A single public URL resolves to the configured routing destination behind it.
Device-aware behavior
iPhone, Android, desktop, and QR scans follow the same public link and route by request context.
Stable public URL
The public link stays stable even when destinations are edited later.
Fallback behavior
If a destination is missing, Smart Linker renders the public fallback page instead of inventing a target.
Routing flow
-
1. Open
Visitor opens the public Smart Link or scans the QR code that points to it.
-
2. Read
Smart Linker reads the configured destinations attached to that public link.
-
3. Select
The router evaluates the request context and selects the best destination.
-
4. Route
The visitor reaches the configured iOS destination, Google Play, or a web fallback.
-
5. Stay stable
The public URL remains stable even when destinations are edited later.
Device-aware behavior
| Context | Public behavior |
|---|---|
| iPhone | Routes through the existing iOS path to one configured iOS destination: an App Store URL or public TestFlight invite. |
| Android | Routes to the configured Google Play destination when present. |
| Desktop | Uses the configured web fallback when present, otherwise the public fallback page. |
| QR scan | Uses the same stable public link and routes by device at scan time. |
iPhone
Routes through the existing iOS path to one configured iOS destination: an App Store URL or public TestFlight invite.
Android
Routes to the configured Google Play destination when present.
Desktop
Uses the configured web fallback when present, otherwise the public fallback page.
QR scan
Uses the same stable public link and routes by device at scan time.
Stable-link semantics
- One public URL can be reused across campaigns, bios, partner placements, launch pages, and QR assets.
- The destination behind that URL is editable later without reissuing the public link everywhere it appears.
- A public TestFlight invite uses the existing single iOS destination after creation; it is not a second iOS field or a separate routing branch.
- The same Smart Link and QR can later use the production App Store destination; use separate Smart Links for simultaneous beta and production iOS destinations.
- Install-link behavior is a public entry pattern for app distribution, not a deep-linking or attribution guarantee.
- The routing outcome stays deterministic when the same link and same request context are used.
Fallback model
- Configured device-specific destinations take precedence when they are available.
- If a destination is missing, Smart Linker renders the public fallback page instead of inventing a redirect target.
- The public fallback action reflects the configured iOS destination: Join TestFlight or Open in App Store.
- The fallback behavior is deterministic and stays tied to the published public link.
Analytics workflow
Analytics stays aggregate-only. Smart Linker provides aggregate routing and click visibility without exposing click-level privacy-sensitive data. It does not integrate with App Store Connect or provide analytics for TestFlight installs, tester enrollment, build status, app opens, conversions, or attribution.
What you can see
- Traffic totals
- Link clicks
- QR scans
- Routing quality
- Traffic over time and mix
- Referrer and fallback summaries
What stays out of export
- Raw click rows
- IP addresses
- User agents
- Full referrer URLs
- User IDs
- Click IDs and per-click timestamps
Supported windows are 7d, 30d, and 90d. CSV export remains aggregate-only and does not expose raw click rows, IP addresses, user agents, full referrer URLs, user IDs, click IDs, or per-click timestamps.
Governance boundary note
This reference is kept aligned with Smart Linker’s governed routing model. It explains public routing behavior without exposing private infrastructure details.
- Public: routing concepts, fallback concepts, stable-link behavior, QR semantics, and platform-level guarantees.
- Private: infrastructure topology, secrets, anti-abuse internals, deployment mechanics, monitoring details, scoring logic, and sensitive security details.
- This page does not expand the capability contract; it explains the workflow semantics behind it.