Targeting Rules¶

Targeting Rules let you control when an Experience or Experiment applies. Instead of activating a feature for everyone at once, you can pinpoint exactly the users you want — based on their feature flags like country, subscription_plan, account_age, or any other property you decide to track as a feature flag.

How Rules Work¶

A rule is a condition that FlagPal evaluates for each feature flag. If the condition is true, the rule matches. If it doesn't match, the Experience or Experiment doesn't apply to that user.

Every rule has three parts:

Part	Description	Example
Name	The feature flag to check	`country`
Operator	How to compare the value	`equals`
Value	What to compare against	`"DE"`

Put together: "country equals DE" — match users whose country is Germany.

Operators by Type¶

Different property types support different operators:

String Properties¶

Operator	Meaning	Example
`equals`	Exact match	`plan equals "premium"`
`contains`	String includes the value	`email contains "@company.com"`
`in`	String is one of the options	`plan is in one of options: "free", "premium"`

Integer / Number Properties¶

Operator	Meaning	Example
`equals`	Exact number match	`login_count equals 1`
`greater than`	Number is larger	`days_since_signup greater than 30`
`greater than or equal to`	Number is at least	`order_count greater than or equal to 5`
`less than`	Number is smaller	`cart_items less than 10`
`less than or equal to`	Number is at most	`failed_attempts less than or equal to 3`

Boolean Properties¶

Operator	Meaning	Example
`equals`	Is true or false	`is_beta_user equals true`

Array Properties¶

Operator	Meaning	Example
`equal`	Array contains all values	`hobbies is "hiking" and "drawing"`
`contains`	Array includes the value	`roles contains "admin"`
`does not contain`	Array doesn't include the value	`blocked_features does not contain "chat"`

Date Properties¶

Operator	Meaning	Example
`equals`	Exact date	`account_created equals "2024-06-01"`
`before`	Date is earlier	`signup_date before "2024-01-01"`
`before_or_equal`	Date is equal to or earlier	`signup_date before or equal to "2024-01-01"`
`after`	Date is later	`signup_date after "2023-12-31"`
`after_or_equal`	Date is equal to or later	`signup_date after or equal to "2023-12-31"`

Multiple Rules (AND Logic)¶

When you add more than one rule to an Experience or Experiment, all rules must match for it to apply to a user. This is called AND logic.

Example: Show the premium homepage to users who are both on the premium plan and located in the UK.

Feature	Rule	Value
`plan`	`equals`	`"premium"`
`country`	`equals`	`"GB"`

A user on the free plan in the UK → no match.
A user on the premium plan in France → no match.
A user on the premium plan in the UK → match ✓

No Rules = Everyone¶

If you don't add any targeting rules, the Experience or Experiment applies to all users (up to the traffic percentage, if set).

This is useful for:

Rolling out a feature to 100% of users
Gradually increasing traffic on an experiment (start at 10% with no rules, increase over time)

What Targeting Rule options can I use?¶

The options you can use in rules come from your created Feature Flags. Therefore, all of your User properties that you want to target must be included in the Feature Flags you create.

Common properties teams send:

user_id
email (ensure user identifying information is hashed or encypted! FlagPal does not handle this for you)
country
plan (free / starter / premium)
is_beta_user (true/false)
signup_date
days_active
total_orders
last_login_at

If some user property you want to target on isn't available, be sure to create a Feature Flag for it, and set its value in your Application.

Feature Flag names are case-sensitive. Country and country are considered different flags. Make sure the names you use in rules match exactly.

Common Targeting Patterns¶

Beta Users Only¶

is_beta_user equals true

Specific Country¶

country equals "US"

Paid Users Only¶

plan does not equal "free"

New Users (First 7 Days)¶

days_since_signup less than or equal to 7

Power Users¶

total_orders greater than or equal to 10

Company Email Domain¶

email contains "@yourcompany.com"

Exclude Internal Team¶

email does not contain "@yourcompany.com"

Specific User IDs (for testing)¶

user_id equals "user_12345"

Tips for Writing Good Rules¶

Test with a known user first. Before activating an Experience, verify the rules would match the users you intend. Ask your developer to check what properties a test user has.

Start broad, then narrow. If you're unsure about rules, start with fewer/broader rules and refine as you learn.

Check feature flag names carefully. A typo in a flag name means the rule will never match. For example, if your app sends country_code but your rule checks country, it won't work.

Use the Description field. Explain in plain language who this Experience/Experiment targets, so your teammates understand it without deciphering the rules.

Actors — where targeting properties come from
Experiences — using rules to target feature rollouts
Experiments — using rules to target A/B tests