Identifier les utilisateurs

Kilden sépare les événements (immuables) des personnes (mutables). Chaque événement porte un distinct_id ; la résolution d’identité associe les distinct ids à des personnes, pour que l’activité d’avant et d’après l’inscription appartienne au même humain.

Anonyme par défaut

À la première visite, le SDK génère un id anonyme — anon_ + UUID v7 — le persiste et l’appose sur chaque événement. Une personne est créée pour lui dès le premier événement. Aucun appel nécessaire.

identify() à la connexion ou à l’inscription

Quand vous savez qui est l’utilisateur, appelez identify avec votre id utilisateur stable (un id de base de données vaut mieux qu’un email — les emails changent) :

kilden.identify('user_4821', { email: '[email protected]', plan: 'pro' });

Cet appel émet un événement $identify qui porte les deux ids (l’id utilisateur comme distinct_id, l’id anonyme comme $anon_distinct_id). Le pipeline fait alors l’une de ces deux choses :

• Votre id utilisateur est nouveau (le cas courant, ~90 %) : il est ajouté comme distinct id supplémentaire à la personne du visiteur anonyme. Tout l’historique d’avant l’inscription est déjà attribué — rien ne bouge.
• Votre id utilisateur a déjà une personne (connexion sur un deuxième appareil) : les deux personnes fusionnent.

Appelez identify sur chaque page où l’utilisateur est connecté, pas seulement à la connexion — l’appel est idempotent, et c’est ce qui garde liés les nouveaux appareils et les navigateurs dont les données ont été effacées.

Ce que fait une fusion

• La personne la plus ancienne gagne (selon son created_at) ; les distinct ids de la plus récente sont repointés vers elle.
• Traits : en cas de conflit, la gagnante garde ses valeurs ; la perdante ne comble que les trous. Un $set ultérieur écrase dans tous les cas.
• Les événements passés continuent de fonctionner dans les requêtes : les fusions de personnes sont résolues au moment de la requête, donc les événements historiques attribués à la personne perdante comptent pour la gagnante.

Mettre à jour les traits

kilden.setPersonProperties(
  { plan: 'enterprise' },       // $set — écrase
  { signup_source: 'organic' }, // $set_once — seulement si absent
);

Les traits vivent sur la personne et peuvent changer ; les événements sont figés au moment de la capture. Si une valeur doit être digne de confiance (plan de facturation, revenu), envoyez-la côté serveur avec une clé secrète ou comme traits signés — tout ce qu’un navigateur envoie peut être forgé par le propriétaire du navigateur.

reset() à la déconnexion

kilden.reset();

Fait tourner l’id anonyme, efface le token d’identité et les super properties. Sautez cette étape, et la prochaine personne à se connecter sur ce navigateur sera liée à la piste anonyme de l’utilisateur précédent.

Les règles qui vous protègent

• Deux ids connus ne fusionnent jamais automatiquement. Si un utilisateur identifié se retrouve d’une manière ou d’une autre identifié sous un autre id connu, Kilden refuse la fusion (c’est presque toujours un bug d’instrumentation), la journalise, et attribue l’événement à la personne de l’id utilisateur. Le SDK web n’expose délibérément pas d’alias() — identify couvre entièrement le parcours navigateur ; $alias existe dans le pipeline pour les SDK serveur, où lier deux ids connus est légitime.
• Un plafond de distinct ids par personne (100 par défaut) empêche l’accumulation incontrôlée d’ids (“person bloat”) ; au-delà du plafond, les événements s’attribuent toujours, mais aucun nouveau mapping n’est créé.
• Avec la vérification d’identité en mode enforce, un identify non vérifié envoyé depuis un navigateur ne peut ni créer ni modifier de mappings d’identité.