Why doesn't my segment match any users?
Last updated:
The rule probably cannot resolve the segment at all, which fails closed and matches nobody. A client SDK never given segment data behaves the same way. Once that is ruled out, look at condition logic. Segments carry one flat condition list with a single AND or OR, so a segment built to catch two different user groups with AND matches nobody by construction.
Both serve the fallthrough, so from outside you cannot tell a segment whose conditions genuinely exclude everyone from a segment the evaluator never found at all. Worth separating the two before you start editing conditions, because only one of them is a condition problem.
When a rule references a segment, the evaluator resolves that segment first. If it cannot, the rule fails closed and reports no match. It deliberately does not fall back to the rule’s own condition list. An empty condition list matches everyone, and quietly switching a feature on for your entire user base is the one outcome nobody wants out of a targeting bug.
The resolution case
Browsers are where this usually turns up.
// Server SDK: segments arrive with the flag payload, rule resolves normallyclient.boolVariation('beta-dashboard', { userId: 'u_1', plan: 'pro' }, false);
// Client SDK with no segment data: the rule cannot resolve, so no matchclient.boolVariation('beta-dashboard', { userId: 'u_1', plan: 'pro' }, false); // -> falseIf a flag works from your backend and not from the browser while both send the same attributes, check whether the segment is reaching the client at all before touching any conditions.
The condition case
If the segment does resolve, look at how it combines conditions. A segment carries one flat list plus a single operator for the whole list, unlike a targeting rule, which supports several condition groups combined with AND.
Write a segment meant to capture “enterprise customers or anyone on the beta program” using AND and you have asked for people who are both, which is usually nobody at all. Switch the operator to OR, or split it into two segments.
Attribute types are the other frequent culprit. A condition comparing plan to the string "pro" will not match a context sending a number, and a condition on signup_date needs the format the operator expects.
Checking it quickly
Evaluate one user you are certain belongs in the segment and read the reason back. A RuleMatch naming a different rule tells you something above it captured the user first, since rules run in priority order and the first match wins. A fallthrough reason tells you the segment rule genuinely did not match, which narrows it to the two causes above.
How to use segments covers how the condition list is put together. If the reason string points you at rule ordering instead, Targeting and segments has the precedence rules.
Related questions
Why did my targeting rule not match?
Rules run top to bottom and the first match wins, so an earlier rule can shadow the one you are testing. The other usual cause is a missing context attribute.
Why doesn't my semver targeting rule match?
Semver operators parse the version string before comparing. A build number, a date, or anything else that is not a version matches nothing at all.
Why is my feature flag returning the default value?
Six reasons a Featureflip flag falls back to the default you passed, ordered by how often each one is the real cause, with the check for each.
Still stuck?
The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.