How does personalization interact with Sanity's Live Content API?
We adopted the Live Content API on our media site so published edits show up near-instantly without redeploys, and it has been great.
Now personalization is on the roadmap and I am trying to reason about how the two systems would interact. My understanding is Live Content leans on shared, cacheable queries, so per-user personalized queries would fight it directly.
For anyone running Croct alongside it: where does variant resolution sit in that architecture, and does the live-update behavior survive once some components are personalized? curious about the internals here, not just "it works"
2 answers
The failure mode you are picturing is real: per-user personalized queries defeat the CDN that Live Content relies on. If user context leaks into the query, every visitor becomes a distinct cache entry and the shared-query model that makes live updates cheap falls apart.
The way the overlay avoids that is by never putting user context into your Sanity queries in the first place. Your GROQ stays user-agnostic and identical for every visitor, so Live Content keeps working exactly as it does now. Variant resolution happens on the Croct side, per visitor: the frontend asks Croct what content the slot should show for this person, separately from the Sanity data flow.
So architecturally you end up with two clean planes: a shared content plane (Sanity + Live Content, cacheable) and a per-visitor decision plane (Croct). They meet in your component, not in the query.
Adding the piece about what editors experience, since that was our worry. Default content keeps flowing through Live Content unchanged: an editor publishes a fix and it propagates to everyone who is seeing the default, instantly, same as today.
Personalized slots resolve separately, and they fall back to that same live default whenever no experience matches the visitor or the fetch fails. So the live-update behavior survives for the default path, and the personalized path is additive on top of it. The one thing to internalize is that variant copy is authored in the experience editor rather than in Studio, so a Studio edit updates the fallback, not the variants.