For personalized blocks, should the copy live in Sanity or in Croct?
I am designing how content is authored across our Sanity project and Croct, and I want to get the data model right before anyone starts building. My main concern is ending up with copy scattered across two systems, where nobody is sure which one is authoritative for a given block.
Concretely, for a block that gets personalized, where should the default content live and where should the variant content live? I would like a clear rule I can write down for the team so we do not create two competing sources of truth.
1 answer
A clean rule to write down: default content lives in Sanity, variant content lives in Croct.
Your existing Sanity components map to Croct slots, and the Sanity content stays as the default fallback for each slot. That remains the single source of truth for the baseline version everyone sees when no experience or experiment applies. You do not migrate it, and adoption is gradual, so unmapped content is untouched.
The variant content for an experience or an experiment is defined in Croct, against the slot. So the split is by role: the baseline is authored where it already lives in Sanity, and the targeted variations are authored in Croct. There is no duplication of the default, because Croct only holds the deltas you create for a given audience.
At request time the right version is resolved server-side, so the correct content arrives in the initial render with no client-side swap.
The Sanity integration guide covers the mapping model, and fallback content explains how the Sanity default is used when nothing matches.