Résolution d'identité

La résolution d'identité (alias Fuse v2) est notre fonctionnalité de réconciliation d'identité en temps réel. Vos clients utilisent de nombreux appareils, passent d'un canal à un autre (web, mobile, shops, ads…) et souhaitent une expérience personnalisée sur tous ces appareils/canaux, dès lors qu'ils ont donné leur consentement via le CMP.

Par exemple, un client peut visiter votre site web pendant la journée avec son laptop, puis cliquer sur une ad et revenir plus tard pour acheter avec son mobile et contacter le service client 2 jours après. Votre objectif est d'unifier toutes ces actions autour d'un utilisateur unique, le défi étant souvent que cette donnée est stockée dans de nombreux systèmes : votre CRM, votre site web, votre agence publicitaire, votre système de service client… Le module de résolution d'identité vous permet de créer une vue complète de vos clients. Vous pouvez activer ce module au sein de la plateforme dans le menu Identity . Cet algorithme propriétaire de réconciliation en temps réel est alors le cœur de votre CDP. Il vous permet de définir les segments d'audience les plus appropriés et de mieux les activer.

Comment fonctionne l'algorithme ?

Techniquement, il utilise des clés de réconciliation afin d'apparier les différents visiteurs/utilisateurs. Ces clés sont définies par vous, cela peut être une adresse email, un ID personnel, un numéro de téléphone, une adresse postale…

Pour l'instant, seule 1 clé est gérée, mais plus tard vous pourrez définir plusieurs clés et les prioriser. Par exemple, vous pouvez définir que la clé principale est l'adresse email et, s'il n'y a pas d'email, la deuxième clé à vérifier est le numéro de téléphone ou tout autre élément que vous jugez pertinent pour vous et votre activité.

Une fusion entre 2 utilisateurs aura lieu si une correspondance est détectée parce que la clé de réconciliation est identique pour les 2 utilisateurs (adresse email, par exemple). L'utilisateur le plus récent est fusionné dans l'utilisateur le plus ancien. Les données collectées pour l'utilisateur le plus récent sont transférées sur l'utilisateur le plus ancien, et l'utilisateur le plus récent est supprimé.

Chaque document lié au visiteur B (conversions, pages vues, impressions, clics, consents…) est transféré vers l'utilisateur A. Aucune donnée n'est supprimée, seul l'utilisateur est supprimé, et les informations sont déplacées vers l'utilisateur principal (A dans notre exemple).

Que se passe-t-il pour les consents ?

Lorsque nous effectuerons une fusion, nous prendrons en compte les derniers consents enregistrés afin de respecter les choix des users.

Que se passe-t-il pour les Augmented User Attributes

Augmented user attributes (sum, min, max, count, calculus...) sont automatiquement recalculés lorsqu'une fusion se produit.

Comment sont gérés les devices partagés ?

Certains devices sont strictement personnels, comme les mobiles, mais d'autres peuvent être partagés comme les tablets. Par exemple, dans une famille, le mari peut utiliser la tablet et 1 heure plus tard la femme peut aussi utiliser la tablet. L'algorithme est capable d'identifier et de gérer ce comportement.

Dès qu'il détecte une nouvelle clé de réconciliation (login, adresse email, user_id) différente de la session précédente sur l'appareil, il peut distinguer différents users et adresser le bon user.

Dans le cas 1 (à gauche) il ne peut pas identifier un nouvel user car il n'y a pas de clés de réconciliation (pas de login, pas d'email...). Au contraire, dans le cas 2 (à droite), il y a un login, donc il peut créer un nouvel user ou mettre à jour un user existant. En conséquence, le tcid (identifiant cookie) reste le même mais le pid (identifiant personnel) est différent ainsi que le user_id.

Comment sont gérés les hotspots Wi‑Fi publics ?

Sur les hotspots publics, de nombreux devices partagent la même adresse IP, ils sont connectés au même réseau. Comment éviter d'avoir 1 user unique pour tous ces devices ?

Techniquement parlant, l'algorithme ne considère pas de la même manière les users sur Chrome / Android et les users sur Safari / iOS.

Sur Chrome / Android, il est capable de créer 1 user par device, avec des pid (Personal Identifier) différents parce que le tcid (=identifiant cookie) est différent.

Dès qu'il peut identifier 2 devices avec le même user_id (login par exemple), il peut fusionner ces 2 users, pour n'avoir qu'1 user unique pour ces 2 devices.

Pour Safari / iOS, c'est différent car il ne peut pas avoir différents tcid. En raison des limitations des cookies sur Safari, il utilise un fingerprint. Malheureusement, sur un hotspot public, tous les devices ont la même adresse IP et, par conséquent, le fingerprint est identique, ce qui signifie que nous avons 1 user unique pour tous ces devices.

Cependant, dès qu'il peut détecter qu'un user est unique (avec un login par exemple), il peut créer un user séparé.