Last updated
A feature flag (also called a feature toggle) is a switch in your product that turns a feature on or off for a chosen set of visitors without shipping new code. It decides access. In A/B testing, it helps teams define how an experiment is structured, measured, and interpreted before they act on the result.
A feature flag (also called a feature toggle) is a switch in your product that turns a feature on or off for a chosen set of visitors without shipping new code. It decides access. It does not, by itself, decide a winner.
The release and the deploy come apart. Code can sit in production while the flag is off. You then enable it for staff, for 5% of visitors, or for one segment. If the feature misbehaves, you turn the flag off instead of rolling the deploy back. That is the mechanism behind a canary and behind a holdout . An A/B test is the extra step that compares the on and off experiences on a metric you named in advance.
A flag limits the blast radius of a bad release. It also creates a trap: a long-lived flag that nobody removes is a second version of the product hiding in the code. Experiments and flags on the same page can also contradict each other. Mida's flag notes say to use targeting, priority, and mutual exclusion so a visitor does not get two conflicting changes.
A new checkout step is deployed with the flag off. On Monday you enable it for 5% of visitors and watch the error rate. On Wednesday the error rate matches the old step, so you move to 25%. You are not yet claiming the new step converts better. That claim would be an experiment with a primary metric. The flag only controlled who could reach the step.
Name the flag for one behavior, not a bundle of unrelated changes. Decide the audience and the percentage before you turn it on. Watch an error or latency guardrail during the first hours. Remove the flag from the code once the feature is either fully on or deleted. Read Mida feature flagging for the product workflow and the feature-flag post for the release patterns.
A common mistake is treating a 50% flag as an A/B test result. Half the people saw the feature. Unless you randomized them against a control and scored one metric, you have a rollout, not a test. Another mistake is leaving the old branch in the code after the rollout, so the next change has to work in both states.
The feature-flagging page describes web flags for turning an experience on or off, exposing it gradually, and targeting it without a full release. Developers check a flag with mida.onFeatureFlags and mida.isFeatureEnabled, as the flag FAQ states. The same FAQ says Mida supports server-side or full-stack flag workflows when the decision has to happen outside the browser, and that a rollout can be tied to goals, conversions, and revenue. Flags can use the same targeting rules as experiments: URL, device, geography, cookie, segment, event, schedule, and campaign signals.
When you need to know whether the change beats the current experience. A flag that is simply on for 20% of people does not, by itself, give you a control group you are scoring. Add an experiment, or keep a measured holdout, if the decision is about performance rather than access.
Not for the on/off decision. The code that reads the flag ships once. After that, targeting and the percentage exposed can change from the flag controls. A code bug inside the feature still needs a deploy or a kill switch that turns the flag off.
The feature-flag FAQ documents mida.onFeatureFlags, which waits until flags are ready, and mida.isFeatureEnabled, which returns whether a named flag is on. Targeting can use URL, device, geography, cookie, segment, event, schedule, or other visitor rules already listed for experiments.
Visual editor, AI-generated variants with MidaGX, redirect testing, and GA4 integration — free forever in the Mida Sandbox. No credit card required.
Still deciding?
A quick screen share on your actual site — no slides, no generic tour. Just your questions answered.
30 min · no commitment · no sales pressure