Feature Flagging for Marketing Experiments
A feature flag and an A/B test variant are the same mechanism
A feature flag is a runtime switch that controls which code path or configuration a given user sees, decided by a rule (percentage rollout, user attribute, explicit allowlist) rather than a hardcoded value in the deployed code. An A/B test variant assignment is structurally identical — it's a flag that happens to be evaluated for measurement rather than for gradual rollout. This is why platforms like LaunchDarkly, Statsig, GrowthBook, and Split started as feature-flagging tools and expanded naturally into experimentation platforms: the underlying assignment and evaluation infrastructure is the same, only the intent (ship safely vs. measure an effect) differs.
Why flags beat deploy-gated A/B tests
Testing backend logic changes — a new recommendation algorithm, a different pricing calculation, a checkout flow restructure — the old way meant deploying two separate code branches and routing traffic between them at the infrastructure level, which is slow, risky, and hard to turn off quickly if something breaks. A feature flag lets both code paths live in the same deployed codebase simultaneously, with the flag service deciding at runtime which path executes for a given user — meaning a test can be started, adjusted, or instantly killed without a new deployment, and a dangerous variant can be rolled back to 0% in seconds rather than waiting for a rollback deploy.
import { getFlag } from "@experimentation/sdk";
async function getRecommendations(userId: string, cartItems: Item[]) {
// The flag service decides the variant; the exposure is logged
// automatically by the SDK the moment this evaluation happens,
// which is what makes exposure-based (not eligibility-based)
// analysis possible downstream.
const variant = await getFlag("recommendation-algorithm-v2", {
userId,
defaultVariant: "control",
});
switch (variant) {
case "collaborative-filtering-v2":
return getCollaborativeFilteringRecs(userId, cartItems);
case "control":
default:
return getLegacyRuleBasedRecs(userId, cartItems);
}
}Feature flags vs. traditional deploy-based testing
| Dimension | Deploy-gated A/B test | Feature-flag-based test |
|---|---|---|
| Time to start a test | Requires a deployment | Instant — toggle a flag |
| Time to kill a bad variant | Requires a rollback deploy | Instant — set rollout to 0% |
| Testable scope | Mostly front-end/visual changes | Any code path: backend logic, pricing, algorithms |
| Risk of a broken variant reaching 100% | High if rollback is slow | Low — percentage rollout controls blast radius |
Flags enable progressive rollout, which is itself a risk-mitigation strategy
Flag debt accumulates fast if flags aren't cleaned up
Server-side flags and the flicker problem, revisited
Because a feature flag is evaluated server-side (or at the edge) before the response is constructed, flag-based experiments don't suffer from the client-side flicker (FOOC) problem that plagues DOM-rewriting A/B testing tools — the variant is baked into the response from the start. This is a major reason backend and full-stack teams prefer flag-based experimentation platforms over client-side visual testing tools for anything beyond simple front-end copy and layout tests.
What's Next?
Feature flags provide the mechanism for running an experiment safely and measuring it cleanly — but choosing *what* to test in the first place is its own discipline, grounded in structured frameworks for evaluating where a page or flow is actually underperforming.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.