Targeting Conditions
Targeting Conditions
Section titled “Targeting Conditions”A targeting condition is a filter that determines which users a rule applies to. Each rule on a Feature can have zero or more conditions. All conditions on a rule must be true for the rule to match the current user. If any condition is false, the user does not match that rule and GrowthBook moves on to the next one.
Adding a condition in the GrowthBook UI
Section titled “Adding a condition in the GrowthBook UI”- On a Feature’s detail page, click Add Rule (or click the pencil icon on an existing rule).
- In the rule editor, click Add Condition.
- Select the Attribute from the dropdown (e.g.
country). - Select the Operator (equals, not equals, contains, regex, etc.).
- Enter the Value (e.g.
TH). - Click Save Rule.
You can add as many conditions as you need. Each additional condition narrows the audience further.
Condition operators
Section titled “Condition operators”GrowthBook supports a wide range of operators to match different attribute types:
- equals / does not equal — exact match on string, number, or boolean
- contains / does not contain — substring match for strings
- matches regex — test a string against a regular expression
- is greater than / is less than — numeric comparisons
- is in list / is not in list — check whether a value appears in a comma-separated set
Advanced JSON mode
Section titled “Advanced JSON mode”For power users, GrowthBook supports a MongoDB-style condition JSON — the same format used internally by the evaluation engine. Click Advanced in the rule editor to enter raw JSON instead of using the visual builder.
Match users where country is TH and plan is pro:
{ "country": "TH", "plan": "pro"}Match users where email ends with @company.com:
{ "email": { "$regex": "@company\\.com$" }}The advanced editor is useful for complex expressions (nested $or, $and, $not) that the visual builder does not expose.
import { GrowthBook } from '@growthbook/growthbook';
const gb = new GrowthBook({
apiHost: 'https://cdn.growthbook.io',
clientKey: 'sdk-YOUR_DEV_KEY',
});
await gb.init({ timeout: 2000 });
gb.setAttributes({
id: 'user-456',
country: 'TH',
email: '[email protected]',
});
// Returns the feature value if the user matches all conditions on a rule,
// or the default value ('false') if no rule matches.
const isBetaEnabled = gb.getFeatureValue('beta-feature', false);
console.log('beta-feature:', isBetaEnabled);Trade-offs
Section titled “Trade-offs”| Option | Benefit | Cost |
|---|---|---|
| Complex targeting conditions | Much more precise | Harder to debug when results don’t match expectations |
| Simple conditions | Easier to debug | Coarser, covers fewer use cases |
Common mistakes
Section titled “Common mistakes”- Writing self-contradicting conditions (e.g. country = TH AND country = US), matching no users at all
- Nesting so many condition layers that no one on the team can read them
- Not testing the condition against real users before shipping it
💡 Real-world example
Growth teams commonly combine several layers of targeting conditions (country + device + subscription tier) to release a feature to the segment most likely to respond well first.