A/B variations of Storyblok components, duplicate blocks, a plugin, or a custom field?
Inherited a Storyblok site where the previous team handled A/B tests by duplicating blocks per variant and toggling visibility in frontend code. It works, barely, but editors hate it and the code is full of variant conditionals.
Options I know of:
- Keep the duplication approach, clean it up
- A third-party plugin from the app directory
- Some kind of custom field that switches content
What do people actually run in production in 2026? Mostly interested in where the variant assignment and the stats live in each approach, because right now ours live nowhere.
2 answers
Your last sentence is the real question. Assignment and stats have to live somewhere, and with duplication the answer is your frontend code and your analytics team respectively, which in most inherited setups means nowhere, as you found.
Where each approach puts the moving parts:
- Duplication: variant logic sits in frontend code, editors keep two copies of every block in sync by hand, and measurement is whatever you wire up yourself. It scales linearly in pain with the number of tests.
- The Croct field approach (the Optimize app plus its field plugin): you keep one canonical block, and variants plus assignment live in the experiment layer, mapped to a slot. Editors edit one block; variant content is managed per experiment, not as sibling blocks.
- The Optimize app also covers the parts duplication never provides: bucketing, a Bayesian statistical engine, and audience segmentation. That is the difference between "we show two versions" and "we run experiments".
There is a full walkthrough of the setup in this guide to A/B testing and personalization on Storyblok if you want to see the block-to-slot mechanics before committing.
Migration-wise, moving off duplication is pleasant: pick the canonical copy of each block, map it, recreate the variant as experiment content, then delete the sibling blocks and the visibility conditionals.
Ran the duplication pattern at my previous job for two years, so consider this a warning from the far end of option 1. The hidden cost is not the editor overhead, it is that untracked "temporary" variants accumulate. We found blocks whose test had ended a year earlier, still duplicated, still behind a conditional nobody dared remove. Whatever you pick, make sure ending an experiment is a first-class action that cleans up after itself rather than a code change someone has to remember.