---
url: /ab-testing.md
---
# A/B Testing

A/B testing lets you compare two (or more) variants of a template change on live traffic. The platform splits visitors into variants, the template renders differently per variant, and the results are evaluated in Google Analytics 4.

How it works:

1. You define variant codes in `config.json`.
2. On the first pageview, each visitor is randomly assigned one variant. The assignment is stored in the `ab` cookie for 30 days, so a visitor keeps seeing the same variant.
3. The template branches on the assigned variant.
4. Each pageview reports the variant to Google Analytics 4 (as an `experience_impression` event), where you compare conversion rates, revenue, or any other metric between variants.

## Configuration

Define the test in `config.json` (see [Configuration](/config)):

```json
{
    "AB": {
        "variants": ["menu2026-a", "menu2026-b"]
    }
}
```

The variant codes are arbitrary strings (up to 64 characters) — they are what you will see in Google Analytics. Include an experiment identifier in the codes (`menu2026-a`, not just `a`) so that data from successive experiments never mixes together in analytics.

At least two unique variants are required. To end the test, remove the `AB` key from `config.json`.

## Template Conditions

Branch on `this.ABVersion` in any template:

```twig
{% if this.ABVersion == 'menu2026-a' %}
    {% include "menu_variant_a.tpl" %}
{% elseif this.ABVersion == 'menu2026-b' %}
    {% include "menu_variant_b.tpl" %}
{% else %}
    {% include "menu_default.tpl" %}
{% endif %}
```

You **must** always provide a fallback branch (the final `else`) for the case where `this.ABVersion` is `null` or holds a code that is not one of yours. This happens for bots and crawlers (they are never assigned a variant, so they consistently see the fallback), for requests where the test is not active, and right after you remove the test from `config.json`, when visitors may briefly carry a cookie with a code from one of the platform's internal experiments.

## Forcing a Variant

To preview a specific variant, append `?_forceAB=code` to any URL, where `code` is the variant code:

```
https://www.example.com/?_forceAB=menu2026-b
```

This stores the chosen variant in your `ab` cookie, so it persists for your subsequent pageviews.

## Evaluating in Google Analytics 4

If the shop has a Google Analytics 4 measuring code configured, every pageview with an assigned variant automatically sends the event Google defines for [experiment integrations](https://developers.google.com/analytics/devguides/collection/ga4/integration):

```javascript
gtag("event", "experience_impression", {"exp_variant_string": "menu2026-b"});
```

To work with the variant in GA4 reports:

1. **Register the dimension** — in GA4: *Admin → Custom definitions → Create custom dimension*, with scope **Event** and event parameter `exp_variant_string`. Data collected before the registration stays available for audiences but not for Explorations.
2. **Compare variants** — in *Explore*, create segments filtered by the `exp_variant_string` dimension (one per variant) and compare conversions, revenue, or engagement between them. Standard reports support up to four comparisons at once.
3. **Audiences (optional)** — create one audience per variant (condition on `exp_variant_string`) to segment any standard report by test variant.

Use *Admin → DebugView* or the Realtime report to verify the event is coming in right after you deploy the test.

The assigned variant is also recorded outside GA4: it is stored with each order's traffic-source data and in the platform's own visit analytics (every pageview, visit, and conversion carries the variant), so order-level and visit-level analyses are possible on request even for traffic that ad blockers hide from GA4.

## Things to Keep in Mind

* **Sample size** — an A/B test needs enough traffic to be meaningful. Before acting on a result, make sure both variants have enough sessions and that the measured change makes sense — otherwise you may effectively be [measuring an A/A test](https://kadavy.net/blog/posts/aa-testing/).
* **One test at a time** — the platform supports a single active test; run experiments sequentially, not in parallel.
* **Smart product sorting** — while a template A/B test is active, it takes precedence over the platform's internal smart-sort experiment (chytré řazení in A/B mode); that experiment resumes when your test ends.
* **First pageview included** — the variant is assigned and rendered already on the visitor's first pageview, so landing-page changes can be tested too.
* **Bots see the fallback** — crawlers are never assigned a variant, so search engines index the stable fallback branch, not a random variant.