> For the complete documentation index, see [llms.txt](https://doc.commandersact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.commandersact.com/fr/fonctionnalites/identity-resolution.md).
# Résolution d'identité
Identity resolution (alias Fuse v2) est notre **fonction de réconciliation d’identité en temps réel**.\
Vos clients utilisent de nombreux appareils, passent d’un canal à un autre (web, mobile, magasins, publicités…) et souhaiteraient une expérience personnalisée sur tous ces appareils/canaux, à partir du moment où ils ont donné leur consentement dans le [CMP](/fr/fonctionnalites/consent-management.md).
Par exemple, un client peut visiter votre site web dans la journée avec son ordinateur portable, puis cliquer sur une publicité et revenir plus tard pour acheter avec son téléphone mobile et contacter le service client 2 jours après.\
Votre objectif est d’unifier toutes ces actions autour d’un seul et unique utilisateur, 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éconciliation 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 *Identity* menu.\
\
Ce **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 adaptés et de mieux les activer.
## Comment fonctionne l’algorithme ?
Techniquement, il utilise **des clés de réconciliation** afin de faire correspondre les différents visiteurs/utilisateurs.\
Ces clés sont définies par vous, cela peut être une adresse e-mail, un ID personnel, un numéro de téléphone, une adresse postale…
Pour l’instant, une seule 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 e-mail et, s’il n’y a pas d’adresse e-mail, la deuxième clé à vérifier est le numéro de téléphone ou tout ce que vous jugez pertinent pour vous et votre entreprise.
Une fusion entre 2 utilisateurs aura lieu si une correspondance est détectée, car la clé de réconciliation est la même pour les 2 utilisateurs (adresse e-mail, par exemple). L’utilisateur le plus récent est fusionné dans le plus ancien. Les données collectées pour l’utilisateur le plus récent sont stockées sur le plus ancien, et l’utilisateur le plus récent est supprimé.
Tous les documents du visiteur B (conversions, pages vues, impressions, clics, consentements…) sont déplacés vers l’utilisateur A. Aucune donnée n’est supprimée, seul l’utilisateur est supprimé, et les informations sont transférées vers l’utilisateur principal (A dans notre exemple).
{% hint style="info" %}
Techniquement parlant, vous avez le **tcid ou caid** (cookie ID) pour identifier **les appareils,** **PID** (identifiant personnel) pour identifier **les utilisateurs** et **user\_id** pour identifier les utilisateurs à partir d’une clé provenant de nos clients (**CRM ID** par exemple).
**tcid = appareils**\
**pid = utilisateurs**\
**user\_id = utilisateurs (clé du client)**
{% endhint %}
## Que se passe-t-il pour les consentements ?
Lorsque nous effectuerons une fusion, nous prendrons en compte les derniers consentements enregistrés afin de respecter les choix des utilisateurs.
## Que se passe-t-il pour les attributs utilisateur augmentés
[Attributs utilisateur augmentés](/fr/fonctionnalites/enrichments/augmented-user-attributes.md) (somme, min, max, count, calculs...) sont automatiquement recalculés lorsqu’une fusion se produit.
## Comment sont gérés les appareils partagés ?
Certains appareils sont strictement personnels, comme les téléphones mobiles, mais d’autres peuvent être partagés comme les tablettes. Par exemple, dans une famille, le mari peut utiliser la tablette et 1 heure plus tard, la femme peut aussi utiliser la tablette. 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 e-mail, user\_id) différente de la session précédente sur l’appareil, il peut distinguer différents utilisateurs et s’adresser au bon utilisateur.
Dans le cas 1 (à gauche), il ne peut pas identifier un nouvel utilisateur car il n’y a pas de clés de réconciliation (pas de login, pas d’e-mail...). À l’inverse, dans le cas 2 (à droite), il y a un login, donc il peut créer un nouvel utilisateur ou mettre à jour un utilisateur 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 appareils partagent la même adresse IP, ils sont connectés au même réseau. Comment éviter d’avoir 1 utilisateur unique pour tous ces appareils ?
Techniquement parlant, l’algorithme ne considère pas de la même manière les utilisateurs sur Chrome / Android et les utilisateurs sur Safari / iOS.
Sur Chrome / Android, il est capable de créer 1 utilisateur par appareil, avec différents pid (Personal Identifier) car le tcid (=cookie identifier) est différent.
Dès qu’il peut identifier 2 appareils avec le même user\_id (login par exemple), il peut fusionner ces 2 utilisateurs, afin d’avoir 1 utilisateur unique pour ces 2 appareils.
Pour Safari / iOS, c’est différent car il ne peut pas avoir de tcid différent. En raison des limitations liées aux cookie sur Safari, il utilise une empreinte. Malheureusement, sur un hotspot public, tous les appareils ont la même adresse IP et, par conséquent, l’empreinte est la même, ce qui signifie que nous avons 1 utilisateur unique pour tous ces appareils.
Cependant, dès qu’il peut détecter qu’un utilisateur est unique (avec un login par exemple), il peut créer un utilisateur distinct.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://doc.commandersact.com/fr/fonctionnalites/identity-resolution.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.