Getting the Group

Checking an experiment's group name in code is an anti-pattern on Statsig. Checking the group name isn't necessary, and it limits your ability to quickly test different variants. Read experiment parameters directly instead, so your code stays decoupled from the group names you configure in the console.

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, Statsig dynamically evaluates your variable. 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's 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's fragile. If the group name in code doesn't match the name in the Statsig console, Statsig doesn't return the correct experience.
2. It's static. Adding another experiment group, such as an "Unsorted long list", requires a code change.

So instead, this is what the code looks 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 now have 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 Statsig assigns a user to. The following table defines the Rules you see and what they mean.