Calculate a deterministic feature rollout percentage bucket

This calculator hashes a stable user, account, device, or tenant identifier into one of 10,000 deterministic buckets, then compares that bucket with your rollout percentage. It returns the unsigned hash, the readable percentage bucket, and the final inclusion decision. No random value, clock, network request, or stored assignment influences the result, so identical inputs always produce identical output.

Choose an identifier that represents the rollout subject

Start with an identifier that is stable, unique at the level where the feature should be assigned, and available everywhere the decision is made. A user ID is appropriate for a personal interface experiment, while an account or tenant ID is usually better when every member of an organization must see the same behavior. Device identifiers can work for anonymous experiences, but clearing local storage may change the assignment. The calculator treats the identifier as exact text: capitalization, whitespace, punctuation, and Unicode characters all contribute to the hash. Therefore, normalize identifiers before calling the capability if different systems might serialize them differently. For example, decide whether email-like identifiers are lowercased, whether numeric IDs are padded, and whether a namespace such as production or staging belongs in the value. Do not use mutable profile data such as a display name. Once you select a convention, keep it consistent, because changing the identifier changes the bucket even though the underlying person or account has not changed.

Understand the deterministic bucket calculation

The capability encodes the identifier as UTF-8 and applies the 32-bit FNV-1a hash algorithm. The unsigned hash is reduced to one of 10,000 basis-point buckets, displayed as a number from 0 through 99.99. A subject is included when its bucket is strictly lower than the requested rollout percentage multiplied by 100. This boundary rule guarantees the useful endpoints: zero percent includes nobody and one hundred percent includes everybody. It also permits changes in increments of 0.01 percentage points. Because the process has no random seed, time dependency, storage, or network access, the same identifier and percentage always return the same answer. Increasing the percentage preserves all previously included subjects and adds identifiers from the next bucket range; decreasing it removes subjects from the upper end. The hash is suitable for operational rollout assignment, not cryptographic security. Do not treat the returned value as secret, use it to conceal identifiers, or depend on it for authorization decisions.

Use the result safely in a release workflow

Use the included boolean as one input to feature delivery, alongside explicit eligibility rules, environment checks, and emergency overrides. A typical service first excludes unsupported plans or regions, then calculates the percentage assignment for the remaining audience. Store the rollout configuration, not a separate random assignment for every user, because the deterministic calculation recreates the decision whenever needed. Before increasing exposure, compare monitoring and business metrics for eligible cohorts and prepare a fast global disable path. If multiple independent features use the same identifier alone, their bucket ordering will be correlated; add a stable feature key to the identifier, such as feature-name followed by a separator and the user ID, when each rollout needs an independent audience. Keep that feature key unchanged for the life of the rollout. The endpoint rejects percentages below zero or above one hundred instead of silently clipping them, which helps configuration mistakes fail visibly. Calls are priced at $0.002; the browser version uses the same pure calculation for local checks.