Migrating off Ninetailed after the sunset, what do our audiences and experiences become?
We ran the standalone Ninetailed app on a Contentful site until the March 2026 legacy sunset caught us, so I am now planning the migration properly.
Here is what we currently run:
- 6 audiences (industry, returning visitor, two campaign-based, two behavioral)
- 9 experiences that swap hero and CTA entries per audience
- Variant entries live in Contentful next to the defaults
Before I estimate anything I want to map old concepts to new ones explicitly. In Croct terms, what does a Ninetailed audience become, what does an experience become, and where does variant content live? I have read the sunset thread but it does not go into the concept mapping.
2 answers
Your list maps over quite directly.
Audiences. In Croct, an audience is a CQL condition evaluated in real time on every interaction. Your six audiences become six conditions, for example:
user is returningcampaign's source is "google" and campaign's name matches "spring"One structural difference: audiences are defined inside experiences, as part of the who/where/what flow, rather than as a separate library you attach afterwards.
Experiences. Same concept, same name. An experience says who sees what content in which slot. Your nine experiences become nine Croct experiences targeting the hero and CTA slots.
Variant content. This is the main workflow change. Variant content is authored inside the Croct experience, not as extra entries in Contentful. Your Contentful entries stay as the single default that your app renders, and experiences override that content only for matched audiences. In practice this means you can delete the duplicate variant entries from Contentful once the migration is done, which most teams count as a win for editors.
One dependency worth noting for the behavioral audiences: conditions like user is returning or session's stats' pageviews > 3 work from the SDK's automatic tracking, with no instrumentation needed. Only conditions built on your own custom events or attributes require sending those first.
So the estimate is roughly: map the hero and CTA components to slots in code once, then recreate six conditions and nine experiences in the dashboard.
Having just finished this exact migration off the sunset Ninetailed app, I can confirm the concept mapping above held in practice. Two things I would add from doing it.
First, the behavioral audiences really did need nothing extra: user is returning and pageview-based conditions worked straight off the SDK's automatic tracking, and only our one custom-event audience needed the event sent first. Second, deleting the duplicate variant entries from Contentful afterwards was the step our editors noticed most, since a single default entry is all that remains per slot.
On effort: budget the bulk of it for mapping the hero and CTA components to slots in code once. Recreating the six conditions and nine experiences in the dashboard was the quick part.