Feature Flags

Control which users see which features — without redeploying code.

What Are Feature Flags?

Feature flags let you control which version of a feature your users see. Instead of deploying a change and hoping it works for everyone, you wrap the change in a flag and decide exactly who should see it — by user segment, percentage, device, geography, or any other attribute you choose.

Flags are the foundation of the entire experimentation platform. Every A/B experiment is backed by a feature flag. But flags are also powerful on their own — you can use them for gradual rollouts, kill switches, and feature gating without ever running a formal experiment.

Flag Types

Every flag has a type that determines what kind of values it can return. Choose the type that best fits your use case:

Type	What It Does	When to Use It
Boolean	Simple on/off toggle. Returns `true` or `false`.	Feature gating, kill switches, simple A/B tests.
Percentage	Returns a number between 0 and 100.	Throttling, gradual exposure control, rate limiting.
String	Returns a text value like a color code, copy variant, or feature name.	Multi-variant UI tests, copy experiments, theme selection.
JSON	Returns structured configuration data.	Complex feature configurations, layout settings, multi-parameter tests.

Flag Lifecycle

Flags move through a defined lifecycle. Understanding these states helps you manage flags across your organization:

Status	What It Means
Draft	The flag exists but is not active. No users are affected. Use this state while you are still configuring variations and targeting rules.
Enabled	The flag is live. Targeting rules are being applied and every evaluation is tracked. This is the active state for flags in production.
Disabled	The flag is paused. All users receive the default variation regardless of any targeting rules. Use this to quickly turn off a feature without deleting the flag.
Archived	The flag is no longer in use but is kept as a historical record for auditing and reference.

Variations

Every flag defines two or more variations — the different values the flag can return. Each variation has a unique key, a human-readable name, and a value that matches the flag's type.

For a boolean flag, variations are typically "On" and "Off." For a string flag running a headline test, you might have variations called "Short headline," "Long headline," and "Question headline," each with a different text value.

One variation is always marked as the default. This is the value returned when no targeting rules match, when the flag is disabled, or when something goes wrong during evaluation.

Targeting Rules

Targeting rules let you show different variations to different users. Each rule has a set of conditions (all of which must match) and a traffic split across variations. Rules are evaluated in order — the first matching rule wins. If no rules match, the user gets the default variation.

What You Can Target

Condition Type	What It Checks	Example
Segment	Whether the user belongs to a defined audience segment.	Beta testers, enterprise users, free-tier accounts.
Individual User	A specific user by their ID.	Your QA team, a specific customer for a preview.
Profile Attribute	A property of the user's profile.	Country, subscription plan, signup date, language.
Device Attribute	A property of the user's device or app.	Platform (iOS/Android/Web), OS version, app version, screen size.
Flag Dependency	The current value of another feature flag.	Only show variation B if the user is already seeing the new navigation.

Available Operators

When targeting by profile or device attributes, you have access to a rich set of comparison operators:

Equals / Not Equals — exact match on a value.
In / Not In — value is in (or not in) a list of options.
Contains / Does Not Contain — text includes a substring.
Starts With / Ends With — text begins or ends with a value.
Greater Than / Less Than — numeric comparisons.
Semver Greater / Semver Less / Semver Equals — version string comparisons (useful for targeting specific app versions).

How Evaluation Works

When the system evaluates a flag for a user, it follows a straightforward process:

Check the flag's status. If the flag is disabled, the default variation is returned immediately — no rules are checked.
Walk through targeting rules in order. Each rule's conditions are checked against the user's attributes. The first rule where all conditions match is the one that applies.
Assign a variation. The matching rule's traffic split determines which variation the user gets. This assignment is deterministic — the same user always gets the same variation for a given flag, ensuring a consistent experience.
Fall through to the default. If no targeting rules match, the user receives the default variation.

Assignments are deterministic because they are based on a combination of the user's identity and the flag's salt (a random seed). If you need to reshuffle all assignments — for example, after removing a variation or restarting an experiment — you can regenerate the flag's salt. This gives you a fresh random split while keeping the process fully deterministic.

Live Exposure Tracking

Every time a flag is evaluated, the result is recorded. This gives you a real-time view of how many users are seeing each variation. You can monitor the distribution over any time range to verify that your targeting rules and traffic splits are working as expected.

Exposure tracking is especially valuable when ramping up a rollout — you can confirm that the right percentage of users are seeing the new experience before increasing traffic further.

Feature flags are useful far beyond experiments. Use them as kill switches for risky features, as gates for features under development, or as configuration levers that let you change behavior without a deployment.