Skip to main content

Managing Segments

Segments allow you to group your users based on a set of rules, and then control Feature Flags and Remote Config for those groups. You can create a Segment and then override a Feature Flag state or Remote Config value for that segment of users.

Segments for Flags and Config are overridden at the Environment level, meaning that different Environments can define their own Segment overrides.

Segments only come into effect if you are getting the Flags for a particular Identity. If you are just retrieving the flags for an Environment without passing in an Identity, your user will never be applied to a Segment as there is no context to use.

tip

Segments are not sent back to Client-Side SDKs. They are used to override flag values within the dashboard, but they are never sent back to our Client-Side SDKs from the API.

They are sent back to Server Side SDKs running in Local Evaluation mode.

Learn more about our architecture.

Example - Beta Users​

important

Segment definitions can be defined at the Project or Flag level. Project level Segments are defined at the Project level and can be used with any number of Flags within that Project. Flag Specific Segments can only affect the Flag they are defined within.

Let's say that you want all your team to automatically be defined as Beta Users. Right now, all your logged in users are identified with their email address along with some other traits.

You can create a new Segment by going navigating to Segments and clicking the "Create Segment" button, call it Beta Users, and define a single rule:

  • email_address contains @flagsmith.com

Once the Segment has been defined, you can then associate that Segment with a specific Feature Flag. To do this, open the Feature Flag that you want to connect the Segment to and navigate to the Segment Overrides tab. You then have the option of connecting a Segment to the Feature. This then allows you to override the flag value for Users that are within that Segment. If the Identified user is a member of that Segment, the flag will be overridden.

For all the Feature Flags that relate to Beta features, you can associate this Beta Users segment with each Flag, and set the Flag value to true for that Segment. To do this, edit the Feature Flag and select the segment in the 'Segment Overrides' drop down.

At this point, all users who log in with an email address that contains @flagsmith.com will have all Beta features enabled.

Let's say that you then partner with another company who need access to all Beta features. You can then modify the Segment rules:

  • email_address contains @flagsmith.com
  • email_address contains @solidstategroup.com

Now all users who log in with a @solidstategroup.com email address are automatically included in beta features.

Feature-Specific Segments​

You can also create Segments within a Feature. This means that only that Feature can make use of that Segment. Feature Specific Segments are useful when you know you will only need to use that Segment definition once. Go to the Feature, then the Segment Overrides Tab, and click the "Create Feature-Specific Segment" button.

Multi-Variate Values​

If you are using Multi-Variate Flag Values, you can also override the individual value weightings as part of a Segment override.

Rules Operators​

The full set of Flagsmith rule operators are as follows:

NameCondition
Exactly Matches (==)Trait value is equal to segment value.
Does Not Match (!=)Trait value is not equal to segment value.
% SplitIdentity is in the percentage bucket. See Percentage Split Operator.
>Trait value is greater than segment value.
>=Trait value is greater than or equal to segment value.
<Trait value is less than segment value.
<=Trait value is less than or equal to segment value.
InTrait value is equal to one or more elements in a comma delimited list. See The In operator.
ContainsSegment value is a substring of trait value.
Does Not ContainSegment value is not a substring of the trait value.
Matches RegexSegment value, set to a valid Regex expression, is applied to trait value and matches it.
Is SetTrait value is set for given identity and trait key.
Is Not SetTrait value is not set for given identity and trait key.
SemVer >Trait value is set to a newer SemVer-formatted version than segment value. See SemVer-aware operators.
SemVer >=Trait value is set a newer SemVer-formatted version than segment value or equal to it. See SemVer-aware operators.
SemVer <Trait value is set to an older SemVer-formatted version than segment value. See SemVer-aware operators.
SemVer <=Trait value is set to an older SemVer-formatted version than segment value or equal to it. See SemVer-aware operators.

Operator Details​

The In operator lets you match a Trait value against a comma-separated list of values. For example, the Segment rule value might read 21,682,8345. This would then match against a Trait value of 682 but not against a Trait value of 683.

The In operator can be useful when building Segments to match against tenancies within your application. Let's say you wanted a Segment to evaluate as true for 5 different customer tenancies. Create a Segment rule where the In operator matches all of those 5 customer tenancy ID's and no others. You can then create a Trait value for the Identity that contains the tenancy ID of that user.

The In operator is case sensitive when evaluating alphabetical characters.

important

Earlier SDK versions will not work in local evaluation mode if your environment has segments with the In operator defined.

To keep local evaluation from breaking, please ensure you have your SDK versions updated before you add such segments to your environment.

These minimum SDK versions support segments with the In operator in local evaluation mode:

  • Python SDK: 3.3.0+
  • Java SDK: 7.1.0+
  • .NET SDK: 5.0.0+
  • NodeJS SDK: 2.5.0+
  • Ruby SDK: 3.2.0+
  • PHP SDK: 4.1.0+
  • Go SDK: 3.1.0+
  • Rust SDK: 1.3.0+
  • Elixir SDK: 2.0.0+

Rule Typing​

When you store Trait values against an Identity, they are stored in our API with an associated type:

  • String
  • Boolean
  • Integer

When you define a Segment rule, the value is stored as a String. When the Segment engine runs, the rule value will be coerced into the type of the Trait value. Here are some examples.

You store a Trait, here with an example in Javascript:

flagsmith.identify('flagsmith_sample_user');
flagsmith.setTrait('accepted_cookies', true);

So here you are storing a native boolean value against the Identity. You can then define a Segment rule, e.g. accepted_cookies=true. Because the Identity trait named accepted_cookies is a boolean, the Segment engine will coerce the string value from accepted_cookies=true into a boolean, and things will work as expected.

If you were to then change the trait value to a String at a later point the Segment engine will continue to work, because the Identity's Trait value has been stored as a String

flagsmith.setTrait('accepted_cookies', 'true');

For evaluating booleans, we evaluate the following 'truthy' String values as true:

  • True
  • true
  • 1

Segment Rule Ordering​

Flagsmith evaluates the conditions of a Segment in the order they are defined. This can affect how things are processed and should be considered when creating your Segment rules.

For example, let’s say I have this segment:

  1. Percentage Split = 10%
  2. isSubscriber = true

This Segment would randomly select 10% of all Identities first and then filter the subscribers. You could also define the Segment rules the other way around:

  1. isSubscriber = true
  2. Percentage Split = 10%

This definition makes the isSubscriber check first, and the Split condition is second, operating purely on the pool of subscribed users.

Feature Flag and Remote Config Precedence​

Feature Flag states and Remote Config values can be defined in 3 different places:

  1. The default Flag/Config value itself
  2. The Segment associated with the Flag/Config
  3. Overridden at an Identity level

For example, a Feature Flag Show Paypal Checkout could be set to false on the Flag itself, true in the Beta Users segment, and then overridden as false for a specific Identity.

In order to deal with this situation, there is an order of priority:

  1. If the Identity has an override value, this is returned ahead of Segments and Flags/Config
  2. If there's no Identity override, the Segment is checked and returned if valid
  3. If no Identity or Segment overrides the value, the default Flag/Config value is used

More simply, the order of precedence is:

  1. Identity
  2. Segment
  3. Flag