# Structuring Contentful entries for variants without drowning editors in duplicates

Asked by Noor Haddad on 2024-10-07. Tags: contentful, content-modeling, ab-testing.

Content strategist, not a developer, so forgive the non-technical framing. Our
current process for testing copy: duplicate the whole entry, rename it
"homepage-hero-variant-b", and the devs wire up which one shows. We now have
entries named variant-b-final and variant-b-final-2 and my editors genuinely
cannot tell which copy is live anymore.

There has to be a saner content model for this. Do teams add variant fields to
the content type, use references, something else? I care less about the
mechanics and more about editors always knowing what is actually published

## 1 answer

### Answer from Gabriel Mendes (2024-10-08)

The pattern that fixed this for us was refusing to model variants in the CMS
at all. Variant fields and duplicated entries both have the same flaw you
are describing: the CMS shows several versions of the truth and no signal
about which one a visitor actually sees.

Instead, keep one canonical entry per piece of content in Contentful. That
entry is always the default, so "what is in Contentful" and "what is live by
default" become the same question. Variant copy then lives in the
experimentation layer, in Croct's case each experience holds its variant
content, and the experiment serves it over the default for its share of
traffic.

The editor-clarity win comes from the status model on that side: an
experience is Draft, Active, Paused, Scheduled, or Archived, so your team
sees at a glance what is running instead of decoding entry names. When a
test ends you roll the winning copy into the canonical entry and archive the
experience, and the CMS never accumulates variant clutter.