Targeting and Progressive Rollouts

From on/off to who and how many

The first two chapters treated a flag as a switch. In production, a raw on/off switch is rarely what you want. Turning a feature on for everyone at once is exactly the big bang release that flags were invented to avoid. What you actually want is control over who sees a feature and how many of them - and to widen both gradually while watching for trouble. That is targeting and progressive rollout, and it is where feature flags stop being a nice if statement and start being a delivery strategy.

Two mechanisms do the work: targeting rules decide eligibility, and percentage rollouts decide reach within the eligible set. They compose. Let us build them up.

Targeting rules: deciding who is eligible

A targeting rule is a condition evaluated against the context you pass at flag evaluation time. Recall from chapter one that every evaluation takes a context - a user plus attributes. Targeting rules run against those attributes:

IF user.plan == "enterprise"      -> on
ELSE IF user.country IN ["CA","US"] -> on
ELSE                                -> off

Rules are ordered and the first match wins, much like a firewall config. The attributes you can target on are whatever you attach to the context - plan tier, signup date, email domain, app version, device type, or a custom trait. Platforms like Flagsmith call these traits and let you attach them to an identity; LaunchDarkly calls the reusable groupings segments. The concept is the same: describe a cohort declaratively, then flip features for that cohort without code changes.

Individual targeting is the simplest special case - “turn this on for my own account and the two QA testers.” This is how you test in production safely, a benefit we flagged back in chapter one. You flip the feature on for a named list of users, validate against real data, and only then widen.

Percentage rollouts and the bucketing problem

Once a segment is eligible, you rarely want all of it at once. A percentage rollout releases the feature to a growing slice - 1%, then 5%, then 25%, then everyone. This is the same shape as a canary deployment, except you control it at the flag layer rather than the infrastructure layer, which is faster and finer grained.

The subtle part is consistency. If you naively roll a die per request, a user at 10% would flicker between the new and old experience on every page load. That is unacceptable. The solution every serious platform uses is deterministic bucketing:

1. Take a stable key for the user, usually their id.
2. Hash it together with the flag key: hash(flagKey + ":" + userId).
3. Map the hash onto a 0 to 100 bucket.
4. The user is in the rollout if their bucket is below the current percentage.

Because the hash is deterministic, the same user always lands in the same bucket. Widening from 10% to 20% only adds users; it never reshuffles the ones already in. Including the flag key in the hash means a user who is unlucky on one flag is not automatically unlucky on every flag - the buckets are independent per flag. The practical rule for you as an implementer: always pass a stable user key. Pass a random value and you get flicker and broken experiments. The mechanics here are also what make experiment flags statistically valid, since stable assignment is a prerequisite for measuring a variant honestly. Statsig and GrowthBook build their experiment analysis directly on this bucketing model.

Progressive delivery: the loop that ties it together

Targeting plus percentage rollout gives you the tools. Progressive delivery is the discipline of using them well. The pattern is a loop:

1. Release to a tiny, safe audience - internal users, then 1%.
2. Watch. Error rates, latency, and the business metric the feature is supposed to move.
3. Decide. Healthy signals mean widen; bad signals mean roll back instantly by flipping the flag.
4. Repeat at the next percentage until you reach 100%.

The reason this beats a traditional deploy is the blast radius. A bug that would have hit every user now hits 1% for a few minutes, and the fix is a flag flip measured in seconds rather than a revert and rebuild. This is the core argument of the progressive delivery guide, and the step by step version lives in how to do a canary release. For the menu of specific patterns - ring based rollouts, blue green at the flag layer, and more - feature flag rollout strategies is the reference to keep open.

A concrete rollout might read: internal only on Monday, 1% Tuesday morning, 10% that afternoon once dashboards look clean, 50% Wednesday, 100% Thursday. Each step is gated on monitoring, not on the clock. On anything touching payments, data migrations, or authentication, slow the loop down and add manual verification between steps. On low risk copy changes, you can compress the whole thing into an afternoon.

Automating the ramp

Manually clicking a percentage upward is fine to start, and honestly it is where most teams should begin, because a human watching a dashboard catches things automation misses. As you mature, platforms can automate the ramp: advance the percentage on a schedule, and automatically halt or roll back if a guardrail metric - error rate, latency, conversion - crosses a threshold. LaunchDarkly markets this as guarded releases and Statsig ties it to its metrics pipeline. Automation is a genuine upgrade, but only after you trust your metrics. Automating a rollout that keys off a noisy or wrong metric just lets you ship a regression faster. Earn the automation by first running the loop by hand a few times.

Key takeaways

• Targeting rules decide who is eligible using context attributes; percentage rollouts decide how many of the eligible get the feature. They compose.
• Percentage rollouts rely on deterministic bucketing - hashing a stable user key with the flag key - so users stay put as you widen. Always pass a consistent user key.
• Progressive delivery is the release, watch, decide, widen loop. It shrinks blast radius and makes rollback a flag flip.
• Gate each ramp step on monitoring, not a timer, and slow down for anything touching money, data, or auth.
• Automate the ramp only once you trust the metrics it keys off.

Where to go next

That completes the fundamentals arc - what flags are, the types they come in, and how to release them to the right users gradually. From here, put it into practice: how to implement feature flags covers a real SDK setup, and feature flags best practices keeps your growing flag inventory healthy. When you are ready to pick a platform, how to choose a feature flag tool walks the decision.