Redirect Priority: Complete Reference
The definitive guide to how SMLLR decides which redirect rule wins — including all conflict scenarios, worked examples, and tips for combining rules safely.
The Full Priority Chain
Every time someone scans your QR code, SMLLR walks through this chain and stops at the first rule that fires:
Default URL
↓ overridden by A/B Test (if active)
↓ overridden by Scheduled Redirect (if time window matches)
↓ overridden by Device Redirect (if device matches)
↓ overridden by Scan-Limit Offer Redirect ★ (if configured) — TERMINAL★ Terminal means that once Scan-Limit fires, evaluation stops. A/B, Scheduled, and Device rules are completely skipped for that scan.
Higher in the chain = lower priority. The rule at the bottom always wins when it is active.
What 'Terminal' Means
The Scan-Limit Offer Redirect is terminal: the moment it fires, the routing decision is final. No other dynamic rule runs.
Why? The Scan-Limit rule is a hard promotional commitment — 'the first 100 people get this offer'. Allowing A/B tests or device rules to silently override it would break that commitment. Making it terminal ensures your promotion cap is always honoured, regardless of what other rules are configured.
If you need device-specific behaviour alongside a scan-limit promotion (e.g. iOS users go to App Store, first 100 get a discount), the current data model does not support this combination. In this case, remove the device redirects and manage platform routing in your offer landing page itself.
Common Scenarios — Who Wins?
| Rules Active | What Happens |
|---|---|
Scheduled only | Scans during a time window go to the scheduled URL; outside windows → default URL |
Device only | Matched devices go to their device URL; unmatched devices → default URL |
Scheduled + Device | Device wins for matched devices regardless of time. Unmatched devices follow the scheduled rule during windows. |
Scan-Limit only | First N scans → offer URL; scan N+1 onwards → fallback URL |
Scan-Limit + Scheduled | Scan-Limit wins — scheduled rule is bypassed entirely while scan-limit is in the offer phase |
Scan-Limit + Device | Scan-Limit wins — all devices go to the offer/fallback URL, device redirects are ignored |
A/B Test + Scheduled | During active time windows → scheduled URL (A/B skipped). Outside windows → A/B test runs normally |
A/B Test + Device (partial) | Matched devices → device URL (A/B skipped for those). Unmatched devices → A/B test runs |
A/B Test + Device (all 3 set) | A/B test never fires — all devices are routed by device rules. Conflict: SMLLR editor will warn you. |
Conflict Rules — When the Editor Warns You
The SMLLR QR editor detects four conflict situations and shows warnings or blocks saving:
BLOCKED (cannot save):
- A/B Test + all three device redirects set (iOS + Android + Desktop) — device rules cover every possible visitor, so the A/B test can never fire. Remove at least one device redirect to leave a channel for A/B traffic.
WARNED (can still save, but be aware):
- Scan-Limit + any device redirect — Scan-Limit overrides device redirects. iOS/Android users will NOT go to their device URL; they follow the scan-limit URLs. Intentional if your promotion applies to everyone.
- A/B Test + scheduled redirects — During scheduled time windows, the A/B test is paused. Make sure enough traffic exists outside windows to get a statistically meaningful test.
- A/B Test + some (not all) device redirects — Devices with a URL bypass the A/B test. Your test results will only reflect users on uncovered devices, which may skew conversion data.
Conflict warnings are informational — they tell you what will happen, not that your setup is wrong. Some combinations are intentional (e.g. Scan-Limit + Device is valid if your promotion applies universally).
How to Combine Rules Safely
Scheduled + Device work great together. Use Scheduled to set the content (breakfast menu vs dinner menu) and Device to control delivery (iOS → app, Android → web). Device always overrides Scheduled.
A/B Test + Scheduled: ensure your scheduled windows don't cover all hours, or A/B results will be too sparse. Best when the schedule covers only a few specific windows (e.g. happy hour) and A/B runs the rest of the time.
Scan-Limit + Scheduled: works well. The Scan-Limit overrides scheduled URLs during the promotional cap period. Once the cap is exhausted (fallback fires), the fallback URL is used for ALL scans, scheduled or not.
Scan-Limit + Device: device redirects are bypassed while Scan-Limit is in offer phase. Only use this combination if your promotion applies to everyone regardless of device.
A/B Test + Device (partial): only configure device URLs for platforms where you do NOT want A/B testing (e.g. iOS → App Store always) and leave other platforms unconfigured to enter the A/B test.
Never set A/B Test + all three device redirects: the editor blocks this because the A/B test is unreachable.
How to Check Which Rule Fired for a Scan
Every scan record in SMLLR stores the final URL the visitor was sent to. To see which rule fired:
- Go to Analytics for your QR code
- Open the Scan Log (if available on your plan)
- The
Target URLcolumn shows exactly where that scan was redirected
If a Device redirect fired, you will see the device-specific URL. If Scan-Limit fired, you will see either the offer URL or the fallback URL. If no dynamic rule matched, you will see the default URL.
Use UTM parameters on each rule's URL to distinguish traffic in your analytics tool (Google Analytics, etc.) — for example, add ?utm_source=qr&utm_content=ios to your iOS device redirect URL.
Was this article helpful?