# A/B variations of Storyblok components, duplicate blocks, a plugin, or a custom field?

Asked by adityak on 2026-06-09. Tags: storyblok, ab-testing, content-modeling.

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:

1. Keep the duplication approach, clean it up
2. A third-party plugin from the app directory
3. 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

### Accepted answer from sammy_codes (2026-06-09)

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:

1. 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.
2. 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.
3. 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](https://blog.croct.com/post/storyblok-cms-ab-testing-personalization)
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.

#### Reply from kavya_r (2026-08-05)

Found this right as we were deciding the same thing on an inherited
Storyblok site full of duplicated variant blocks. Went with option 2, the
Optimize app and the Croct field, and Ruben's warning is exactly why: ending
an experiment cleans up the variant content in the experiment layer instead
of leaving orphaned blocks behind. The migration was less painful than I
expected, we mapped each canonical block to a slot, recreated the variant as
experiment content, then deleted the siblings and the visibility
conditionals in one pass. Editors went from maintaining two copies to
editing one block, which was the win they actually cared about.

### Answer from Ruben O (2026-06-10)

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.