How to use Hygraph CMS for AB testing and website personalization

Hygraph has native personalization. It does not have native A/B testing. Those two facts get collapsed in most comparison articles, and the difference decides what you have to build.

Hygraph's Variants feature lets you enable variant support per field, define Segments, and attach variant entries to those segments. Your query filters variants by segment slug, and you merge the result over the base entry. It is a clean design, and for content personalization it does the job.

What it does not do is decide which segment a visitor belongs to, split traffic between variations, or tell you whether the personalized version performed better. This post covers where that line sits and what to do about it.

If you want the implementation detail rather than the tool comparison, we walk through setting up Variants step by step, with the query, the overlay, and the editorial trade-offs, in this post.

What Hygraph Variants actually does

Credit where it is due: this is a better-designed feature than the field-level variant systems on some competing CMSs.

• Variant support is opt-in per field

  You enable it only on the fields that should vary, so a schema with twenty fields and four variable ones stays mostly untouched.

• Segments are first-class

  A segment is a named entry with a slug, and variants link to one or more segments. You are not encoding audience names into field values.

• The variant is an entry overlay, not a per-field lookup

  One query parameter filters the whole entry's variants, and you merge the result over the base. Compare that to systems where every personalized field adds its own experiment and variant parameters, and Hygraph's version is meaningfully cleaner.

Three limits belong in any evaluation. Variants is an enterprise feature requiring a sales conversation. There is a maximum of 30 variants per entry, and segments and variants both count toward the content entry limits of your billing plan, so personalization consumes the same quota as your content. Custom and unique fields are not supported, and segment fields cannot be localized.

There is also an editorial cost that only appears at scale: variants do not stay in sync with the main entry. Updating a variant-enabled field on the main entry does not update it in the variants, and each variant publishes separately, after the main entry. Six segments mean seven edits for any shared change and seven publish actions.

For the full walkthrough, including the schema setup, the GraphQL query, the overlay function, and the publishing rules, see this article.

Where the line sits

Hygraph's own documentation is explicit about the boundary. Step one of their guide is: identify the user's role using your own frontend logic. The CMS stores and serves the variants. Everything before that is yours.

Three things sit on your side of the line.

1. Deciding who is in which segment

The documented example reads the segment from a URL parameter or a cookie. That is fine for the tutorial's case, where a campaign link carries ?segment=shops. It is not a segmentation engine. Anything beyond a URL parameter or a preference the visitor picked themselves, such as behavior in the current session, firmographics, purchase history, returning versus new, is logic you write and maintain, plus wherever that data lives.

Hygraph notes this does not require a CDP, and for campaign and self-selected segments that is true. Once your segments depend on behavioral data, you need somewhere to keep it.

Two details worth handling carefully. Set the cookie server-side: Safari's ITP caps client-set cookies at seven days, so a visitor returning after that gets re-segmented. And treat a segment in a URL parameter as user-controllable, since it is shareable, editable, and indexable.

2. Multi-segment precedence

This one is easy to miss and shows up in production. Hygraph's own example repository is upfront about it:

If a visitor matches only one segment, this is correct. If they match two segments, like an enterprise account and a returning customer, they get whichever variant the API returned first. There is no priority order, and nothing in the query expresses one.

You need an explicit precedence rule as soon as you have overlapping segments, and it has to live in your code because the CMS has no concept of it.

3. AB testing, entirely

Variants are a personalization feature. There is no experiment object, no traffic allocation, no random assignment, no exposure tracking, and no statistical analysis.

That matters more than it sounds, because personalization without measurement is unfalsifiable. You can ship a variant for coffee shop owners and never learn whether it converts better than the base entry. To find out, you need:

• Deterministic assignment: Hash a stable visitor ID with an experiment key so the same visitor always gets the same variation and a reload does not flip it.
• Exposure tracking: Recording who saw what, sent server-side so ad blockers do not bias the denominator.
• A statistical engine: Deciding whether the difference you observed is real.

None of that is in scope for Variants, and reasonably so. It is a content feature.

Your options

Hygraph Variants alone is the best choice for a fixed set of known segments driven by campaign parameters or explicit user choice, where you are personalizing rather than testing. Cheapest option, and genuinely sufficient for a real class of use case.

Now, if you want to run AB tests using Variants, you'll need to use a feature flag platform like GrowthBook, Statsig, or LaunchDarkly to handle assignment and statistics. You wire the flag's variation to a segment slug and pass it into the query. Solid for engineering-led teams, and every new variation is still a code change and a deploy.

The official Optimizely app on Hygraph's marketplace includes an Optimizely integration connecting structured GraphQL content delivery to Optimizely's targeting and decisioning. This is the supported enterprise path if Optimizely is already in your stack, with the cost and onboarding that implies.

The fourth option is using a content layer alongside Hygraph to resolve audiences and variants per request outside the CMS, leaving your schema, your Variants setup, and your queries as they are.

Everything for conversion optimization

From personalization and experimentation to content and data management, we have all you need to deliver better user experiences.

Explore all features

Where Croct fits

Croct resolves audiences and content per request outside Hygraph, with your Hygraph content as the fallback.

export default async function Article({id}) {  // No segment parameter, no variant filtering, no merge step  const {article} = await hygraph.request(ARTICLE_QUERY, {id});
  const {content} = await fetchContent('article-hero', {    fallback: article,  });
  return <ArticleHero {...content} />;}

Audiences are evaluated, not supplied. Instead of your code deciding the segment and passing it in, audience rules are evaluated server-side against a live visitor profile. Profiles are built in, so behavioral targeting works without a separate CDP, and firmographic data from 6sense, Demandbase, or ZoomInfo lands on the same profile for B2B targeting.

When a visitor matches several audiences, priority is set in the interface rather than resolved by array order, so you don't need to worry about precedence.

Experiments come with the same mechanism. The slot that personalizes can also AB test, with assignment, cross-device stickiness, exposure tracking, and Bayesian analysis on all your data included. As a result, your schema and your Variants setup are untouched. Croct reads nothing from Hygraph and writes nothing back.

Where this is not the right fit

If Variants already covers you, use Variants. A fixed set of campaign or self-selected segments, no need to measure lift, and no behavioral targeting means the native feature is sufficient and free of another vendor. Do not add a layer to solve a problem you do not have.

If you are standardized on Optimizely, use the official Hygraph app. A first-party integration beats a third-party layer when the platform is already in your stack.

If you need warehouse-native analysis, GrowthBook and Statsig are built for that.

And if you want to check Croct out before making any decision, create your forever-free account and try it today. You can integrate it in less than an hour.