In an A/B test, what does it mean for a user to trigger into the experiment?

## Two different moments An online experiment records at least two events per user, and confusing them is the single most common source of misread results. **Assignment** is the platform decision: this identifier belongs to control, that one to treatment. It is typically made early and cheaply, often on the first request of a session, and it happens whether or not the user ever goes anywhere near the thing being tested. **Triggering** (also called exposure, or entering the experiment) is the product moment where the assignment can finally make a difference: the user reaches the screen, the code path, or the state in which treatment and control would render or behave differently. Assignment is about bookkeeping. Triggering is about the physics of the change. ## A concrete shape Suppose the change under test is a new control that only appears on the settings page, and roughly 3% of assigned users open the settings page during the experiment window. Every one of those 3% could in principle behave differently depending on their arm. The remaining 97% see byte-identical product in control and treatment. Their sessions, purchases, retention and churn are drawn from exactly the same distribution in both arms. Those untriggered users are not neutral, though. They contribute outcome values to whichever average you compute, and those values carry variance. They add noise to the comparison without being able to add signal. That asymmetry is the whole reason triggering matters to an analyst rather than only to an engineer. ## What makes a good trigger condition A usable trigger definition has four properties. 1. **It is a condition, not an outcome.** Opening the settings page is a trigger. Clicking the new button is not, because only treatment has a new button, so that set does not exist in control at all. 2. **It is evaluated the same way in both arms.** The control code path has to check the same condition at the same point in the flow and record that the user would have qualified, even though nothing visible happens. Without that record you simply have no control group for the triggered set. 3. **It is fixed before launch.** A trigger chosen after the results are in is a knob, and knobs get turned until the number looks good. 4. **It is timestamped.** Knowing when a user triggered lets you count outcomes only from that moment forward, rather than folding in behaviour from before the change could possibly have mattered. ## Why the timestamp matters If a user triggers on day 6 of a 14-day experiment and you count their entire 14 days of activity, the first 6 days are pure pre-exposure noise attached to a treated unit. Restricting the outcome window to post-trigger activity keeps the measured behaviour to the period in which the treatment could have acted. On metrics with heavy per-user variance, that alone can be a large sensitivity gain. ## Triggering is not a licence to delete users A junior instinct on hearing all of this is: fine, throw away everyone who did not trigger. That is one legitimate readout, but it is a different question from the one the business usually asks, and it is only trustworthy when the control-side trigger record is real and the change does not itself alter who qualifies. The safe default readout keeps every assigned user exactly as assigned; the triggered readout is the sharper instrument that has to be earned with correct logging. ## What to take away When someone quotes an experiment result, the first question is: over which users? Everyone the platform assigned, or only the ones who reached the change? The same underlying effect can be quoted as a big number or a tiny one depending purely on that answer, and neither number is wrong as long as it is labelled.