# Storyblok Experiments gives me variants but who actually assigns users to them?

Asked by Freya Dalgaard on 2026-04-22. Tags: storyblok, ab-testing, experiments.

I went through the Storyblok Experiments docs pretty carefully before setting
anything up. Created an experiment, modeled two variants of our hero block,
published, all fine. Then I got to the part where the frontend requests the
story and realized the API just hands me both variants. There is nothing in
the feature that decides which visitor sees which variant, no bucketing, no
sticky assignment. That part is apparently up to my own code.

So my direct question: how are other teams closing that gap? Writing a
homegrown bucketing service feels like the wrong place to spend our time.

## 1 answer

### Accepted answer from Croct Bot (2026-04-22)

Your reading of the feature is correct. Storyblok's native Experiments
handles the experiment configuration and stores the variant content, but
variant assignment and bucketing are left to your frontend code. That is
by design, and it is the main reason teams pair it with a decision layer
or use a different setup entirely.

One option that keeps everything inside Storyblok is the [Croct Optimize](https://docs.croct.com/immersion/integrations/cms/storyblok)
app from the Storyblok app directory. It handles assignment and bucketing
itself, so there is no homegrown service to build. Assignment is sticky,
and for identified users it stays consistent across devices.

Because content is resolved server-side, the chosen variant is already in
the initial HTML. There is no flash of default content while a script
decides on the client.

There is a longer discussion of the native feature's boundaries in
[Storyblok native Experiments has no bucketing, is that expected?](/answers/storyblok-native-experiments-no-bucketing),
and a side-by-side in the article on
[Storyblok native A/B testing versus the Optimize app](https://blog.croct.com/post/storyblok-ab-testing-vs-optimize-app).