Personas e identidad
Una persona es el perfil duradero detrás de los eventos: un humano (hasta donde Kilden puede saber), con traits mutables y uno o más distinct ids que apuntan a ella.
Distinct ids
Sección titulada «Distinct ids»Cada evento nombra a su actor mediante distinct_id. Hay dos tipos:
- Anónimo:
anon_+ UUID v7, generado por el SDK antes de que sepas quién es el usuario. - Identificado: tu propio id de usuario, definido vía
identify()o enviado server-side.
El formato tiene significado: cualquier cosa que no luzca como anon_<uuid7> se trata como un usuario identificado — que es lo que hace baratos de computar los niveles de confianza.
Una persona puede tener muchos distinct ids (varios dispositivos, ids previos y posteriores al registro), hasta un tope de 100.
Los traits son el estado actual de la persona — plan, email, empresa — actualizados por identify(id, traits), setPersonProperties(), o properties $set/$set_once en cualquier evento:
$setsobreescribe.$set_onceescribe solo las keys que aún no existen.- Los traits firmados (dentro de un token de identidad verificado) ganan sobre los valores sin firmar del mismo evento.
Las actualizaciones de traits nunca tocan eventos pasados; los eventos conservan la foto de sus properties para siempre.
Cuando identify() revela que dos personas son el mismo humano (tu id de usuario ya existía, y acaba de enlazarse desde una nueva sesión anónima), se fusionan:
- La persona más antigua sobrevive; los distinct ids de la más nueva se re-apuntan a ella.
- En conflictos de traits la sobreviviente conserva sus valores; la persona absorbida solo rellena huecos.
- Los eventos históricos no se reescriben (inmutabilidad) — las queries resuelven los ids de persona viejos hacia la sobreviviente en tiempo de lectura, así los conteos se mantienen correctos.
Los merges son unidireccionales y conservadores: dos ids identificados nunca se fusionan automáticamente (ese patrón es casi siempre un bug de instrumentación), y el SDK web no expone alias() — identify cubre el caso del navegador por completo.
Datos de persona en las queries
Sección titulada «Datos de persona en las queries»Las queries de analytics leen los eventos con la persona resuelta en tiempo de consulta (“person on events” más una tabla de overrides de merge), así que un merge que ocurrió ayer unifica retroactivamente todo el historial de un usuario sin ningún job de backfill.