# Duplicating Storyblok folders per test variant is drowning our editors, better pattern?

Asked by cormac_d on 2024-09-17. Tags: storyblok, workflow, ab-testing, content-model.

so here is the mess we made for ourselves. Every time we run an A/B test we
duplicate the whole story folder, rename it variant-b, and point the test at
the copy. Sounded harmless when it was one test on one page. We now have a
three variant test running on two pages, which means six near-identical
stories, and last week an editor fixed a typo in variant A of one page and
nobody fixed it in the other five. They are drifting apart and my editors
are starting to hate me.

How are other teams modeling variants in Storyblok without this duplication
sprawl? There has to be a saner pattern.

## 2 answers

### Answer from Annika Berg (2024-09-17)

We got out of exactly this hole by moving the variants out of the story
tree entirely. There is a Croct field plugin for Storyblok that adds a
field to your existing blocks and connects each block to a matching Croct
slot. The Storyblok content stays where it is and acts as the default
fallback, and the variants live in Croct experiences instead of
duplicated stories.

Practical effect: editors keep one story per page. A typo fix happens
once, in the real story. The variant content is managed per experiment,
so when a test ends there is nothing to clean up in the folder tree.

One thing to plan for before you commit: rich text, table, and reference
fields are not currently supported by the field mapping. Our hero and
banner blocks were all plain fields so it was a non-issue for us, but if
your tested blocks lean heavily on rich text you may need to restructure
them a bit first.

#### Reply from cormac_d (2024-09-18)

One story per page again sounds like a dream. The rich text caveat is
good to know, our heroes are mostly plain fields too.

### Answer from Petr Havel (2024-09-19)

Before you adopt any tool, do the cheap fix first: stop duplicating
folders and duplicate only the block being tested, inside the same story.
That alone cuts the sprawl massively because the shared 90 percent of the
page stays single-sourced.

It still leaves you with variant blocks living in the story and some
convention about which one is live, so it is a stopgap rather than a
solution. The block-to-slot mapping Annika describes is the cleaner end
state since the story stops carrying variant content at all.