# How does mapping Sanity components to Croct slots work?

Asked by Abdul Rahman on 2024-05-22. Tags: sanity, slots, integration.

Before I propose this internally I want to make sure I understand the model.
Our Sanity site is heavy on portable text and we have a well-established
schema that nobody wants to restructure.

The integration pages talk about mapping existing Sanity components to Croct
and adding personalization on top. What exactly maps to what here, is a slot
per component, per document, per page? And does our Sanity content model have
to change at all, or does the mapping live entirely outside the dataset

## 1 answer

### Accepted answer from Owen McCarthy (2024-05-22)

Your Sanity content model does not change. The mapping lives on the Croct
side plus a small amount of frontend code, not in your dataset.

The two concepts to get straight:

1. A component in Croct is the reusable building block, defined by a
   component schema, roughly mirroring the Sanity component you already
   render (a hero section, a CTA banner).
2. A slot is a context-specific placeholder bound to one component schema.
   It is the specific place where that component renders, like "home hero".
   Component is the type, slot is the location.

So you map component to component and place slots where personalization
should happen. The overall flow is three steps: link your Sanity components
to slots, build experiences or A/B tests on those slots, monitor the
results.

The part your team will like: your Sanity content stays as the fallback.
When no experience matches a visitor, or you delete everything later, the
regular Sanity content renders exactly as it does today. It is an overlay,
not a replacement, so you can pilot it on one component without touching
the rest of the schema.
