A/B Test events
UpdatedHow it works
A/B tests help you determine how variations in your websites, apps, and services perform with your audience. We use this specification to support default actions—any we have now and ones we might add in the future. So, if you send A/B tests that conform to this specification, you’ll be ready to trigger downstream actions in destinations that rely on an A/B testing framework.
We refer to A/B tests as experiments. Each experiment can have multiple variants that you present to random samples of your audience. So, each track
call that you send to Customer.io should contain the experiment_id
and variant_id
properties, so you can track the efficacy of variants in your tests. Each event can also contain an experiment_name
and variant_name
properties that help you understand your events at a glance—without having to look up what each ID represents.
Experiment Viewed
There’s only one event in our specification, called Experiment Viewed
. You’ll send this event whenever you present someone with a variant in an A/B test. It helps you track which experiments you’re running and which variants a person sees.
You can track the total number of variants within an experiment to see how many people have been involved in the experiment. A typical event contains the following properties:
- experiment_id stringThe ID of the A/B test.
- experiment_name stringThe A/B test’s human-readable name.
- variation_id stringThe ID of the individual test variant.
- variation_name stringThe A/B test variant’s human-readable name.
Example payload
An example payload for an Experiment Viewed
event might look like this:
{
"type": "track",
"userId": "97980cfea0067",
"event": "Experiment Viewed",
"properties": {
"experiment_id": "12345",
"experiment_name": "Homepage Hero",
"variant_id": "67890",
"variant_name": "Hero B"
}
}