Local Overrides

A local override is a developer-only way to force a unit into a specific experiment group from client code. It is meant for debugging and end-to-end test runs — not for production traffic shaping. Production traffic should always be controlled through the platform via Audience targeting and the experiment's Allowlist.

When to use it

• You are reproducing a bug that only appears in the treatment branch.
• You are recording a demo and want a specific UI variant on screen.
• A QA pass has to walk every variant of an experiment in a single session.

When not to use it

• You want certain employees to always see a specific variant in production. Use the experiment Allowlist in the console; allowlisted units are excluded from analysis automatically.
• You want a kill switch. Use a feature flag with a default value, see Default Values & Fallback.
• You want to run an A/B/A test or other split. Use the platform's traffic allocation; do not build it on top of overrides.

Recommended pattern

The supported way to force a variant during development is to combine the SDK's assignment allowlist (configured on the experiment in the console) with a local feature toggle:

1. In the console, add the developer's unit ID to the experiment's Allowlist for the variant you want them to see.
2. In your client code, gate the override behind a build flag (__DEV__, debug build, or a query string parameter) so it cannot ship to production.
3. Wrap the SDK call in a small adapter that, in dev mode, can return a hard-coded variant without going through getExperiment. Skip the exposure log in this dev branch — exposing forced variants pollutes results.

// JavaScript example: dev-only override before falling back to the SDK
function getVariant(layer, paramKey) {
  if (__DEV__ && window.__OVERRIDES__?.[paramKey] !== undefined) {
    return window.__OVERRIDES__[paramKey];        // do NOT log exposure
  }
  const exp = abc.getExperiment(layer, true);          // normal path
  return exp.getStringValue(paramKey, "control");
}

Honoring the platform's truth in tests

Integration tests that exercise the assignment path (rather than the variant code) should hit the real SDK with a deterministic unit ID rather than overriding the response. The platform guarantees that the same unit ID always lands in the same group, so tests stay reproducible without overrides.