A feature flag with only an on and off position is a blunt tool. Segments make it precise.

What is a feature flag, briefly?

A feature flag is a switch in your application that decides whether some behaviour is active. The code for a new feature is shipped, but it stays hidden until the flag is turned on. The decision lives in a service such as Flagsmith, outside your code, so changing it needs no new deployment. This separates deploying code from releasing a feature, which is the single biggest reason teams adopt flags.

The problem with “everyone or no one”

A plain switch has two outcomes. Everyone gets the feature, or nobody does. That is rarely what a real release needs. New features are risky, so you want a small, friendly audience first. Some features belong only to paying customers. Some should appear only in countries where you have a legal licence. Some should be hidden from people running an old app version that cannot display them. Each of these is a question about who the user is, not just a question about whether the feature is ready.

What is a segment?

A segment is a saved description of a group of users, built from facts about those users. You give it a name, such as “premium customers in India”, and you describe the group using rules. From then on, Flagsmith can answer a simple question for any user: do you belong to this group or not? Flags can then behave differently for members of the group, which is called a segment override.

Why define the group once?

You could, in theory, write the audience rules separately on every flag. That would quickly become a mess. If the definition of “premium customer” changes, you would have to hunt through dozens of flags to update each copy. A segment solves this by keeping the definition in one place. Change the segment, and every flag that uses it follows automatically. This is the same reasoning that makes programmers put repeated code into one shared function.

Almost everything in targeting uses the same few terms. Learn them once and the rest of this guide reads smoothly.

flowchart TD
    SEG["Segment: Premium customers in India"] --> R1["Rule group 1: ALL of the following"]
    SEG --> R2["Rule group 2: ANY of the following"]
    R1 --> C1["Condition: plan equals premium"]
    R1 --> C2["Condition: country equals IN"]
    R2 --> C3["Condition: app_version at least 4.2.0"]
    R2 --> C4["Condition: platform equals web"]
    SEG -. "used by" .-> OV["Segment override on a flag in one environment"]

Read the figure from the top. One segment holds one or more rule groups. Each rule group holds conditions and states how they combine. Every condition is a single test about a trait. The dotted arrow at the bottom shows that a flag uses the whole segment through an override, so the flag never needs to know how the audience was built. This layering is what lets you change the rules without touching a single flag.

Segments are shared, overrides are local

A segment is defined at the project level, so the same definition is available in every environment. The override, which says what members receive for a particular flag, is stored per environment. This means “internal staff” can mean the same thing in Development, Staging and Production, while the flag’s behaviour for them can differ in each. Understanding this split avoids many surprises when moving settings between environments.

Rules can only judge what they can see. Before writing a single condition, you must know where the facts come from.

No identity, no segment

Segments work on identities. When your application asks Flagsmith for flags without saying who the user is, Flagsmith can only return the environment’s default values. It has nobody to test against. To use segments, your application must identify the user, passing a unique identifier, and usually a set of traits at the same time. Only then can the rules be evaluated for that person. This is the most common reason that a segment seems to “do nothing” during a first trial.

Where traits come from

Traits are supplied by your own application, since only it knows the facts. A web shop might send the customer’s plan, signup date, country and number of past orders. A mobile app might add the app version, the operating system and the device type. Traits can be sent each time the user is identified, and Flagsmith can also store them so they are remembered between visits. The choice between sending and storing depends on how your systems are arranged and which version of Flagsmith you use.

Types of traits

A trait has a value, and a value has a type. Text such as a country code is a string. A whole number such as the count of past orders is an integer. A decimal number such as a lifetime spend is a float. A true or false fact such as “has verified email” is a boolean. Flagsmith keeps the type with the trait and compares accordingly. The same characters can mean different things: the text “10” and the number ten behave differently when ordered. Sending numbers as numbers, not as text, is therefore important for greater-than and less-than conditions.

Storing and sending traits wisely

Every segment, however complicated it looks, is built from one small repeating shape.

What is a condition?

A condition is a single yes-or-no test about an identity. It has three parts. The property says which fact to look at, usually the name of a trait. The operator says how to compare it. The value says what to compare it with. Together they read like a short sentence: “country equals IN”, “orders is greater than 5” or “email contains example.com”. When Flagsmith evaluates the condition for a user, the answer is either true or false.

What is a rule?

A rule is a container for conditions. It decides how their separate answers combine into one answer. Flagsmith offers three kinds of rule type. An “all” rule is true only when every condition inside it is true, which behaves like the word AND. An “any” rule is true when at least one condition inside it is true, which behaves like the word OR. A “none” rule is true only when no condition inside it is true, which behaves like “NOT any of these”.

How rule groups combine

A segment can hold several top-level rules. They combine like the word AND: the user belongs to the segment only when every top-level rule is true. Inside a rule, conditions combine according to the rule’s type. Rules can also be nested, so that a rule contains other rules. Nesting is what lets you express statements such as “on the paid plan, and either in India or in a country with a local partner, and not a test account”.

flowchart LR
    U["User with traits"] --> T1{"Rule 1 ALL: plan is pro and orders over 3"}
    T1 -- "false" --> OUT1["Not in segment"]
    T1 -- "true" --> T2{"Rule 2 ANY: country is IN or country is NP"}
    T2 -- "false" --> OUT1
    T2 -- "true" --> T3{"Rule 3 NONE: is_test is true or is_staff is true"}
    T3 -- "false" --> OUT1
    T3 -- "true" --> IN1["In the segment"]

The figure follows one user through three top-level rules. First, the user must be on the pro plan and have placed more than three orders. If either is false, the journey ends and the user is outside the segment. Second, the user must be in India or Nepal, where only one of the two conditions is needed. Third, the user must not be a test account or a staff account, which is what a “none” rule checks. Only a user who passes every checkpoint reaches the segment. Reading the rules as a series of gates is a reliable way to predict the result.

The first family of operators asks whether a trait matches, differs from or ranks above or below a value.

Equals and not equals

“Equals” is the simplest condition: it is true when the trait’s value is the same as the one you typed. It suits fixed vocabularies such as plan names, country codes and roles. “Not equals” is its opposite, true when the trait’s value differs from the one you typed. Both are strict. A trait of “Premium” does not equal “premium” if the system treats letter case as significant, which is common, so agree on one style and check how your version behaves.

Greater than and less than

The ordering operators compare numbers. “Greater than” is true when the trait is above the value, and “less than” when it is below. Flagsmith also offers inclusive forms, “greater than or equal” and “less than or equal”, which are true when the trait equals the value as well. The difference matters at the edge. A rule that says “orders greater than 5” excludes someone with exactly five orders, while “greater than or equal to 5” includes them.

Semantic versions

App versions such as 4.2.0 and 4.10.0 are not ordinary numbers or ordinary text. As text, “4.10.0” sorts before “4.2.0” because the character “1” comes before “2”. As a decimal number, it is not even a valid number. Flagsmith therefore supports comparing semantic versions, where each dot-separated part is compared as a number in turn. When you want to say “app version at least 4.2.0”, the condition value must be marked as a semantic version, which the dashboard offers as an option in recent versions. Check your documentation for the exact way it is marked in your version, and always test with versions on both sides of the boundary.

The second family of operators looks inside text, checks lists, and asks whether a trait exists at all.

Contains and does not contain

“Contains” is true when the trait’s text includes the given piece anywhere inside it. A segment for a partner company’s staff might say “email contains partner.example.com”. “Does not contain” is the reverse. These operators are flexible, but they are also easy to over-match. The text “pro” is contained in “professional” and in “improve”, so a short fragment can capture people you never intended. Prefer longer, more distinctive fragments, or use an exact equals when the vocabulary is fixed.

The “in” operator

“In” checks whether the trait’s value is one of a list of values, separated by commas. It is shorter and clearer than a long “any” rule full of separate equals conditions. For example, “country in IN, NP, BD” means the country is India, Nepal or Bangladesh. Because it matches whole values, not fragments, it avoids the over-matching trouble of “contains”.

Is set and is not set

Sometimes the question is not what a trait is, but whether you know it at all. “Is set” is true when the identity has a value for the trait. “Is not set” is true when it does not. These are the correct way to handle missing information. For example, you might give a feature to everyone for whom a “preferred_language” is not set, using a default. Do not try to test emptiness with a not-equals condition, because the way missing traits are treated in other operators may surprise you, as later chapters explain.

Regular expressions

A regular expression, often shortened to regex, is a compact pattern language for describing text. It can express things that “contains” cannot, such as “starts with a letter followed by exactly four digits” or “ends with either .edu or .ac.uk”. Flagsmith’s regex operator is true when the trait’s text matches the pattern you supply. Regex is powerful, and it is also the easiest operator to get subtly wrong. Patterns that look right can match more or less than you expect, and the exact flavour of pattern language depends on the engine evaluating it, so keep them short and test them on many sample values.

Some conditions do not look at a trait you sent. They look at the identity itself, at the environment, or at a number made from the identity.

Percentage split

The percentage split operator is true for a chosen share of users, such as ten percent. It does not look at any trait. Instead, Flagsmith turns the user’s identifier, mixed with something unique to the segment, into a number between zero and one hundred, and the condition is true when that number falls under your chosen percentage. Because the calculation is repeatable, the same user always lands on the same side. Chapter 10 explains why this stability is so valuable.

Modulo

The modulo operator divides a numeric trait by a number you choose and checks the remainder. It is useful for splitting people into repeating groups by a number they already have, such as a customer number. If you divide by two and look for a remainder of zero, you select every even number. If you divide by ten and look for a remainder of three, you select one tenth of customers, those whose number ends in three. It is an old, dependable trick for creating stable test groups from numeric identifiers, though the percentage split is usually easier.

Built-in properties

Besides traits you send, Flagsmith can expose a few built-in properties to rules. In recent versions, these include the identity’s own identifier and the name of the environment being asked about. A rule on the identifier lets you target a known list of users without inventing a trait for them. A rule on the environment name lets one segment behave differently in Staging and Production, though this should be used sparingly, because it hides environment differences inside the rule itself. Check your version’s documentation for the exact names of these properties and whether they are available to you.

Individual conditions are easy. The errors creep in when you combine them, so a little logic goes a long way.

The three connectors

Every audience description is built from three connecting ideas. AND narrows the audience, because a person must satisfy both sides. OR widens the audience, because a person need satisfy only one side. NOT flips an answer, turning a match into a non-match and the reverse. In Flagsmith, AND and OR are expressed by the “all” and “any” rule types, while NOT is expressed by the “none” rule type, and by operators with a negative meaning such as “not equals”.

The two classic traps

The first trap is mixing up the meaning of “none” with “not all”. A “none” rule is true only when every condition inside it is false. If you write “none of: is_test is true, is_staff is true”, then a person who is staff is excluded even though they are not a test account. People who intended to exclude only those who are both test and staff have written the wrong rule. Say aloud what you mean: “exclude anyone who is a test account, and also exclude anyone who is staff” is a “none” rule, while “exclude people who are both” needs a different structure.

The second trap is a negative that does not behave as hoped. Suppose you want everyone who is not on the free plan. A “plan not equals free” condition seems perfect, but if some users have no plan trait at all, the way the missing value is handled may leave them out. The safer wording is often a positive list, such as “plan in pro, team, enterprise”, because it says exactly who should be included instead of describing everyone else.

A reliable method

Reading about operators is useful. Seeing complete segments for realistic needs is better.

Each example below describes an audience in words, then shows how its rules are put together. They are built for an imaginary online shop called BrightCart, which sends traits named plan, country, orders, app_version, platform, email and is_test.

A percentage rollout looks trivial, but a surprising amount of good engineering sits behind the phrase “ten percent of users”.

Why not simply flip a coin?

Imagine deciding on every page load, with a random number, whether to show the feature to ten percent of people. A single visitor would see the new design on one page, the old design on the next and the new design again after a refresh. The experience would flicker, bug reports would be impossible to reproduce and any measurement of the feature’s effect would be meaningless. What you want is for each person to be assigned once, and to stay assigned.

How stable assignment works

Flagsmith takes the user’s identifier, mixes it with something specific to the segment, and passes the result through a mathematical scrambling function called a hash. The output looks random but is completely repeatable: the same input always produces the same number. That number, scaled to the range zero to one hundred, is compared with your chosen percentage. Because the same person always produces the same number, they always get the same answer, on every device, as long as their identifier does not change.

Widening a rollout keeps early users

Because assignment depends only on the user’s position in the scrambled order, raising the percentage from ten to twenty-five keeps everyone who was already in and adds more. Nobody who had the feature loses it as you widen. This is why you can start small and expand with confidence, knowing that early users keep a consistent experience.

Different segments pick different people

Since the calculation mixes in something unique to each segment, two segments with the same ten percent do not select the same ten percent of users. This is useful. Two unrelated experiments will not accidentally land on exactly the same unlucky group. If you need two features to reach exactly the same people, build one segment and use it on both flags.

Common mistakes with percentages

A segment on its own changes nothing. It becomes meaningful when a flag uses it, and when several segments compete, order decides the winner.

What is a segment override?

A segment override is an instruction attached to a flag, in one environment, saying “for members of this segment, behave like this”. The override can set its own enabled position and, for remote configuration flags, its own value. Members of the segment receive the override’s answer. Everyone else keeps receiving the flag’s default answer for the environment.

When a user belongs to several segments

One person can match many segments at once: a premium customer, in India, on iOS, in the staff group. If the flag has overrides for several of those segments, Flagsmith needs a tie-breaker. It uses the order of the override list. The segments are checked from the top, and the first one the user belongs to supplies the answer. Segments lower down are ignored for that flag. You control the order by dragging overrides up and down in the flag’s screen.

flowchart TD
    A["Flag requested for an identity"] --> B{"Identity override exists?"}
    B -- "Yes" --> R1["Use the identity override"]
    B -- "No" --> C{"In first segment override?"}
    C -- "Yes" --> R2["Use the first matching segment override"]
    C -- "No" --> D{"In next segment override?"}
    D -- "Yes" --> R3["Use that override"]
    D -- "No" --> E["Use the environment default value"]

Follow the arrows from the top. When a flag is requested for an identity, Flagsmith first checks whether that specific person has a personal override. If they do, that is the answer, and nothing else is considered. Otherwise it walks down the list of segment overrides in priority order and stops at the first segment the person belongs to. If the person matches none, the environment’s default value is returned. The figure shows only two segment steps, but the list can be longer.

Ordering advice

Watching one request travel from your application to Flagsmith and back makes every earlier chapter click into place.

sequenceDiagram
    participant APP as Application
    participant SDK as Flagsmith SDK
    participant FS as Flagsmith
    participant ENG as Rule Engine
    APP->>SDK: Identify user with traits
    SDK->>FS: Request flags for this identity
    FS->>ENG: Evaluate segments for the identity
    ENG->>ENG: Check each rule group and condition
    ENG-->>FS: Return matching segments
    FS->>FS: Apply identity and segment overrides in order
    FS-->>SDK: Return flag values for this user
    SDK-->>APP: Flags ready to use

The application starts by telling the SDK who the user is and what is known about them. The SDK sends this to Flagsmith, asking for the flags that apply. Flagsmith hands the identity and traits to its rule engine, which walks through every segment relevant to the requested flags, checking each rule group and each condition. The engine reports which segments the user belongs to. Flagsmith then applies the overrides in priority order, as Chapter 11 described, and returns the final flag values. The SDK passes them to the application. This whole journey usually takes a fraction of a second.

Evaluation on your own server

For high-traffic backends, Flagsmith’s server-side SDKs offer a local evaluation mode. Instead of asking Flagsmith each time, the SDK downloads the environment’s complete rule set, including segments and overrides, and runs the same rule engine inside your own service. Answers become extremely fast, and the application continues to work if the network to Flagsmith is briefly interrupted. The trade-off is a short delay before rule changes reach your servers, as the SDK refreshes on a timer. Check your SDK documentation for the refresh interval and any differences in supported features.

What the engine needs from you

Real data is never as tidy as examples. These are the situations that produce the strangest segment behaviour.

The trait that is not there

Not every user has every trait. A brand-new visitor may have no plan, no country and no order history. For most operators, a condition on a missing trait simply does not match, because there is nothing to compare. This is usually what you want. The surprising cases come from negative operators. A condition such as “plan not equals free” might not match a user with no plan at all, since there is no value to be different from. Behaviour in edge cases can differ between versions and operators, so always test missing traits explicitly instead of assuming.

Wrong type, wrong result

If a number is sent as text, an ordering condition may not behave as expected. The text “9” is considered greater than the text “10” in dictionary order, because “9” comes after “1”. Sending the count of orders as a real number avoids the problem. Similarly, sending the word “true” as text where a true-or-false value was expected can lead to a condition silently failing to match. Agree on types in your application, and keep them consistent across web, mobile and backend code.

Capital letters, spaces and spelling

Strings usually need to match exactly, including letter case and any hidden spaces at the start or end. A plan sent as “Pro ” with a trailing space is not the same as “Pro”, and neither is “pro”. These mistakes are invisible on the screen and very frustrating to find. Clean values in your application before sending them, preferably to a lowercase, trimmed form, and document the permitted vocabulary.

A segment is a small program written in clicks. Like any program, it deserves tests, and the tests are cheap.

Why test at all?

A wrong segment is a quiet failure. Nothing crashes. A feature simply reaches too many people, too few people or the wrong people, and the mistake can stay hidden for weeks. The cost is not a technical error message but a confused customer, a leaked feature or an experiment whose results cannot be trusted. A few minutes of deliberate testing before a segment goes live is the best value in the whole process.

The test identity matrix

The most reliable technique is to create a small set of test identities, each designed to prove one thing. For every segment, include at least one person who should be inside, and several who should be outside for different reasons: one failing each condition, one with a missing trait and one sitting exactly on a boundary value. Then check, for each of them, what the flag returns.

Using the dashboard to help

Flagsmith’s dashboard can show which stored identities currently match a segment, when traits are saved against identities. This is a helpful sanity check: the list should look like the audience you meant. It cannot replace tests that include missing and edge-case data, because those identities may not exist yet. You can also create identities by hand in a non-production environment, give them chosen traits and see the flag values they would receive.

Automated checks

Segments are shared across a project, but their effects are decided separately in each environment. This split is the source of many puzzling moments.

Define once, override separately

When you create a segment, it exists for the whole project. The same name and the same rules are available in Development, Staging and Production. What differs is whether a given flag has an override for the segment in each environment, and what that override says. A flag might give the staff segment the new behaviour in Staging, but have no override for it yet in Production.

One edit, many environments

Because the rules are shared, editing a segment changes it everywhere at once. Add a condition in Development while experimenting, and the same condition is now in force in Production, for every flag that uses the segment. This is convenient and dangerous in equal measure. Experiments with new rules belong in a copy of the segment, or in a feature-specific segment, until you are sure. Never use the shared, production-facing version as a scratchpad.

flowchart LR
    SEG["Segment: Premium India, defined once"] --> DEV["Development: override on, value practice"]
    SEG --> STG["Staging: override on, value practice"]
    SEG --> PRD["Production: override on at 10 percent, value live"]

The figure shows a single segment feeding three environments. The audience definition is identical in all three, because it comes from the one segment. The consequences differ: Production uses the real value and a small percentage, while the lower environments use practice values. When you promote a flag from Staging to Production, you recreate the override in Production, but you do not need to recreate the segment.

Safe habits

Most useful segments fall into a handful of familiar shapes. Recognising them speeds up design and makes segments easier for others to read.

Naming that explains itself

Names are the cheapest documentation a segment has. Describe the group in business words, not in rule-language. “Premium customers in India” reads well in an override list. “plan eq premium and country eq IN” explains how the group is built, which anyone can see by opening it, but not why it exists. Keep a single style, and avoid dates, people’s names and temporary words such as “new” or “test2” which are meaningless a month later.

Small, composable segments

A common design question is whether to build one large segment with many conditions or several small segments. Small segments are easier to understand and reuse. Large ones are easier to read in one place but harder to change safely. A good habit is to keep each segment to one clear idea, such as “premium customers”, and to combine ideas at the flag level through ordered overrides rather than stuffing every possible combination into a single segment.

An anti-pattern is a habit that looks reasonable and causes trouble later. These five are the most common in targeting rules.

A single segment check costs almost nothing. Millions of checks, each against dozens of segments, are worth thinking about.

What makes evaluation heavier?

Evaluating a segment means walking its rules and testing each condition against the user’s traits. A segment with three conditions takes negligible time. A segment with fifty conditions, several regular expressions and long lists of values takes longer, and a flag with twenty overrides multiplies that cost. For one request, the total is still tiny. For a busy service handling thousands of requests each second, small costs add up, and the simplest rules are the cheapest.

Habits that keep targeting fast

Targeting rules are built from information about people. That information deserves care, whatever the size of your company.

Data minimisation

Data minimisation is the principle of collecting and sending only what is needed for a stated purpose. Every trait you send to a flag service is a piece of personal information in another system. If a segment needs to know whether a customer is in the paid tier, send “paid” or “free”, not their billing history. If it needs a rough region, send a country code, not a home address. Smaller, simpler traits reduce risk, speed up evaluation and make privacy reviews easier.

Traits that should not be sent

Client-side visibility

When an application running on a user’s own device asks for flags, it can see the answers it receives. Flag values and, in some arrangements, the existence of flags are visible to a determined person inspecting the app. For this reason, never place secrets or private business information in remote values, and never rely on a client-side segment to hide something that is truly confidential. Treat everything a client can read as readable by the user.

Fairness and responsibility

Targeting decides who gets what, and some decisions have consequences beyond convenience. Offering a discount only to some groups, or withholding a service from others, can raise fairness and legal questions. Before building segments that affect prices, access or opportunity, ask whether the rule could treat people unfairly, and involve your legal and product colleagues where the stakes are real. A simple technical rule can have a serious human effect.

Sooner or later, someone will ask this question. A calm, ordered method answers it quickly almost every time.

flowchart TD
    A["User reports wrong flag value"] --> B{"Was the user identified?"}
    B -- "No" --> B1["Identify the user and retry"]
    B -- "Yes" --> C{"Correct environment key?"}
    C -- "No" --> C1["Use the key for the right environment"]
    C -- "Yes" --> D{"Traits arrived with right names and types?"}
    D -- "No" --> D1["Fix the trait names or types in the app"]
    D -- "Yes" --> E{"Each condition true for these traits?"}
    E -- "No" --> E1["Correct the condition or the data"]
    E -- "Yes" --> F{"Higher priority override wins?"}
    F -- "Yes" --> F1["Reorder overrides or adjust the winning one"]
    F -- "No" --> G{"Cache or refresh delay?"}
    G -- "Yes" --> G1["Wait one refresh period and retest"]
    G -- "No" --> H["Check identity overrides and audit log"]

The figure moves from the most common causes to the least. First, confirm the user was identified at all, since anonymous requests skip segments. Second, confirm the key belongs to the environment you think you are looking at. Third, check that the traits arrived with the exact names and types the rules expect. Fourth, work through each condition by hand with the actual trait values. Fifth, look for a higher-priority override that is winning. Sixth, allow for caching delay. Finally, look for a personal identity override and read the audit log for recent changes.

Common symptoms and causes

Segments are easy to create and easy to forget. A light set of habits keeps the list useful as the product grows.

What is governance?

Governance is simply a set of agreed rules about who may do what, and a way of checking that the rules are followed. For segments, it answers practical questions. Who may create a segment? Who may change one that other people depend on? How do we find segments nobody uses any more? Who decides when a segment is retired? A small team can answer these in a shared document. A large organisation may use roles, reviews and regular audits.

The life of a segment

Who needs which permission?

A simple review routine

Segment-based targeting is a powerful idea with real costs. Seeing both sides helps you apply it where it pays.

Rules in Flagsmith or logic in your own code?

Sometimes it is not obvious whether a decision belongs in a segment rule or in your own application. A useful guideline is to ask who needs to change it, and how often. If a product manager should be able to widen an audience without a developer, or the answer changes weekly, a segment is a good home. If the decision involves complicated business logic, many data sources or strict security, keep it in code, and send the final yes-or-no result to Flagsmith as a simple trait that segments can use.

Experienced teams repeat a short list of habits. Newer teams repeat a short list of mistakes. Here are both.

Habits worth building

Mistakes to catch early

To finish, here is one imaginary feature taken from idea to full release, using everything in this guide.

BrightCart, the imaginary online shop, wants to launch “express reorder”, a button that lets loyal customers repeat a past order in one tap. The team wants staff to try it first, then a beta group who opted in, then ten percent of loyal customers on supported mobile apps, and finally everyone loyal. Nobody who is a test account should ever count in the numbers.

What would have gone wrong without the routine?

Suppose the team had compared versions as text. Customers on version 4.10.0 would have been judged older than 4.2.0 and excluded from the feature, while customers on 4.1.9 might have received a button their app could not display. Suppose the team had forgotten the “none” rule on test accounts. The ten percent group would have included automated tests, distorting every number the team measured. Suppose the team had used a percentage split on an identifier that changes at login. Customers would have seen the button appear and vanish as they signed in. Each of these is an ordinary mistake, and each is caught by the habits in this guide.

Segments do more than switch features on and off. They can also change the value a flag carries, and even choose between several variants.

Remote values per audience

A Flagsmith flag can carry a value as well as an on or off position. The value might be a banner message, a number such as a maximum upload size, or a small block of settings. A segment override can supply its own value, so different audiences receive different values from the same flag. For example, a flag named upload-limit might carry fifty megabytes for everyone, two hundred for the premium segment and five hundred for the enterprise segment. The application asks one question and each customer receives the answer suited to them.

This is a tidy way to express entitlements and limits. The code reads a single flag and uses whatever number comes back. Pricing and product teams can then adjust each audience’s limit without asking for a new release. The price of this convenience is that the meaning of each value must be agreed in advance, since the application trusts whatever arrives.

Multivariate flags and segments

A multivariate flag has several variants, such as three versions of a button, each with a share of the audience. Segment overrides interact with this in a simple way. A segment override can choose its own enabled state and value, and it takes priority over the environment’s default split for people in that segment. Members of a staff segment might always see variant B so designers can inspect it, while the public sees the default percentage split between variants A, B and C.

Cautions

Segment values multiply the number of situations you must test. A flag with four segment values has at least five answers, including the default, and each must be right. Keep value formats strict, such as a plain number or a short fixed word, and have your code validate what it receives, falling back to a safe default when a value is missing or unexpected. A mistyped value in a dashboard should never be able to break a page.

The same segment tools serve three quite different jobs. Knowing which job you are doing tells you how to build the rules.

Job one: gradual rollouts

A rollout widens an audience over time until everyone has a feature. The audience should grow, never flicker, and be easy to reverse. Segments built around a percentage split fit this job, with staff and beta groups above them. Success is judged by technical health: errors, speed and support messages. The segment rules should be simple, because you will be editing them often while watching the numbers, and a complicated rule makes every edit risky.

Job two: experiments

An experiment compares groups to learn which version of something works better. Here fairness matters more than speed. People must be assigned to groups in a way that is random with respect to anything that might affect the result, and they must stay in their group for the whole test. A percentage split on a stable identifier gives exactly this. Avoid building experiment groups from traits such as “most active customers”, because the groups would differ before the experiment starts, and any difference in results might come from that, not from your change. Do not edit the split while the experiment runs.

Job three: kill switches and exclusions

A kill switch is a flag that lets you turn off a risky or costly behaviour quickly. Segments help by letting you turn it off for only part of the audience, for example a single country where a partner service is failing, instead of for everyone. The rules for a kill-switch segment should be as plain as possible, so that anyone on call can read and apply them without hesitation in the middle of an incident.

Keeping the three jobs apart

A common source of confusion is using one segment for two jobs. A segment created for an experiment is later reused as a rollout audience, and then someone edits its percentage mid-test. Give each job its own segment, named for its purpose. When the job ends, retire the segment with it. This small discipline prevents accidental damage to results and keeps every audience’s history clear.

Short, direct answers to the questions people ask most often about segment rules.

Segments turn “who should see this?” into a precise, reusable, testable answer. A few clear ideas carry nearly all of the value.