Targeting

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

Operator	Applies to	Description
`equals`	string, number	Exact match
`not equals`	string, number	Does not match
`in list`	string, number	Value is one of a configured set
`not in list`	string, number	Value is not in the set
`contains`	string	Substring match
`starts with`	string	Prefix match
`ends with`	string	Suffix match
`greater than`	number	Strict numeric comparison
`greater than or equal`	number
`less than`	number
`less than or equal`	number
`exists`	any	Attribute is present in the context
`does not exist`	any	Attribute 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.

React / React Native
.NET

useFlag('checkout.charge-delivery-fee', {
  customerId:    '4821',
  country:       'Nigeria',
  city:          'Lagos',
  platform:      'ios',
  appVersion:    '4.1.0',
  plan:          'enterprise',   // custom attribute
});

var ctx = new EvaluationContext
{
    CustomerId = 4821,
    Country    = "Nigeria",
    City       = "Lagos",
    Platform   = "api",
    AppVersion = "4.1.0",
};

ctx["plan"] = "enterprise";   // custom attribute

Built-in attributes

Attribute	Type	Notes
`customerId`	`string \| number`	Primary bucketing key for rollout
`agentId`	`string \| number`	Secondary bucketing key; used when `customerId` is absent
`businessId`	`string \| number`	Tertiary bucketing key
`businessBranchId`	`string \| number`
`country`	`string`	Full country name (e.g. `"Nigeria"`, `"Ghana"`)
`city`	`string`
`platform`	`string`	`web`, `ios`, `android`, `api`, etc.
`appVersion`	`string`	Semver 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 lets you target on application-specific properties like subscription plan, account type, or experiment cohort, without changes to the SDK or 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:

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).
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.

Get Started

SDKs

Concepts

Rule structure

Conditions

Operators

Multiple conditions (AND)

Evaluation context

Built-in attributes

Custom attributes

Rule ordering

Fallthrough

​Rule structure

​Conditions

​Operators

​Multiple conditions (AND)

​Evaluation context

​Built-in attributes

​Custom attributes

​Rule ordering

​Fallthrough

Rule structure

Conditions

Operators

Multiple conditions (AND)

Evaluation context

Built-in attributes

Custom attributes

Rule ordering

Fallthrough