Experiments

ContentBind does not decide who sees what

Your experimentation tool owns the flag, the bucketing and the results. ContentBind owns the content each bucket sees. That split is deliberate: teams already have a tool for this and do not want a second source of truth for what is running.

Supported flag providers: LaunchDarkly, Statsig, GrowthBook, Split, Optimizely, Eppo, and a built-in bucketer for teams with no external tool.

Starting one

In the editor, open Experiments → Start an experiment. It asks for two things: the flag key, exactly as it exists in your tool, and the list of variants. The first variant is the default, which is what anyone unassigned, or assigned to a variant this page has never heard of, falls back to.

There is no hypothesis field and no sample-size calculator. Those live in the tool that owns the flag.

Authoring per variant

With an experiment running, the topbar gets a variant switcher. Switch to variant_b, edit the headline, switch back: the control is unchanged. Any input can differ per variant, and only the inputs you actually change are stored, so a variant is a diff rather than a copy of the page.

Blocks can also be shown only for a variant, which is how you test a section existing at all.

Serving

Pass the visitor's assigned variants when you fetch:

const entry = await fetchOneEntry({
  model: 'page',
  publicKey: KEY,
  url,
  variants: { hero_headline_test: assignedVariant },
})

Delivery resolves the content server-side and caches per combination, so a visitor gets fully-formed HTML with no flash of the control.

Ending one

Ending an experiment promotes one variant's content into the page proper and removes the rest. The promotion is a normal edit, so it lands on the version history and can be undone.