Percentage rollout

The SDK hashes the user identifier together with the flag key into a stable bucket from 0–99. A 10% rollout serves the new variation to buckets 0–9. Because the hash is deterministic, raising the percentage to 25% adds users to the enabled cohort without re-randomising the original 10% — a property called sticky bucketing. This is what makes a rollout safe to ramp and safe to compose with experiments. The mechanics are covered in the rollout strategies guide.

A percentage rollout is the mechanism — a flag set to serve N% of traffic. A progressive rollout is the practice of stepping that percentage up over time (1% → 5% → 25% → 100%) while watching metrics at each tier. You need a percentage rollout to run a progressive one; the percentage is the dial, the progression is how you turn it.

The dial controls how many users see the feature. Which users get it is a separate question, answered by a targeted rollout and configured as a rule on the flag: internal staff first, or the accounts in one region. They stack. A rule picks the audience and a percentage ramps inside it. Consistent bucketing depends on a stable identifier arriving in the evaluation context, without which an anonymous caller cannot be held in one cohort from request to request. Exposure is all the percentage buys, and whether the new variation actually performs better belongs to your analytics or experimentation stack. See how percentage rollouts work in Featureflip for the serving side.