Personnes et identité

Une personne est le profil durable derrière les événements : un humain (autant que Kilden puisse en juger), avec des traits mutables et un ou plusieurs distinct ids qui pointent vers lui.

Les distinct ids

Chaque événement nomme son acteur par distinct_id. Deux sortes :

• Anonyme : anon_ + UUID v7, généré par le SDK avant que vous sachiez qui est l’utilisateur.
• Identifié : votre propre id utilisateur, défini via identify() ou envoyé côté serveur.

Le format a du sens : tout ce qui ne ressemble pas à anon_<uuid7> est traité comme un utilisateur identifié — c’est ce qui rend les niveaux de confiance peu coûteux à calculer.

Une personne peut détenir de nombreux distinct ids (plusieurs appareils, ids d’avant et d’après l’inscription), jusqu’à un plafond de 100.

Traits

Les traits sont l’état courant de la personne — plan, email, entreprise — mis à jour par identify(id, traits), setPersonProperties(), ou les propriétés $set/$set_once sur n’importe quel événement :

• $set écrase.
• $set_once n’écrit que les clés qui n’existent pas encore.
• Les traits signés (dans un token d’identité vérifié) gagnent sur les valeurs non signées du même événement.

Les mises à jour de traits ne touchent jamais aux événements passés ; les événements gardent pour toujours l’instantané de leurs propriétés.

La fusion

Quand identify() révèle que deux personnes sont le même humain (votre id utilisateur existait déjà, et il vient d’être lié depuis une nouvelle session anonyme), elles fusionnent :

• La personne la plus ancienne survit ; les distinct ids de la plus récente sont repointés vers elle.
• En cas de conflit de traits, la survivante garde ses valeurs ; la personne absorbée ne comble que les trous.
• Les événements historiques ne sont pas réécrits (immuabilité) — les requêtes résolvent les anciens ids de personne vers la survivante à la lecture, donc les comptages restent corrects.

Les fusions sont unidirectionnelles et conservatrices : deux ids identifiés ne fusionnent jamais automatiquement (ce motif est presque toujours un bug d’instrumentation), et le SDK web n’expose pas d’alias() — identify couvre entièrement le cas navigateur.

Les données de personne dans les requêtes

Les requêtes d’analytics lisent les événements avec la personne résolue au moment de la requête (“person on events” plus une table d’overrides de fusion), si bien qu’une fusion survenue hier unifie rétroactivement tout l’historique d’un utilisateur, sans aucun job de backfill.