Targeting

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 values (user IDs, email addresses, organization IDs, etc.) stored in Flagpool and referenced in targeting rules.

Use cases:

• Beta testers — a list of user IDs who should see beta features
• Enterprise customers — a list of organization IDs with access to premium features
• Blocked users — a list of user IDs excluded from a feature

Target lists are managed in the dashboard under Target Lists. When exported to the CDN, they are AES-256-GCM encrypted so that user identifiers are never exposed in the public flag payload.

To use target lists in client-side SDKs, you need to configure a crypto adapter. See the TypeScript SDK or React SDK docs for details.

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:

1. Rules are checked first — if a rule matches, its variation is returned regardless of rollout
2. 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