Targeting

Control exactly who sees a feature using rules, operators, and target lists

Targeting lets you control which users see a feature. Instead of a simple on/off toggle, you define rules that evaluate against the user's context to decide which variation to serve.

How targeting works

When a flag is evaluated, the SDK checks each targeting rule in priority order. The first rule that matches determines the returned variation. If no rules match, the rollout percentage and default variation are used instead.

Request comes in with context: { userId: "u-42", plan: "enterprise", country: "US" }

Rule 1 (priority 0): plan eq "enterprise"  → variation 0 (true)   ✅ MATCH → return true
Rule 2 (priority 1): country in ["US","CA"] → variation 0 (true)  ⬜ skipped
Default variation                                                   ⬜ skipped

Rule structure

Each targeting rule has four parts:

Part	Description	Example
Attribute	The context property to check	`plan`, `email`, `country`
Operator	How to compare	`eq`, `contains`, `in`
Value	The value to compare against	`"enterprise"`, `["US", "CA"]`
Variation	Which variation to return when the rule matches	`0` (first variation)

Rules also have a priority (lower number = higher priority). Rules are evaluated in priority order and the first match wins.

Operators

Flagpool supports eight operators across three categories:

String operators

Operator	Description	Example
`eq`	Equals	`plan eq "enterprise"`
`neq`	Not equals	`plan neq "free"`
`contains`	String contains substring	`email contains "@company.com"`
`startsWith`	String starts with prefix	`userId startsWith "admin-"`

List operators

Operator	Description	Example
`in`	Value is in list	`country in ["US", "CA", "UK"]`
`nin`	Value is not in list	`country nin ["CN", "RU"]`

Target list operators

Operator	Description	Example
`inTargetList`	Value exists in a named target list	`userId inTargetList "beta-testers"`
`notInTargetList`	Value does not exist in a named target list	`userId notInTargetList "blocked-users"`

Target lists

Target lists are named collections of string values with an attribute key, such as user IDs, email addresses, account identifiers, or other identifiers. The dashboard stores them and makes them available to targeting rules.

Target lists are managed in the dashboard under Target Lists. When exported to the CDN, they are AES-256-GCM encrypted by default. Encryption protects target-list values in the exported payload; flag definitions and targeting rules are not encrypted, and clients that decrypt a list can inspect its values.

An encrypted target-list export requires both the environment's decryptionKey and a platform-specific crypto adapter registered before SDK initialization. See the complete crypto adapter guide for every SDK and runtime. Feature flags and target-list rules are not authorization controls; enforce permissions and entitlements on the server.

Combining rules

You can add multiple rules to a single flag. Rules are independent — each one is evaluated separately in priority order.

Example: Give enterprise users the full feature, give pro users a limited version, and show the default to everyone else.

Priority	Rule	Variation
0	`plan eq "enterprise"`	Full feature (variation 0)
1	`plan eq "pro"`	Limited feature (variation 1)
—	Default	Basic feature (variation 2)

Combining targeting with rollouts

Targeting rules and percentage rollouts work together:

Rules are checked first — if a rule matches, its variation is returned regardless of rollout
If no rules match, the rollout percentage determines whether the user gets the "on" or "off" variation

This lets you do things like "always show the feature to enterprise users, but only roll out to 10% of free users."

Next steps

Contexts — the data you provide for targeting
Rollouts — percentage-based releases
Beta Testing Guide — practical targeting example

Environments Contexts