Skip to main content
You can’t create a feature test yet. Until you can, getFeature returns null for every key, so code written from this page renders Control.
A feature test splits visitors into test groups and leaves the change to your code. Use it to test anything you render yourself: a hero section, a layout, a product page block. Each test group can carry variables, so a test can change copy or settings without a deploy.

​
How it works

  1. You create a feature test in ABConvert, with a feature key, its test groups, and the pages your change is on.
  2. Your code reads the visitor’s test group by that key and renders that version.
  3. ABConvert counts a visitor in the test the first time they open one of those pages.

​
Feature key

A feature key names the feature your code tests, such as home-hero. Your code reads the test by its key, not by its ID or name, so the code is written once and works for every test you run on that feature. The key and the test name are separate. You can rename a test at any time. The key locks when the test launches, because your code depends on it. Until then you can change it. One running test per key. When that test ends, the next test can use the same key, and your code keeps working. A visitor who is in no test with that key gets null.

​
Render a version per test group

Read the feature on the server, with the client your stack guide creates from the request, so the first HTML already shows the right version. Pass the result to your component as you pass any other data.
Server
Component
getFeature returns the same Assignment object as getAssignment. testGroup.index is 0 for Control, 1 for Variant A, and so on.

​
Variables

A test group can carry variables: values you set in the ABConvert admin and read in your code. Use them when the versions differ by a value, such as a headline, a layout name, or a threshold, so the merchant can change the value without a deploy.
Server
Three rules apply:
  • A variable is a string, a number, or a boolean.
  • variables is empty for a visitor who is not in the test, so give every variable a fallback that is your current value.
  • Give Control the same variables with the current values, or leave it empty and rely on the fallbacks.
Variables do not replace code for a new layout or component. They carry the values that version needs.

​
Set the pages the test runs on

Set page targeting on the test to the pages that show your change. A visitor enters the test on their first visit to one of those pages, not on their first visit to your store. This keeps your results clean. A home page test that counted every visitor would include visitors who never saw the home page.

​
Common mistakes

  • Rendering the change on a page the test does not target. Visitors see it without being counted. The fix: keep the test’s page targeting and your code in step.
  • Treating a missing feature as an error. getFeature returns null for a visitor who is not in the test. The fix: render the current version.
  • Using testGroup.name to pick the version. The name is a display label that can change while the test runs. The fix: use testGroup.index.
  • Reading a feature test by its test ID. getAssignment('49603') works, but the next test on the same feature has a new ID and needs a deploy. The fix: use getFeature with the feature key.
  • Reading a variable with no fallback. A visitor outside the test gets undefined. The fix: fall back to your current value, as the example does.
  • Caching the page for every visitor. A full-page cache then serves one version to everyone. The fix: render the page for each visitor. On Hydrogen, see Hydrogen full-page cache.