What is an A/B Test?

An A/B test — also called an experiment — is a controlled method of comparing two or more variations of a product experience to determine which one better achieves a desired outcome. Instead of guessing what works, you let real user behaviour tell you.

In GrowthBook, every experiment starts with a hypothesis: a falsifiable statement such as “Changing the call-to-action button colour from grey to green will increase click-through rate.” You then define variations (the original control and one or more challengers), split your traffic between them, collect metric data, and use statistical analysis to make a confident decision.

Feature-flag experiments vs the Experiments UI

GrowthBook gives you two paths to run an experiment:

Feature-flag experiments wire an experiment directly to a feature flag. Your code already calls gb.getFeatureValue('experiment-key', 'control') to read the feature; GrowthBook silently assigns each user to a variation bucket and records the exposure. This approach keeps your experimentation logic decoupled from your UI and is the recommended path for product and engineering teams.

The Experiments UI lets you define an experiment without touching feature flags, useful for visual or content experiments managed through a no-code interface. Under the hood it still uses the same assignment and metrics engine.

Both paths share identical statistical analysis, meaning you can compare results and combine learnings across your whole programme.

The experiment lifecycle

Every GrowthBook experiment moves through five stages:

Hypothesis — State clearly what you believe will happen and why. A good hypothesis names the change, the expected direction, and the metric it will affect.
Variations — Define the control (the current experience) and one or more treatment variations. Keep changes focused: testing too many things at once makes it impossible to know what drove the result.
Assignment — GrowthBook assigns each user to exactly one variation using a deterministic hash of a stable user identifier (e.g. user ID or anonymous device ID). This means a user always sees the same variation across sessions without any server-side storage.
Metrics — Connect your data source and define the goal metric (e.g. conversion rate, revenue per user) and any guardrail metrics (e.g. page load time) you want to monitor for regressions.
Decision — Once you reach statistical significance or your planned sample size, GrowthBook surfaces a winner. You then ship the winning variation to 100 % of users and archive the experiment.

Reading the assigned variation in code

The snippet below shows the minimal pattern: initialise the SDK, then call getFeatureValue with the experiment feature key and a fallback value of 'control'. Branch on the result to deliver the right experience.

import { GrowthBook } from '@growthbook/growthbook';

const gb = new GrowthBook({
  apiHost: 'https://cdn.growthbook.io',
  clientKey: 'sdk-YOUR_KEY',
  // Pass stable attributes so assignment is deterministic
  attributes: {
    id: currentUser.id,
  },
});

await gb.init({ timeout: 2000 });

// Returns the variation assigned to this user, or 'control' as fallback
const variation = gb.getFeatureValue('experiment-key', 'control');

if (variation === 'treatment') {
  // Show the new experience
  renderTreatment();
} else {
  // Show the original control experience
  renderControl();
}