Experience Platform · evolución de schemas XDM
El schema sin vuelta atrás
Tres meses después de salir a producción llegan las peticiones de cambio al schema de clientes: renombrar un campo, arreglar un tipo, borrar otro, cambiar la identidad principal. En AEP, un schema con datos solo puede crecer. Elige un cambio y mira qué dice la plataforma y qué hacer en su lugar.
Supuestos del ejemplo
Schema, campos y peticiones de ejemplo.
Clase XDM Individual Profile
Schema "Clientes ecommerce"
Los campos del schema, con el que toca el cambio marcado según lo que permite la plataforma.
Experience Platform
Qué dice la plataforma y qué hacer
Si el cambio rompe, la alternativa siempre es aditiva: un campo nuevo, un mapeo nuevo y el antiguo marcado como obsoleto.
La recomendación
Diseñar el schema como si no se pudiera cambiar, porque casi no se puede
Lo que en un proyecto normal es una migración de base de datos, en AEP es un campo nuevo, un mapeo nuevo y un campo antiguo que se queda para siempre.
- 01
Iterar sin datos
Probar el schema en un sandbox de desarrollo y, si hay que rehacerlo, borrarlo allí antes de crear datasets en producción. Con dataset creado, las reglas ya aplican.
- 02
Tipos y nombres pensados
Códigos postales, teléfonos e IDs como texto, aunque parezcan números. Nombres en inglés, estables y sin el sistema de origen dentro: tier, no crmTierCode.
- 03
La identidad principal primero
Es lo más caro de cambiar: con datos, obliga a un schema y un dataset nuevos. Hay que decidirla con el modelo de identidad cerrado.
- 04
Campos obsoletos a la vista
Lo que no se puede borrar se marca en su nombre visible y su descripción, y se deja de mapear. Así nadie construye audiencias sobre campos muertos.