Experience Platform · XDM schema evolution
The schema with no way back
Three months after go-live, change requests arrive for the customer schema: rename a field, fix a type, delete another, change the primary identity. In AEP, a schema with data can only grow. Choose a change and see what the platform says and what to do instead.
Example assumptions
Example schema, fields and requests.
XDM Individual Profile class
"Ecommerce customers" schema
The schema fields, with the one the change touches marked by what the platform allows.
Experience Platform
What the platform says and what to do
If the change is breaking, the alternative is always additive: a new field, a new mapping and the old one flagged as deprecated.
The recommendation
Design the schema as if it could not be changed, because it almost cannot
What in a normal project is a database migration is, in AEP, a new field, a new mapping and an old field that stays forever.
- 01
Iterate without data
Test the schema in a development sandbox and, if it needs redoing, delete it there before creating datasets in production. Once a dataset exists, the rules apply.
- 02
Well thought-out types and names
Postal codes, phone numbers and IDs as text, even if they look like numbers. Names in English, stable and without the source system in them: tier, not crmTierCode.
- 03
Primary identity first
It is the most expensive thing to change: with data, it requires a new schema and a new dataset. Decide it once the identity model is settled.
- 04
Deprecated fields in plain sight
What cannot be deleted gets flagged in its display name and description, and is no longer mapped. That way nobody builds audiences on dead fields.