Beta User Targeting

Goal: Roll out a feature exclusively to users in your beta program, leaving everyone else unaffected — without any code changes between groups.

How it works

Create a segment that contains the identifiers of your beta users, then add a SEGMENT rule to your flag that serves true to anyone in that segment. That's all you need — a single rule is sufficient. A STATIC fallback rule is optional; without it, users outside the segment automatically get false.

Step-by-step

1. 1
   Create a segment

   In the dashboard, go to Segments and click New Segment.

   Give it the name Beta Users — the key will auto-generate as beta-users. Click Create.

2. 2
   Add users to the segment

   Open the beta-users segment and add user identifiers. Membership is determined by exact string match against the userIdentifier field your application sends at evaluation time.

   Copy

   10912394
   user-beta-001
   [email protected]

   Add as many identifiers as needed, then save.

3. 3
   Create a feature flag

   Go to Flags and create a new flag. Enter a name such as New Dashboard — the key will generate as new-dashboard.

   Select the environment where you want the beta to run (e.g. Production), then confirm creation.

4. 4
   Add a SEGMENT rule for beta users

   On the flag's detail page, open the Rules tab for your target environment.

   Click Add Rule → select Segment.

   Configure it:

   • Segment: beta-users
   • Operator: IS_IN
   • Serve value: true
   • Priority: 0 (evaluated first)

   Click Save.

5. 5
   Add a STATIC fallback rule (optional)

   This step is optional. Users outside the segment already get false automatically — you do not need a STATIC rule for that to happen.

   If you want the fallback to be explicit and visible in your rule list, click Add Rule → select Static.

   Configure it:

   • Serve value: false
   • Priority: 1 (evaluated after the segment rule)

   Your rule list should now look like:

   Copy

   0. Segment: IS_IN beta-users → true
   1. Static: always → false   ← optional, makes fallback explicit

   Click Save.

6. 6
   Enable the flag

   Toggle the environment switch to Enabled.

   Rules only apply when the flag is enabled. If the flag is disabled, all evaluations return false with error.type = "FLAG_DISABLED".

7. 7
   Verify with curl

   Test with a beta user — should get true:

   Copy

   curl --location 'https://api.releaseanchor.com/v1/evaluate' \
     --header 'Content-Type: application/json' \
     --header 'Authorization: ApiKey <YOUR_API_KEY>' \
     -d '{"flagKey": "new-dashboard", "userIdentifier": "10912394"}'

   Copy

   {
     "value": true,
     "matchedRuleType": "SEGMENT",
     "error": null
   }

   Test with a non-beta user — should get false:

   Copy

   curl --location 'https://api.releaseanchor.com/v1/evaluate' \
     --header 'Content-Type: application/json' \
     --header 'Authorization: ApiKey <YOUR_API_KEY>' \
     -d '{"flagKey": "new-dashboard", "userIdentifier": "99999999"}'

   Copy

   {
     "value": false,
     "matchedRuleType": null,
     "error": null
   }

   If you added the optional STATIC fallback rule in the previous step, matchedRuleType will be STATIC instead.

Adding and removing beta users

To add a user to the beta, open the beta-users segment and add their userIdentifier. The change takes effect on the next evaluation — no deployment required.

To remove a user from the beta, delete their identifier from the segment. Their next evaluation no longer matches any rule and returns false — whether or not you have a STATIC fallback rule.

Using IS_NOT_IN for a denylist

The SEGMENT rule also supports IS_NOT_IN as the operator. Users not in the segment match the rule. Use this to build a denylist: block a specific set of users while letting everyone else through.

0. Segment: IS_NOT_IN blocked-users → true
1. Static: always → false

Combining with a percentage rollout

A common pattern: give beta users immediate access, then roll out to a percentage of everyone else.

0. Segment: IS_IN beta-users → true
1. Percentage: 20% rollout → true
2. Static: always → false

Rules are evaluated in priority order. A beta user matches rule 0 immediately — rules 1 and 2 are never checked for them.