Skip to main content
Targeting rules let you serve specific values to specific users based on attributes you pass at evaluation time. Rules are evaluated in order — the first rule whose conditions all match determines the returned value. If no rule matches, evaluation falls through to the global rollout or the flag’s default value.

​
Rule structure

Each rule consists of:
  • Conditions — one or more attribute checks that must all pass (AND semantics)
  • Serve — the value to return when all conditions match
IF  country equals "Nigeria"
AND platform equals "ios"
THEN serve "variant-a"
You can create as many rules as needed. Rules execute top-to-bottom; the first match wins and evaluation stops.

​
Conditions

A condition evaluates an attribute from the evaluation context against a configured value using an operator. Attribute names correspond to the fields in EvaluationContext, or any custom key-value pair you include.

​
Operators

OperatorApplies toDescription
equalsstring, numberExact match
not equalsstring, numberDoes not match
in liststring, numberValue is one of a configured set
not in liststring, numberValue is not in the set
containsstringSubstring match
starts withstringPrefix match
ends withstringSuffix match
greater thannumberStrict numeric comparison
greater than or equalnumber
less thannumber
less than or equalnumber
existsanyAttribute is present in the context
does not existanyAttribute is absent from the context

​
Multiple conditions (AND)

All conditions in a rule must match. There is no built-in OR within a single rule — to express OR logic, create separate rules. 
Rule 1: country equals "Nigeria"  AND  platform equals "ios"   → serve "variant-a"
Rule 2: country equals "Ghana"                                 → serve "variant-b"
Rule 3: (no conditions)                                   → serve "control"     ← catch-all
A rule with no conditions always matches. Use it as the last rule to define a catch-all when you want explicit control over the fallthrough value rather than relying on the global rollout.

​
Evaluation context

The evaluation context is the set of attributes you pass when calling a flag hook or method. The SDK makes these available during rule evaluation. 
useFlag('checkout.charge-delivery-fee', {
  customerId:    '4821',
  country:       'Nigeria',
  city:          'Lagos',
  platform:      'ios',
  appVersion:    '4.1.0',
  plan:          'enterprise',   // custom attribute
});

​
Built-in attributes

AttributeTypeNotes
customerIdstring | numberPrimary bucketing key for rollout
agentIdstring | numberSecondary bucketing key; used when customerId is absent
businessIdstring | numberTertiary bucketing key
businessBranchIdstring | number
countrystringFull country name (e.g. "Nigeria", "Ghana")
citystring
platformstringweb, ios, android, api, etc.
appVersionstringSemver string — supports prefix matching for version ranges

​
Custom attributes

Any key-value pair you include beyond the built-in attributes is passed through to the evaluation engine and can be referenced in targeting rules by name. This allows you to target on application-specific properties — subscription plan, account type, experiment cohort, etc. — without changes to the SDK or the backend.

​
Rule ordering

Rules are evaluated top-to-bottom. The first rule whose conditions all match wins; subsequent rules are not evaluated. Order rules in the dashboard by dragging them to set priority. Example: A rule that matches a specific customer ID should appear before a broader country-level rule, or it will never be reached if the country rule matches first.

​
Fallthrough

When no targeting rule matches, evaluation falls through in this order:
  1. Global rollout — if rollout is configured, the user is deterministically bucketed into the traffic split. The returned reason is ROLLOUT (boolean) or SPLIT (multi-value).
  2. Default value — if no rollout is set, the flag’s configured default value is returned. The returned reason is DEFAULT.
See Evaluation for the complete evaluation algorithm and all reason codes.