Getting the Group

A common misconception when working with experiments on Statsig is trying to check the experiment group in code. Checking the experiment group in code is an anti-pattern. It isn't necessary with Statsig, and it limits your ability to quickly test different variants.

Experiment groups are useful for understanding what a set of parameters represents in the Statsig console. Comparing "Sorted Long List" vs "Default Search Results" is easier to discuss than understanding what the sorted = true, length = 10 parameters represent.

In code, checking parameters directly is more powerful and simpler to reason about. Rather than hard-coding a particular value, your variable is dynamically evaluated by Statsig. Parameters are the building blocks of your experiments in code, rather than group names.

Example: group names vs parameters

Hard-coding experiment group names is fragile and limiting. Here is why.

In code, a function using 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;
    }
}

There are two problems with this code:

1. It is fragile. If the group name in code doesn't match the name in the Statsig console, the correct experience isn't returned.
2. It is static. Adding another experiment group, such as an "Unsorted long list", requires a code change.

So instead, this is what the code would look like 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;
}

Your code is now completely decoupled from the names of experiment groups in the Statsig console. You are left with a set of dynamic parameters. You can create any experiment groups from these building blocks and the same code works. To test an unsorted list of 5 items against a sorted list of 20 items, configure it in the Statsig console and name the groups however you want.

If you were using group names instead, you would need to add conditions like:

} else if (experiment.groupName === 'Unsorted Short List') {
  return results.slice(5);
} else if (experiment.groupName === 'XL Sorted List') {
  return results.sort().slice(20);
}

Using parameters directly is much simpler and more flexible. It makes your code dynamic and offloads experimentation setup to the Statsig console. The group names you configure to describe each set of parameters make it easy to compare one group against another when analyzing experiment results.

Rules

The diagnostics stream is for debugging your integration and understanding which groups a user is being assigned to. The following table defines the Rules you see and what they mean.