For AI agents: a documentation index is available at /llms.txt. Append .md to any page URL for markdown, or send Accept: text/markdown.
Getting the Group
Learn why using experiment parameters is better than checking group names in code.
Checking an experiment's group name in code is an anti-pattern on Statsig. Read experiment parameters directly with experiment.get("param", default) instead, so your code stays decoupled from the group names you configure in the console and you can add or change variants without a code change. Reserve group names for reading results 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 stream is for debugging your integration and understanding which group Statsig assigns a user to. The following table defines the rules you see in the stream and what they mean.
| 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. |
| Targeting Gate/Inline 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 name} | An experiment override forced the user into the given group. |
{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?