User Targeting & Segments

Targeting lets you control which users see which variation of a feature flag. Instead of turning a flag on for everyone, you can serve different variations based on who the user is, what plan they are on, where they are located, or any other attribute you define.

Evaluation context

When your application evaluates a flag, it passes an evaluation context — a set of key-value attributes describing the current user or request. The SDK sends this context to the Featureflip evaluation service, which uses it to determine the correct variation.

const context = {
  user_id: "user-456",
  email: "[email protected]",
  country: "US",
  plan: "pro",
};

const showFeature = client.boolVariation("new-dashboard", context, false);

You decide what attributes to include. Common choices are user ID, email, country, plan tier, organization ID, and device type. The more attributes you provide, the more flexible your targeting can be.

The user_id attribute is especially important — it is used for consistent percentage rollouts (see Rollout Strategies).

Targeting rules

A targeting rule matches users based on their context attributes and serves them a specific variation. Each rule consists of:

• Attribute — the context field to evaluate (e.g., plan)
• Operator — how to compare (e.g., equals, contains, startsWith, endsWith, in)
• Values — what to compare against (e.g., "pro", "enterprise")
• Variation — which variation to serve when the rule matches

For example, a rule might say: “If country is in ["US", "CA"], serve variation true.”

You can add multiple rules to a flag in each environment. Rules give you fine-grained control without changing application code.

Rule evaluation order

Rules are evaluated top to bottom in the order they appear. The first rule that matches wins, and its variation is served. Remaining rules are skipped.

If no rules match and the flag is enabled, the fallthrough variation is served. This is the default experience for users who are not specifically targeted.

The order matters. Place more specific rules above broader ones:

1. Rule: email equals [email protected] — serve true (specific user)
2. Rule: plan equals enterprise — serve true (all enterprise users)
3. Fallthrough: serve false (everyone else)

You can reorder rules in the Featureflip dashboard by dragging them.

User segments

A segment is a reusable group of users defined by attribute rules. Segments let you avoid duplicating the same targeting conditions across multiple flags.

For example, you might create a segment called Beta Users with the rule: plan equals "beta" OR email ends with "@yourcompany.com". Then, instead of recreating these conditions on every flag, you reference the “Beta Users” segment in your targeting rules.

Segments are useful for:

• Beta programs — define who is in the beta once, reference it everywhere
• Internal teams — target your own employees for dogfooding
• Customer tiers — group enterprise, pro, and free users for different experiences

When you update a segment’s definition, the change takes effect across all flags that reference it. This makes maintenance much simpler than copying rules between flags. See How to Use Segments for a step-by-step guide.

Example flow

Here is how targeting works end-to-end:

1. Your app calls boolVariation("new-checkout", { user_id: "123", plan: "pro" }, false).
2. The SDK sends the evaluation request with the context to Featureflip.
3. Featureflip looks up the “new-checkout” flag in the current environment.
4. The flag is enabled. Featureflip evaluates targeting rules top to bottom.
5. Rule 1: plan equals "pro" — serve true. The context has plan: "pro". Match!
6. Featureflip returns true. The user sees the new checkout.

If the user had plan: "free" and no other rules matched, Featureflip would serve the fallthrough variation instead.

The third argument to boolVariation (false in this example) is the SDK default — the value returned if the SDK cannot reach Featureflip or the flag does not exist. It is a safety net, not a targeting mechanism.

Next steps

• How to Set Up Targeting Rules — step-by-step guide to creating rules in the dashboard
• How to Use Segments — create reusable groups for targeting
• Rollout Strategies — gradual percentage-based rollouts
• Evaluation API — REST API reference for flag evaluation

Frequently Asked Questions

What is user targeting in feature flags?

User targeting lets you control which users see a specific feature variation based on attributes you provide at evaluation time — like user ID, email address, country, subscription plan, or any custom property your application tracks. Instead of rolling a feature out to everyone at once, you can restrict it to a specific customer segment, a geographic region, or users on a particular plan tier. In Featureflip, you define targeting rules per flag per environment. Each rule specifies an attribute, a comparison operator (such as equals, contains, startsWith, or in), and a set of values to match against. When a user’s evaluation context satisfies the rule, they receive the configured variation. Rules are evaluated top to bottom, and the first match wins. This approach lets you do safe internal dogfooding, controlled beta programs, regional feature launches, and enterprise-tier gating — all without changing or redeploying application code.

How do percentage rollouts work?

Percentage rollouts use consistent hashing on a user identifier — typically user_id — to deterministically assign each user to a numbered bucket between 0 and 100. Featureflip combines the user ID with the flag key and hashes them together, so the assignment is unique per flag. If you configure a 30% rollout, users whose hash falls in the 0-30 range receive the enabled variation; the rest receive the control. Because the hash is deterministic, the same user always lands in the same bucket for the same flag — they will not flip between variations across page loads, sessions, or API calls. When you expand from 30% to 50%, you are widening the bucket window; users already in the 30% range stay in. You must include a user_id in your evaluation context for percentage rollouts to work correctly — without a stable identifier, Featureflip cannot produce a consistent hash.

What are segments?

Segments are reusable groups of users defined by attribute-based rules. Instead of duplicating the same targeting conditions across every flag that needs them, you define the group once as a segment and reference it by name in any flag’s targeting rules. For example, you might create a Beta Users segment with the rule: plan equals beta OR email ends with @yourcompany.com. Any flag that needs to target beta users simply references this segment rather than recreating those conditions. When you update the segment definition — say, to add a new email domain — the change propagates immediately to every flag that uses it. Segments are particularly useful for beta programs, internal dogfooding groups, customer tier distinctions like enterprise versus pro, and regional user groups. In Featureflip, you manage segments from the project-level Segments page, and they are scoped per project but available across all environments and flags within that project.