Targeted rollout

With a targeted rollout you name the audience up front, and the flag serves whoever matches. A percentage rollout samples across all traffic at random. The two compose. You target an audience and then roll out to a share within it ("enable for 10% of EU enterprise accounts"), which is the shape most real releases take: a canary aimed at internal staff first, then widened. The targeting rules guide shows how the serving is configured.

Reach for it when exposure should follow the user, not chance: shipping to beta opt-ins, enabling a feature only for the plan tier that paid for it (entitlement gating with a feature flag), dogfooding with internal accounts, or honouring data residency by region. Because membership is recomputed at each evaluation, users move in and out of the target automatically as their attributes change, with no redeploy and no manual list-keeping.

A targeted rollout is an ordered list of rules on the flag. Each rule pairs an attribute (plan, country, email, or any custom property your app sets) with an operator such as equals, in, contains, or startsWith, and a variation to serve on a match. Rules are checked top to bottom and the first match wins, which makes order a precedence list, and anything matching no rule falls through to the flag's default. Narrow overrides go first. The attributes are never stored by the flag service. Your application passes them in the evaluation context on every call, which is why a customer who upgrades their plan is targeted correctly on the very next request. Audiences reused across several flags belong in a named segment instead, where widening one cohort becomes a single edit that every flag picks up. Rules are also scoped per environment, which keeps a rollout targeted in staging off in production until you say otherwise.