Saltar a contenido

Conceptos: el modelo de Unomi

Unomi es un servidor de perfiles: junta todo lo que hace una persona en un único perfil, lo enriquece con reglas y lo clasifica en segmentos en tiempo real. Todo gira alrededor de estos objetos.

Objeto Qué es Cómo se identifica Dónde verlo
Evento Algo que hizo una persona: vio un producto, agregó al carrito, compró, se identificó. JSON con eventType, scope, properties y opcionalmente source y target. Cada tipo debe tener un esquema JSON registrado; si no, se descarta. eventType + id generado Inoyu → Profiles → perfil → Events; POST /cxs/events/search
Perfil La persona. properties (nombre, correo, totalPurchases, lo que se defina), segments a los que pertenece, scores y systemProperties internas. Se crea solo al primer evento con un profileId desconocido. profileId (lo asigna el origen) Inoyu → Profiles; GET /cxs/profiles/{id}
Sesión Una visita: agrupa los eventos de una misma navegación y está ligada a un perfil. Si un sessionId ya tiene perfil, ese perfil manda sobre el profileId enviado. sessionId (lo asigna el origen) Inoyu → perfil → Sessions; GET /cxs/profiles/{id}/sessions
Scope El origen de los eventos (tienda-web, sap). Todo evento pertenece a un scope registrado; el validador rechaza scopes desconocidos. id del scope Inoyu → Scopes; GET /cxs/scopes
Esquema JSON Contrato de un tipo de evento: qué propiedades admite, con qué tipo, cuáles son obligatorias. Con additionalProperties: false rechaza cualquier propiedad no declarada. $id (URL) + self.name = eventType Inoyu → JSON Schemas; GET /cxs/jsonSchema
Tipo de propiedad Declaración de una propiedad del perfil (id, nombre, tipo de valor, multivalor, si es dato personal). Opcional: Unomi crea propiedades al vuelo, pero declararlas les da tipo, nombre legible y etiquetas (por ejemplo personalIdentifierProperties para anonimizar). id Inoyu → Property Types; GET /cxs/profiles/properties
Regla "Cuando pase X, hacer Y": una condición sobre el evento o el perfil y una lista de acciones (fijar o incrementar una propiedad, copiar datos del evento, fusionar perfiles). Se ejecuta en la misma petición que recibe el evento. metadata.id Inoyu → Rules (con estadísticas); GET /cxs/rules
Segmento Grupo dinámico definido por una condición sobre el perfil ("totalPurchases ≥ 2", "agregó al carrito en 7 días y no compró"). La pertenencia se recalcula en cada evento que cambia el perfil. metadata.id Inoyu → Segments (con conteo); GET /cxs/segments/{id}/count
Scoring Plan de puntos: cada elemento es una condición con un valor; el perfil acumula puntos en scores. Sirve para "engagement" o priorización. metadata.id Inoyu → Scoring
Goal Conversión medida por sesión: evento de inicio y evento objetivo; informa sesiones iniciadas, convertidas y tasa. Solo cuenta sesiones posteriores a su creación. metadata.id Inoyu → Goals
Lista de usuarios Conjunto estático de perfiles asignados a mano o por API (a diferencia del segmento, que es dinámico). metadata.id Inoyu → User Lists
Alias Identificador alternativo de un perfil. Tras una fusión, el id del perfil absorbido queda como alias del perfil maestro; cualquier evento enviado con el id viejo se atribuye al maestro. id del alias GET /cxs/profiles/{id}/aliases

Cómo fluye

  1. Un sistema envía un evento a POST /cxs/eventcollector con profileId, sessionId y el evento.
  2. Unomi carga o crea el perfil y la sesión, y valida el evento contra el esquema de su tipo.
  3. Evalúa las reglas cuyas condiciones coinciden y ejecuta sus acciones (el perfil cambia).
  4. Si el perfil cambió, re-evalúa segmentos y scoring, y persiste perfil y sesión.
  5. Responde {"updated": N}: N es una máscara de cambios (sesión, perfil), no una confirmación de que el evento fue aceptado. Un evento válido que no dispara nada devuelve 0, igual que uno rechazado.

Dos APIs

  • Pública (/cxs/eventcollector, /cxs/context.json): sin credenciales, pensada para ser llamada por clientes finales; en Compulandia solo la usan Jitsu y n8n a través de Cloudflare Access. Los eventos protegidos (login, updateProperties) exigen además la cabecera X-Unomi-Peer.
  • Administrativa (/cxs/profiles, /cxs/rules, /cxs/segments, /cxs/jsonSchema, /cxs/privacy, ...): usuario karaf con Basic auth. Es la que usa Inoyu por detrás.

Latencias medidas (banco de pruebas, Unomi 3.0.0)

Qué Latencia
Evento → propiedad del perfil actualizada por una regla 50 a 75 ms
Entrada o salida de un segmento 55 a 85 ms
Fusión de dos perfiles en el login ~1,1 s; eventos reasignados en <1 s
Evento visible en /cxs/events/search 0,5 a 5 s (escritura por lotes)
Esquema, scope, regla o segmento nuevo activo 1 a 2 s