Definiciones previas: qué decidir sobre cada fuente antes de crear objetos

Los objetos de Unomi (scopes, esquemas, reglas, segmentos) son la traducción de decisiones de datos y de negocio. Tomar estas decisiones primero y registrarlas; crearlos antes obliga a rehacerlos. Las decisiones ya tomadas en el diseño vigente figuran como "Decidido"; el resto queda a cargo del área de datos.

1. Inventario de fuentes y camino de entrada

Por cada fuente: quién captura, quién transforma al contrato de Unomi y con qué credencial entra.

Fuente	Captura	Transformación	Entrada	Estado
Tienda web	Cloudflare Zaraz	Función de destino de Jitsu	cdp-api con token de servicio cdp-jitsu	Decidido
ERP SAP	n8n (extracción)	Jitsu (misma función)	cdp-api con token cdp-n8n para lo administrativo	Decidido

2. Catálogo de eventos

Lista cerrada de tipos y, para cada uno, sus propiedades con tipo y obligatoriedad: es literalmente el esquema JSON. Empezar con pocos tipos bien definidos. Propuesta de partida (validada en el banco de pruebas):

Tipo	Scope	properties	target	Protegido
view (de fábrica)	tienda-web	—	página	no
productView	tienda-web	productId, categoria, precio	producto	no
addToCart	tienda-web	productId, cantidad	producto	no
purchase	tienda-web / sap	orderId, total, items[]	pedido con properties.total (entero)	no
login (de fábrica)	según origen	—	usuario con email, firstName, lastName, sapCustomerId	sí
updateProperties (de fábrica)	sap	propiedades a fijar	—	sí

Decidir además si SAP emite eventos propios (sapOrder, sapCustomerUpdate) o solo purchase y updateProperties.

3. Identidad

La decisión más importante. Decidido en el diseño vigente:

• profileId web = web-<identificador anónimo estable de Zaraz/Jitsu>; profileId SAP = sap-<código de cliente>.
• Clave de unión: correo electrónico normalizado (minúsculas, sin espacios), enviado en el evento login.
• La fusión la hace Unomi: el primer perfil que declara un correo lo conserva; los demás con el mismo correo se fusionan en él y sus ids quedan como aliases.

Pendiente de decidir por el área de datos:

• Qué hacer con clientes SAP sin correo (no se fusionan: quedan como perfiles separados).
• Si un correo compartido por varias personas debe fusionar o no (Unomi fusiona siempre).
• Qué propiedades son "fuente de verdad" de SAP y no deben ser pisadas por la web al fusionar (en una fusión gana el valor del perfil que se absorbe; ver identidad y fusión).

4. Sesión

Qué es una sesión en cada fuente. Web: la sesión de Jitsu (nueva tras 30 minutos de inactividad). SAP: no existe; convención decidida sap-<código de cliente>-<fecha>. Regla inviolable: nunca reutilizar un sessionId entre clientes distintos, porque la sesión manda sobre el profileId.

5. Scopes

Uno por propiedad digital emisora: tienda-web y sap. Sirven para distinguir el origen en reglas y segmentos. Más de tres scopes complica sin ganancia.

6. Propiedades del perfil

Qué campos de cliente se quieren consolidados (nombre, correo, teléfono, ciudad, categoría de cliente SAP, totalPurchases, montoCompras, lastPurchaseDate, categoriaInteres). Para cada uno: tipo, si es dato personal (etiqueta personalIdentifierProperties, la que usa la anonimización) y qué fuente lo escribe.

7. Histórico de SAP

Unomi ignora la fecha del evento que manda el cliente: todo evento se guarda con la hora de recepción. El histórico de compras no puede cargarse como eventos con su fecha real. Decidido: cargarlo como propiedades del perfil (totales, fecha de última compra) y enviar como eventos solo lo que ocurre desde la puesta en marcha.

8. Preguntas de negocio

Cada segmento responde una pregunta: "compradores recurrentes", "carrito abandonado en 7 días", "cliente SAP sin compra web", "interés en electrónica". Definir la lista inicial y, para cada una, qué contador o propiedad necesita (lo que a su vez define las reglas).

9. Volumen y retención

Eventos por día estimados y política de conservación. Configurado hoy: eventos y sesiones 400 días, perfiles inactivos 365 días, índices mensuales 13 meses. Validar contra la política de datos de la empresa.

Salida esperada

Con los puntos 2, 3, 5 y 6 cerrados se puede escribir el conjunto inicial de definiciones (scopes, esquemas, tipos de propiedad, regla de fusión, reglas de contadores, segmentos) y versionarlo en el repositorio.