Gestión de negocio en Unomi: cómo, dónde y quién¶

Esta sección está dirigida al responsable de ciencia de datos / marketing que define qué captura el CDP y cómo se interpreta: tipos de evento, propiedades del perfil, reglas de enriquecimiento, segmentos, scoring, goals e identidad. DevOps mantiene la plataforma (VM, contenedores, túnel, respaldos); las definiciones de negocio son responsabilidad del área de datos y se gestionan como se describe aquí.

Responsabilidades¶

Tema	Responsable	Dónde se gestiona
Catálogo de eventos y sus esquemas JSON	Ciencia de datos	Archivos JSON en el repositorio + `POST /cxs/jsonSchema`; consulta en Inoyu → JSON Schemas
Scopes (orígenes)	Ciencia de datos con DevOps	Inoyu → Scopes o `POST /cxs/scopes`
Tipos de propiedad del perfil	Ciencia de datos	Inoyu → Property Types (pestaña Basic) o `POST /cxs/profiles/properties`
Reglas de enriquecimiento y de fusión	Ciencia de datos	Inoyu → Rules (condición y acciones en JSON) o `POST /cxs/rules`
Segmentos, scoring, goals, listas	Ciencia de datos / marketing	Inoyu → Segments / Scoring / Goals / User Lists, o la API
Mapeo de eventos de origen (Zaraz, SAP) al contrato de Unomi	Ciencia de datos define, DevOps implementa en Jitsu / n8n	Función de destino de Jitsu; flujos de n8n
Borrado y anonimización por solicitud	Ciencia de datos solicita, DevOps ejecuta (o n8n)	`/cxs/privacy`
Plataforma, secretos, accesos, respaldos	DevOps	Ver runbook

Dónde: los tres caminos para administrar Unomi¶

Inoyu OSS UI (https://cdp.compulandia.com.py, acceso por SSO corporativo). Recomendado para consultar perfiles, sesiones y eventos, ver conteos de segmentos y estadísticas de reglas, y crear o editar objetos sencillos. En la edición open source las condiciones y acciones se escriben en JSON dentro de un editor con validación; el constructor visual es de la edición Pro.
API REST administrativa (https://cdp-api.compulandia.com.py/cxs/..., token de servicio de Cloudflare Access + usuario karaf). Recomendado para aplicar definiciones versionadas y para cargas o consultas masivas. Referencia de endpoints: manual de Unomi 3.0.x (https://unomi.apache.org/manual/3_0_x/).
Repositorio cdp-unomi. Toda definición que deba sobrevivir a una reinstalación (esquemas, scopes, reglas, segmentos, scoring) se guarda como JSON en el repositorio y se aplica por API con un script. Así un entorno nuevo se reconstruye desde el repositorio y cada cambio queda con historial y revisión. Ejemplo de script de aplicación: unomi-eval/tests/08-demo-ecommerce.sh (dataset de demostración; no ejecutar en producción).

Cómo: ciclo de un cambio de definición¶

Definir el cambio en términos de negocio (qué evento, qué propiedad, qué pregunta responde el segmento). Ver definiciones previas si es un objeto nuevo.
Escribir el JSON siguiendo las plantillas de esta sección.
Probar en el banco de pruebas local (setup): aplicar el JSON, enviar eventos de prueba y verificar el perfil. Para esquemas, usar POST /cxs/jsonSchema/validateEvent con un evento de ejemplo válido y uno inválido.
Versionar el JSON en el repositorio (carpeta de definiciones de producción; pendiente de crear en el primer cambio real) con un mensaje que explique el motivo.
Aplicar en producción por API (o desde Inoyu para cambios pequeños) y verificar con un evento real: que no aparezca ningún WARN SchemaServiceImpl en el log de Unomi y que el perfil refleje el cambio.
Comunicar a quien mantiene Jitsu / n8n si el contrato de entrada cambió (nuevo tipo de evento, propiedad nueva u obligatoria).

Qué tener siempre presente¶

Los eventos rechazados no avisan. Un evento que no cumple su esquema recibe 200 {"updated":0} y se descarta; el único rastro es el log de Unomi. Todo cambio de esquema debe coordinarse con el mapeo en Jitsu.
Los objetos nuevos tardan 1 a 2 segundos en estar activos (scopes, esquemas, reglas, segmentos). Un evento enviado en ese lapso se rechaza o no dispara la regla.
Las reglas no reprocesan el pasado. Un contador se calcula desde que existe la regla; para recalcular hay que reenviar eventos o escribir la propiedad por API.
La sesión manda sobre el perfil. Un sessionId ya ligado a un perfil atribuye los eventos a ese perfil, aunque se envíe otro profileId.
Todo lo creado a mano en Inoyu debe terminar en el repositorio, si no se pierde en una reinstalación.

Páginas de esta sección¶

Página	Contenido
Conceptos	Evento, perfil, sesión, scope, regla, segmento, scoring, goal: el modelo de Unomi en una lectura
Definiciones previas	Decisiones a tomar sobre cada fuente antes de crear objetos
Esquemas de eventos	Formato, registro, validación y errores típicos
Reglas, segmentos y scoring	Plantillas JSON, acciones y condiciones disponibles, limitaciones
Identidad y fusión	`profileId`, `sessionId`, evento `login`, fusión por correo, aliases
Privacidad	Anonimizar, borrar, exportar; retención
Tutorial con la demo e-commerce	Recorrido práctico en el banco de pruebas