Read Parameters, Not Group Names
Why Statsig experiment code reads parameters rather than group names, how that lets you add variants without a code change, and what each Diagnostics exposure-stream rule means.
Statsig experiments differentiate their groups through parameters, not group names. Every group defines a value for the same parameters, your code reads those values with experiment.get("param", default), and the console blocks Start until the experiment defines at least one parameter. Checking a group name in code instead is an anti-pattern: it's fragile, it forces a code change for every new variant, and it borrows a field that exists for diagnostics. Group names belong in the console, where comparing "Sorted Long List" with "Default Search Results" is easier to discuss than the sorted = true, length = 10 parameters they represent.
Example: group names compared with parameters
A function that checks experiment groups might look like this:
async function getSearchItems(user: StatsigUser, searchTerm: String): String[] {
const results = index.get(searchTerm);
const experiment = statsig.getExperimentSync(user, 'search_results');
// NOTE - these APIs don't actually exist - this is for the sake of an example
if (experiment.groupName === 'Sorted Long List') {
return results.sort().slice(10);
} else if (experiment.groupName === 'Sorted Short List') {
return results.sort().slice(3);
} else {
return results;
}
}
This code has two problems:
- It's fragile. If the group name in code doesn't match the name in the Statsig console, Statsig doesn't return the correct experience.
- It's static. Adding another experiment group, such as an "Unsorted long list", requires a code change.
The same function using experiment parameters directly:
async function getSearchItems(user: StatsigUser, searchTerm: String): String[] {
let results = index.get(searchTerm);
const experiment = statsig.getExperimentSync(user, 'search_results');
results = experiment.get("sorted", false) ? results.sort() : results;
const numItems = experiment.get("length", 0);
return numItems > 0 ? results.slice(numItems) : results;
}
This code doesn't reference any group names. To test an unsorted list of 5 items against a sorted list of 20 items, configure the groups in the Statsig console and name them however you want; the same code handles every combination of sorted and length.
Diagnostics rule meanings
The Diagnostics tab helps you debug your integration and understand which group Statsig assigns a user to. The Rule column of the Exposure Stream and the result of Check Group for a User use the following values.
| Rule | Meaning |
|---|---|
| Not started | You haven't started the experiment, so Statsig hasn't determined the allocation groups yet. |
| Holdout | The user is in a holdout that this experiment references, so they aren't in the experiment. |
| Layer Assignment | Statsig doesn't allocate the user to this experiment because it buckets them into a different part of the layer. |
| Failed targeting | The user doesn't meet the requirements for the targeting gate or inline targeting. |
| Not Allocated | Statsig doesn't allocate the user to this experiment because they don't meet the rollout percentage. |
{group name} ({override type}) | An experiment override forced the user into the given group, for example Test (ID Override). |
{group name} | Statsig bucketed the user into this experiment group. |
| Abandoned | You selected the control group in Make Decision and abandoned this experiment. |
{group name} (Launched) | You selected this group as the launch group in Make Decision, so the user sees the launched experience. |
Was this helpful?
For AI agents: a documentation index is available at /llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.