Targeting rules

Overview

This topic explains how to use flag targeting rules to serve flag variations to different contexts based on their attributes.

About targeting rules

Targeting rules are the mechanism for expressing precedence and conditions across multiple context kinds. Individual targeting does not support combined logic across context kinds.

Targeting rules, including the default rule, are all listed on a feature flag’s Targeting tab. You can also use the quick add buttons at the top of the Targeting tab to start different kinds of rollouts or a new experiment.

Each targeting rule includes a description, one or more conditions, and a rollout.

Each condition has three parts:

• Context kind and attribute information, which defines the scope of the condition’s impact.
  • For segment rules, this is always “context,” because segment rules check whether a context is part of a segment.
  • For mobile rules, this is always the application or device context kind, and then an attribute that you select.
  • For custom rules, this is the context kind and attribute that you select, such as “user” and “email address.” To learn more, read Attributes.
• An operator, which sets differentiating characteristics of the attribute, such as limiting the condition to emails that end with certain extensions. If a condition specifies multiple values for the operator to track, the operator iterates over the array. To learn more, read Operators.
• A value, which identifies the attribute by a value you specify, such as .edu or v1. For segment rules, these are the segments that you select.

Segment conditions use OR logic. If you select more than one segment in a “Context is in Segments” condition, the condition matches if the context is a member of any one of the selected segments.

Targeting rules are evaluated using the same evaluation model described in Feature flag hierarchy.

Rollouts

The rollout describes what variation of the flag to serve when the end user matches the targeting rule. You can set this to any of the variations of the flag, or to a percentage rollout. If you want to roll out the selected variation gradually, you can add a progressive rollout or guarded rollout to the targeting rule. To learn more, read Releasing features with LaunchDarkly.

Here is an image of a targeting rule:

By default, all the targeting rules on the flag’s Targeting tab are expanded, so that you can view their names and a summary of their conditions. To view only the names of the targeting rules, click the collapse icon from the top of the page.

Attributes

LaunchDarkly allows you to create your own attributes. For instance, you might want to target contexts based on plan, group, role, or location.

Here is an example of a context with custom attribute values, though each SDK sends context data to LaunchDarkly in a slightly different format:

1
{
2
  "kind": "user",
3
  "name": "Sandy",
4
  "email": "sandy@example.com",
5
  "gymMember": true
6
}

Using attributes, you could show some features to customers on your regular plan, and additional features to customers on your premium plan. Or you could roll out a new feature to 30% of end users at a particular location, rather than 30% of all end users. To learn more, read Context attributes.

In each targeting rule, you can choose an attribute specific to your chosen context kind using the “Attribute” menu.

If an attribute is an object, then in your targeting you can use / as a delimiter to refer to specific object fields. For example, if you have an “address” attribute that includes “city,” “state,” and several other fields, then you can use /address/city in your targeting.

From here, you can also select whether to include or exclude all contexts of a particular context kind based on whether they are part of a segment. To learn more, read Segments.

Operators

LaunchDarkly supports the following operators:

Semantic versions follow the format MAJOR.MINOR.PATCH, such as 1.2.3. The PATCH number is optional, so 2.0 and 2.0.1 are both valid. For some operators, LaunchDarkly stores comparisons internally as the inverse. For example, ”≥” is stored as “not <,” and ”≤” is stored as “not >.” To learn more, read Semantic versions.

Regular expression compatibility across SDKs

LaunchDarkly supports regular expressions for the matches regex and does not match regex operators. Because regular expression syntax varies between programming languages, regex behavior can differ depending on where your flag is evaluated.

• Server-side SDKs: Regular expressions are evaluated using the regex engine of the SDK language. For example, the Java SDK uses java.util.regex, and the Go SDK uses Go’s regexp package.
• Client-side SDKs: Regular expressions are evaluated by LaunchDarkly’s backend:
  • If the expression conforms to Perl syntax, LaunchDarkly evaluates it with a Rust-based regex engine.
  • If it does not conform to Perl syntax, LaunchDarkly evaluates it with a Go-based regex engine.

Neither the Rust nor Go regex engines support lookahead or lookbehind assertions. These patterns do not work in LaunchDarkly targeting rules.

To ensure consistent results across SDKs and environments, use only syntax features that are supported by all relevant regex engines. For most use cases, the safest option is to use simple expressions such as ., *, [ ], ^, and $. If your implementation relies on more advanced syntax, test your expressions with the specific SDKs and environments you use before deploying them.

Types of targeting

LaunchDarkly supports the following targeting types:

• Targeting segments
• Individual targeting
• Bulk targeting
• Mobile targeting
• Custom rules

Each flag can include up to 5,000 targeting rules and 50,000 values across all rules.

You can also set flag prerequisites to make flags depend on other flags being enabled to take effect. To learn more, read Flag prerequisites.