- Pass rate is the share of visitors routed to the real page instead of the safe page.
- Too strict: real users land on the safe page and never reach the offer — wasted spend.
- Too loose: automated traffic reaches the real page, which is the risk the setup exists to avoid.
- Tune one rule at a time and read the effect; the right pass rate depends on your traffic, not a universal number.
What pass rate actually measures
Pass rate is the proportion of incoming visitors your setup routes to the real page. If 100 visitors arrive and 70 reach the real page while 30 see the safe page, your pass rate is 70%. The number itself is neutral — what matters is whether the 30% held back were genuinely automated traffic (good) or real users caught by an over-strict rule (bad). That is why pass rate has to be read alongside the real-vs-safe breakdown described in reading the analytics, not in isolation.
Too strict: over-filtering real users
An over-strict setup treats too many visitors as suspect and routes real users to the safe page. The symptom is a pass rate lower than your genuine-traffic share can explain, often concentrated in one segment — mobile in-app users are a classic casualty because their signals look unusual to desktop-tuned rules. The cost is real: paid clicks land on the safe page and never see the offer. If your pass rate craters on mobile specifically, the cause is usually a referrer requirement or an aggressive fingerprint check — see mobile traffic routing for why.
Too loose: under-filtering
A too-loose setup lets traffic through that a stricter rule would have held back, so automated visitors reach the real page. This is the risk the setup exists to reduce in the first place, so under-filtering defeats the purpose. The symptom is a pass rate close to 100% with a real-vs-safe ratio that looks too clean given the noise in your traffic sources. What kinds of traffic you are trying to separate — and why it matters — is covered in bot traffic basics and how platforms detect these setups.
Finding balance one rule at a time
The reliable way to tune is to change one rule at a time and read the effect before the next change. Batch changes make it impossible to attribute a swing to a cause. Move a single threshold, let enough traffic flow to see the new pass rate and real-vs-safe ratio settle, then decide the next move. This is slower than a big-bang retune but it converges; a stack of simultaneous changes usually does not. During a new-domain warmup, keep every rule looser than its eventual target — see warming a new domain.
Tune per segment, not globally
A single global pass rate hides the fact that different segments need different settings. Desktop and mobile, different geos, and different traffic sources each have their own baseline of what "normal" looks like, so a rule that is balanced overall can be too strict for one segment and too loose for another. Tune per segment where your tool allows it, and always read the pass rate broken down rather than as one blended number. The structural side of keeping the two surfaces coherent while you do this is in safe page vs real page.