Trigger analysis is an experiment analysis technique that restricts the evaluation to users who actually encountered the changed feature, rather than analyzing every user assigned to the experiment. When only a fraction of assigned users reach the feature under test, including everyone in the analysis dilutes the observed treatment effect. Trigger analysis solves this by filtering to users whose behavior indicates they were exposed to the change: they loaded the screen, opened the feature, or triggered the relevant code path.
This matters because most product experiments don't touch every user in the assignment pool. If you change the checkout flow but analyze all users, including the 70% who never visited checkout, the real effect gets buried under noise from people who couldn't have been affected. Trigger analysis recovers the signal.
How does trigger analysis improve sensitivity?
The core mechanism is straightforward. A standard analysis includes every user assigned to the experiment. If the change only affects users who reach a specific part of the product, most of the sample contributes zero signal and full noise. The treatment effect, averaged across all assigned users, gets pulled toward zero.
Trigger analysis restricts the denominator to users who actually hit the trigger condition. Fewer irrelevant users means less noise, which means smaller confidence intervals and higher statistical power for the same sample size. In practice, the sensitivity improvement can be substantial. If only 30% of users reach the changed feature, trigger analysis can improve sensitivity by roughly 3x compared to a full-population analysis.
Confidence runs trigger analysis automatically alongside the standard analysis for every experiment. Teams don't need to configure it or decide in advance whether to use it. Both results appear side by side, so you can see the effect on the full population and on triggered users.
What's the caveat with trigger analysis effect sizes?
This is the part that trips people up. The effect size you estimate from trigger analysis applies to triggered users only. It does not translate directly to the full population.
Say trigger analysis shows a 5% lift in conversion among users who reached checkout. That doesn't mean the feature will produce a 5% lift across all users if you ship it. The full-population effect depends on what fraction of users actually trigger, and that fraction can change after launch (for example, if the feature is promoted more broadly, the triggering population may shift in composition).
The correct interpretation: trigger analysis tells you whether the change works for the people it reaches. Whether that translates to a meaningful full-population impact depends on the trigger rate and whether the triggered population is representative of the broader user base.
At Spotify, teams use trigger analysis to distinguish between "this change doesn't work" and "this change works but not enough users encounter it." Those two conclusions lead to different next steps. The first suggests rethinking the approach. The second suggests improving discoverability.
When should you rely on trigger analysis vs. the full-population result?
Use the full-population intent-to-treat (ITT) analysis as the primary decision metric when the goal is to estimate the overall impact of shipping the change. This is the right number for forecasting business impact, because it reflects the reality that most users won't encounter every feature.
Use trigger analysis when you need to understand mechanism: does the change actually work for users who experience it? It's also the right tool for debugging underpowered experiments. If the ITT result is inconclusive but trigger analysis shows a clear effect, the change probably works but the trigger rate is too low to move the population-level metric.
Confidence presents both analyses by default, so teams don't have to choose one framework in advance. The combination gives you both the business impact estimate and the mechanistic understanding.