Targeting conditions are the criteria a feature flag evaluates to decide which variant a user receives. They match against user attributes (country, device type, subscription tier), segment membership, or traffic percentages, and they're how teams control exactly who sees what without deploying new code.
Targeting matters because a flag without conditions is just a global on/off switch. The value of feature flags comes from precision: showing a new checkout flow only to users on iOS 18+, rolling out a pricing change to 5% of free-tier users in Germany, or forcing a QA engineer into a specific variant for testing. Conditions turn a binary toggle into a programmable decision point.
How do targeting conditions work?
A flag rule contains one or more conditions, each specifying an attribute, an operator, and a value. When a flag is evaluated, the resolver checks the user's context against each condition in order. The first rule whose conditions all match determines the variant.
In Confidence, flag rules support typed attributes with operators like equals, contains, semver >=, and in segment. Rules are evaluated top to bottom, and the first match wins. This means rule ordering matters: a specific override rule for internal testers should sit above a broader percentage-based rollout rule.
A typical targeting setup looks like this:
- Rule 1: If user is in segment "internal-testers", serve variant "new-design" (100%).
- Rule 2: If country equals "SE" and app version >= 4.2.0, serve variant "new-design" (20%) or "control" (80%).
- Default: serve "control" (100%).
This structure lets you layer conditions from most specific to least specific, with a deterministic fallback at the bottom.
What attributes can you target on?
Anything you pass into the evaluation context. Common attributes include:
- User properties: user ID, email, account age, subscription plan.
- Device and environment: platform (iOS, Android, web), app version, OS version, locale.
- Geography: country, region, city (derived from IP or passed explicitly).
- Custom segments: pre-defined groups like "beta users" or "enterprise accounts."
- Traffic percentage: a pseudo-random split based on a hash of the user ID, used for gradual rollouts.
Confidence's structured flags extend this further. Because a single flag can carry multiple typed properties (not just a boolean), targeting conditions can route users to variants that differ across several dimensions simultaneously: a layout, a copy string, and a feature limit, all controlled by one flag evaluation.
Why do targeting conditions matter for experiments?
In an A/B test, targeting conditions define the experiment population. If you target "country equals US and platform equals iOS," only US iOS users enter the experiment. Everyone else gets the default experience and isn't part of the analysis.
Getting targeting right has direct statistical consequences. A narrower target population reduces your sample size but increases the homogeneity of the group, which can improve sensitivity. A broader population gives you more traffic but dilutes the effect if the change only matters to a subset of users. This is the same trade-off described in trigger analysis: you want the analysis population to match the people who actually experience the change.
At Spotify, teams running experiments on the mobile home screen use targeting conditions to coordinate across 58+ concurrent experiment teams. Conditions define non-overlapping populations or use Confidence's surface-level coordination to prevent conflicts.