How Assignment Works

Assignment is sticky and deterministic. The same visitor sees the same variant for the life of the test. It happens on the HTML request, not in a later JavaScript paint, so CSS/JS/PHP can be in the first response.

Identity

These experiment cookies are separate from cache-safe analytics storage. Analytics can stay in localStorage; experiment assignment still needs a first-party cookie so PHP can choose the variant before HTML is sent.

The assignment flow

  1. A running experiment’s page rules match the current URL.
  2. Audience rules (Pro) and analytics exclusions are applied.
  3. If the visitor already has an assignment row, that variant is reused (and exposure is stamped if it was missing).
  4. Otherwise a 0–9999 bucket is hashed from visitor_id + experiment_id.
  5. If the bucket falls outside “traffic in test”, the visitor is holdout (eligible, not assigned, no variant code).
  6. Otherwise the remaining bucket range is split by variant weights. The chosen arm is stored and marked exposed.
  7. Events are written: experiment_eligible, then experiment_assignment and experiment_exposure for assigned visitors.
  8. The session and (later) the WooCommerce order are stamped with visitor ID and experiment map so purchases still attribute if the session cookie was not written yet.

Eligible, assigned, exposed, holdout

Metric Meaning
Eligible Matched targeting (and was not excluded). Includes holdout.
Assigned Eligible and placed on a variant. Excludes holdout.
Exposed Assigned and actually shown the variant (exposed_gmt is set). Conversion rate uses this as the denominator.
Holdout Eligible but withheld from the experiment. Useful as a “do nothing” baseline when traffic in test is below 100% (Pro).

Mutual exclusivity

If two tests are running at once, a visitor is only assigned to one of them. That keeps results from mixing two treatments on the same person. Prefer one running test unless you have a clear reason to overlap audiences that never share URLs.

What is not counted

Related