Rules
Every feature has a default value that applies to all users. Rules override that default for the users, environments, and projects you choose.
How Rules Work
A feature's rules are an ordered list. For each request, GrowthBook evaluates them top to bottom and the first matching rule wins. If no rule matches, the default value is used.
Each rule has up to four parts:
- Targeting conditions define who the rule applies to. Conditions are evaluated against the attributes you pass into the SDK. A rule with no conditions applies to everyone.
- What it does for matching users — serve a value, run an experiment, or run a bandit.
- Scope — which environments and, optionally, which projects the rule applies to.
- Release plan (optional) — a value-serving rule can ramp up automatically over time instead of switching on all at once.
Layer multiple rules on one feature to compose behavior — for example, a forced value for beta testers above a gradual rollout to everyone else.
Rule Types
| Targeting rule | Experiment | Bandit | |
|---|---|---|---|
| Purpose | Serve a value to matching users | Measure which value performs best | Auto-optimize toward the best value |
| Randomization | Optional (percentage rollout) | Random split | Random split, reweighted over time |
| Tracking | No | Yes | Yes |
| Typical use | Enable for a group; gradual release | A/B test a change | Maximize a metric across several options |
Gradual ramp-ups and guardrail-monitored "safe" rollouts are not separate rule types — they're release plans you add to a targeting rule.
Targeting Rule (forced value or percentage rollout)
The most common rule serves a single value to the users who match its conditions. In the rule editor it appears as two presets of the same rule:
- Forced value — everyone who matches gets the value.
- Percentage rollout — a random sample gets the value and the rest fall through to the next rule. A forced value is simply a 100% rollout.
For a percentage rollout, choose a user attribute (e.g., id or company) to sample on. Users with the same attribute value always get the same experience — choosing company, for example, keeps everyone at a company on the same side of the rollout.
Common scenarios:
- Turning a feature on for internal employees or beta testers
- Overriding a value for a single account that reported a bug
- Releasing to 10% of users, then 50%, then 100%
To widen a rollout automatically instead of editing the percentage by hand, add a Ramp-up release plan.
Experiment
Experiment rules randomly split users into variations, assign each variation a value, and log every assignment through the SDK's trackingCallback so you can measure impact in your data warehouse or analytics tool.
You control both the percentage of users included and the split between variations. For example, including 50% of users with a 40/60 split means 20% of all users see variation A, 30% see variation B, and the remaining 50% fall through to the next rule.
→ Full experimentation documentation
Bandit
A Bandit rule works like an experiment but automatically shifts traffic toward the better-performing variation as results come in, rather than holding a fixed split. Use it to optimize toward a metric across several options instead of measuring one change precisely.
Contextual Bandits, which choose a variation per user based on their attributes, are in closed beta.
Ramp-ups and Safe Rollouts
ProRamp Schedules is available on Pro and Enterprise plans.
A Ramp Schedule is a release plan you attach to a value-serving (targeting) rule — not a separate rule type. Choose Ramp-up as the rule's release plan to roll out in timed, optionally approval-gated stages that advance on their own (for example, 1% → 5% → 25% → 100%). You widen exposure gradually and can stop early if something looks wrong. This is the modern replacement for manually bumping a rollout percentage.
Safe Rollout is the same mechanism with guardrail monitoring turned on: GrowthBook runs the ramp as a short A/B test against your guardrail metrics (error rate, latency, conversions, …) and flags regressions so you can roll back. If you've used a standalone "Safe Rollout" rule before, it's now a monitored ramp-up rather than its own rule type.
Scoping Rules
Environments
Each rule applies to all environments or a specific set, chosen in the rule's environment scope. Because each SDK connection maps to one environment, this controls where a rule actually takes effect — letting you test a rule in dev before enabling it in production.
Projects
A rule can optionally be scoped to specific projects within the feature's delivery set — an advanced way to run a rule in only some of the projects a multi-project feature reaches. A rule left unscoped applies to all of them; a rule scoped to a project the feature isn't delivered to won't take effect (the editor flags it).
→ Delivering a feature to multiple projects
Scheduling Rules
ProSchedule Feature Flag is available on Pro and Enterprise plans.
Any rule can be scheduled to turn on or off at a specific date and time — useful for launches, holidays, or special promotions.
For a multi-stage rollout that advances automatically, use a Ramp Schedule instead.
Targeting Conditions
Any rule can include targeting conditions to limit which users it applies to. Conditions you define in GrowthBook are evaluated against the attributes you pass into the SDK.
→ Full targeting reference: attributes, conditions, and saved groups
Testing Rules
Test your rules directly in GrowthBook on the Simulation page. Adjust user attributes and see in real time which rules match and what value the user would receive.
Archetypes
ProArchetypes is available on Pro and Enterprise plans.
Archetypes let you save preset user attribute profiles so you can quickly test how rules apply to specific types of users. If you frequently target features to certain groups (e.g., beta testers, enterprise accounts), archetypes let you check the result in one click. They appear at the top of the Simulation page. Hover over any value to see debug information.
Create and manage archetypes by navigating to SDK Configuration → Archetypes.