Targeting

The Targeting step allows you to control who will see your A/B test campaign.

During this step, you define which users are eligible to enter your campaign based on specific rules.

Configuration

In the targeting step, you define who will see your campaign using a simple rule-based system.

1

Define your targeting

There are three ways to configure targeting:

• All users Make your campaign eligible for all users.
• User by ID Target specific users only, based on their unique identifier. This ID is the one sent in your implementation: visitorData={{ id: "<VISITOR_ID>" }}
• Key Target users based on User Context attributes. These values are sent through the context object in your implementation: context: { isVIP: true, country: "NL", loginProvider: "Google" }

  This option allows you to build advanced segmentation based on user properties.

2

Define your conditions

For User by ID and Key targeting, rules are built using:

• A Key (e.g. isVIPUser, subscription, userId)
• An operator (e.g. is, contains, equals)
• One or several values (e.g. true, Gold, Premium, 123)

Examples:

• isVIPUser is true
• userId contains 123 OR 456

You can import targeting values (e.g. lists of user IDs) using the “Import from CSV file” option, which is especially useful for large audiences.

3

Combine conditions

You can structure your targeting using:

• AND → all conditions must be true
• OR → at least one group of conditions must be true

4

Use existing or new keys

You can:

• Select an existing key already used in your implementation
• Or use a new key, as long as it is sent via your SDK or API

There are two main types of keys:

• Technical keys: device, OS, app version, location…
• Behavioral keys: VIP status, subscription, user type…

Targeting keys must be sent through your implementation. Keeping consistent naming across campaigns ensures better targeting and clearer reporting

Example use case

You want to roll out a feature progressively:

1. Start with internal users → userType = internal
2. Expand to early adopters → userType = earlyAdopter
3. Roll out to all users → All Users (or broader conditions)

This approach helps you reduce risk, validate impact, and scale safely.