Product feature

Feature flag targeting

Serve the right variation to the right users. Match on any attribute you pass, reuse a segment across flags, and change who is targeted from the dashboard instead of a deploy.

Last updated:

Feature flag targeting serves a chosen variation to the users who match a rule, and the flag's default variation to everyone else. A rule matches attributes you pass at evaluation, such as plan, country, email, or organization, using operators like equals, in, and startsWith, and you can combine conditions with AND and OR. The rules live in the flag configuration, so you change who is targeted from the dashboard and your SDKs pick it up over a streaming connection within seconds, with no redeploy. Each SDK evaluates the context locally, in sub-milliseconds.

Get started freeRead the targeting docs

How Featureflip's targeting works

The pieces that turn "who should see this?" into a rule you set in the dashboard and change without shipping code.

Attribute-based rules

A targeting rule matches an attribute in the user's context against a set of values and serves the variation you choose. Target on user id, email, country, plan, organization, or any custom property your app sends at evaluation. A rule can only read the attributes you pass, so richer context means more precise targeting.

A full operator set

Compare attributes with equals, contains, startsWith, endsWith, and in for membership in a list. Combine several conditions in one rule with AND or OR, so a single rule can say plan is enterprise AND country is in US or CA, without stacking extra flags to express it.

Reusable segments

Define a group once as a segment, for example Beta Users or Enterprise, then reference it by name from any flag's rules instead of copying the conditions. A segment is scoped per project and available across every environment and flag in it. Edit the definition once and every flag that uses it updates.

Per-environment rules

Targeting is set per flag per environment. Staging can serve a feature to your whole team while production targets a single pilot customer, and promoting the rule is a copy rather than a redeploy. Each environment carries its own independent set of rules.

Sub-millisecond local evaluation

Each SDK holds the rules and segments in memory and matches the context you pass locally. There is no network round trip on the request path and no shared targeting service your hot path depends on to stay up, so a targeted evaluation adds no measurable latency.

Live updates over Server-Sent Events

Change a rule and Featureflip streams the new configuration to every connected SDK over its open SSE connection, typically within a second or two, fleet-wide. Opening a feature to a new segment takes effect on the next evaluation rather than the next deploy.

For the attributes, operators, and rule-ordering details in full, see the targeting and segments documentation. For the term on its own, the segment targeting glossary entry has the short version.

Building a targeting rule, step by step

The same four moves cover internal dogfooding, an enterprise-only feature, and a regional launch. Your app supplies the context; the rule decides the variation.

  1. 1

    Pass context on every evaluation

    Send the attributes that describe the user or request, such as user_id, plan, and country, with each flag evaluation. A rule can only act on an attribute your app actually includes, so decide up front what you want to target and put it in the context.

  2. 2

    Add a rule

    In the flag's environment, add a rule: pick an attribute, an operator, and the values to match, then choose the variation to serve when it matches. Add as many rules as the flag needs, and combine conditions with AND or OR inside one rule.

  3. 3

    Order rules and set the fallthrough

    Arrange rules most specific first, since the first match wins, and set the fallthrough variation for everyone no rule singles out. Drag to reorder in the dashboard until the precedence reads the way you intend it to.

  4. 4

    Reuse a segment and change it live

    Pull recurring conditions into a segment and reference it from every flag that targets the same group. When the audience changes, edit the rule or the segment in the dashboard and the update streams to your SDKs in seconds, with no redeploy.

Want the click-by-click version in the dashboard? The guide on setting up targeting rules walks through building one, and using segments covers defining a group once and reusing it.

What it looks like in your app

Your code assembles the context and asks the SDK for the flag's value. The targeting logic lives in the flag configuration, not in these branches, so you change who gets what from the dashboard without touching this code:

const context = {
  user_id: user.id,
  plan: user.plan,
  country: user.country,
};

if (client.boolVariation('new-dashboard', context, false)) {
  return renderNewDashboard(user);
}
return renderLegacyDashboard(user);

Add a rule that serves true when plan is enterprise and only enterprise users hit the new dashboard. The call is identical whether one rule matches or ten. A multivariate flag is the same call with a string default, returning whichever variation the matching rule serves:

// a rule serves "enterprise" to plan=enterprise, "pro" to plan=pro, else the fallthrough
const tier = client.stringVariation('pricing-page', context, 'standard');
render(tier);

You assemble the context once per request and reuse it across every flag. Pick your platform from the SDK overview, and see how the evaluation context feeds targeting for the attributes worth sending.

Targeting composes with the rest of the flag

Rules are one layer of the evaluation, not the whole of it. Featureflip evaluates a flag top to bottom, and targeting sits ahead of the percentage split:

  • Rules run before the percentage rollout. Whoever no rule matches falls through to the flag's percentage split, so a canary rule (internal staff on) and a percentage ramp for everyone else live on one flag.
  • Segments keep an audience in one place. A named segment referenced from many flags means you change a beta cohort or an enterprise list once and every flag that uses it follows.
  • Prerequisites gate before any rule. If the flag depends on another flag being on, that check happens first, so a targeting rule never serves a feature whose prerequisite is off.
  • Every change is auditable. Each rule edit is recorded, so you can see who opened a feature to which segment, and when, alongside the rest of the flag's history.

The same attribute matching drives plan-tier entitlements, beta-program access, and A/B assignment, so one targeting model carries across all of them. Rules are set independently in each environment, so the same flag can target one way in staging and another in production.

Frequently asked questions

What is feature flag targeting?
Feature flag targeting decides which users see which variation of a flag based on attributes you pass at evaluation, rather than turning a feature on for everyone at once. You attach one or more rules to a flag in a given environment; each rule matches an attribute in the user's context, such as plan, country, email, or organization, against a set of values and serves a chosen variation when it matches. Users no rule singles out fall through to the flag's default variation. In Featureflip the rules live in the flag configuration, so changing who is targeted is a dashboard action that streams to your SDKs in seconds, with no code change or redeploy.
What attributes and operators can I target on?
You target on whatever attributes your application includes in the evaluation context. Common ones are user_id, email, country, plan tier, and organization id, plus any custom property you send. Featureflip compares them with operators including equals, contains, startsWith, endsWith, and in for membership in a list. A single rule can combine several conditions with AND or OR, so you can express something like plan is enterprise AND country is in US or CA. The more attributes your app passes, the more precise your targeting can be.
How are targeting rules evaluated?
Rules are evaluated top to bottom and the first match wins: as soon as a user's context satisfies a rule, its variation is served and the remaining rules are skipped. Order matters, so put the most specific rules above broader ones, for example a single admin email above an entire plan tier. If no rule matches and the flag is on, Featureflip serves the fallthrough variation, which is the default experience for everyone you have not singled out. You can drag to reorder rules in the dashboard.
What is a segment and when should I use one?
A segment is a reusable group of users defined by attribute rules, for example a Beta Users group defined as plan equals beta OR email ends with your company domain. Instead of recreating the same conditions on every flag, you define the group once and reference it by name from any flag's rules. Update the segment in one place and every flag that references it picks up the change immediately. Segments are scoped per project and available across all of that project's environments and flags, which makes them the right tool for beta cohorts, internal dogfooding groups, and customer tiers you target repeatedly.
Can I change targeting rules without redeploying?
Yes. Targeting rules are configuration, not code. Add, edit, reorder, or remove a rule in the Featureflip dashboard and the new configuration streams to every connected SDK over Server-Sent Events, taking effect on the next evaluation in a second or two, fleet-wide. Your application binary never changes, so opening a feature to a new segment and closing it again are both dashboard actions rather than deploys.
Does targeting add latency to evaluation?
No. Each SDK holds the flag configuration, including its rules and segments, in memory and evaluates the user's context locally, so a targeted evaluation is a function call with no network round trip on your request path. That is what keeps targeting sub-millisecond and safe to call in a hot loop. Your app supplies the context, the SDK does the matching in process, and streaming keeps the rules current without you polling for changes.

Target your next feature without a deploy

Targeting rules and segments are in every plan, including the free Solo tier: 10 flags, 2 environments, no credit card. Paid plans use flat pricing with no per-seat fees.

Get started freeSee pricing

Related

Targeting & segments (docs)

Evaluation context, the operators, rule-ordering, and how segments are defined and reused.

Set up targeting rules (guide)

A step-by-step walkthrough of building a rule in the dashboard and ordering it correctly.

Use segments (guide)

Define a reusable group once and reference it from every flag that targets the same users.

Percentage rollouts (feature)

The fallthrough split that ramps a feature to the users your rules do not single out.