L’uid est un paramètre essentiel issu du datalayer. Il permet d’identifier formellement un utilisateur via un ID CRM.
La valeur envoyée dans ce paramètre est importante pour la collecte, car elle permet de fusionner des historiques marketing provenant de différents environnements. Les métriques UID servent donc à monitorer les valeurs envoyées dans ce paramètre et à vérifier la qualité d’une collecte cross-device, cross-navigateur ou omni-canal.
Les métriques UID permettent de suivre plusieurs situations liées à l’identification d’un utilisateur :
Les pages vues contenant un paramètre uid rempli
Les cas où une valeur uid envoyée diffère de celle habituellement associée
La création d’un nouvel identifiant utilisateur
La fusion de deux historiques marketing via le paramètre uid
Le cas où un même appareil ou cookie est réassocié à un identifiant différent
La métrique est incrémentée à chaque page vue contenant un paramètre uid rempli.
En clair, si une visite contient 10 pages et que l’internaute se logge à partir de la 8e page, le paramètre uid est ajouté à partir de cette page.
Soit une visite effectuée par le même internaute, qui s’identifie à partir de la troisième page :
L’internaute n’est pas identifié
L’internaute se déconnecte
La métrique est incrémentée lorsqu’une valeur est envoyée dans le paramètre uid, depuis le datalayer ou depuis une URL de tracking, mais que cette valeur n’est pas la même que celle habituellement envoyée.
En clair, si au cours d’une même visite un internaute s’identifie plusieurs fois avec des comptes différents, cette métrique est incrémentée pour chaque uid différent.
Contrairement à la métrique , qui ne peut être incrémentée que sur un appel collector, la métrique est aussi impactée par les clics.
Soit une série d’actions, pages ou clics, réalisées par le même internaute :
L’internaute est associé au uid A
L’internaute est toujours associé au même uid
L’internaute s’identifie avec une autre valeur
L’internaute est associé à B, mais en recliquant sur le lien il repasse à A
Un accès est comptabilisé lors de la création d’un nouvel identifiant utilisateur.
En clair, chaque fois qu’un nouvel identifiant unique est passé dans le paramètre uid, le système comptabilise un type d’accès supplémentaire .
Soit la navigation d’un même internaute sur plusieurs appareils :
Un premier cookie est créé pour cet internaute
L’internaute est non loggé
L’historique lié au cookie est pour la première fois associé à un paramètre uid A
L’historique est déjà lié à cet uid
Un correspond à la fusion de deux historiques marketing distincts via le paramètre uid, qui sert de clé de correspondance.
Dans ce cas, un type d’accès est comptabilisé avec un résultat .
Un merge n’est comptabilisé que si le uid unique existe déjà.
Si le cas correspond à une création ou à une première identification, c’est la métrique qui est incrémentée.
Il est aussi possible de merger l’historique de deux paramètres uid distincts.
Dans ce cas, le second récupère :
- l’historique marketing associé au premier, notamment les leviers ;
- les paramètres user du premier, si ces paramètres ne sont pas définis sur le second.
Par exemple, si le premier uid possède un paramètre user codepromo qui n’est pas défini dans le second, le second en hérite.
Soit la navigation d’un même internaute sur plusieurs appareils :
Un premier cookie est créé sur le mobile de l’internaute
L’internaute et son cookie sont associés au uid A
Pour l’instant, aucun moyen ne permet de lier le cookie précédent avec celui-ci
Les deux cookies sont désormais associés au uid A
Dans cet exemple, l’internaute a désormais deux leviers marketing associés : et .
Le est un cas particulier qui se produit lorsque, pour un même appareil ou cookie, l’internaute se connecte avec un identifiant différent encore jamais enregistré, c’est-à-dire avec un paramètre uid différent.
Dans ce cas, les historiques et les paramètres users sont fusionnés avant de faire pointer le cookie vers ce nouvel identifiant.
Soit l’historique suivant, sur le même appareil :
Association du cookie au uid A
Le cookie pointe désormais sur le uid B
Le cookie est associé au uid B
Le cookie est réassocié au uid A
Dans cet exemple, si l’internaute réalise une vente, celle-ci sera attribuée au levier et non au levier .
En effet :
- le levier est associé à l’historique A ;
- le levier est associé à l’historique B ;
- à la dernière page consultée, le cookie pointe vers l’identifiant A.
C’est donc l’historique associé à l’identifiant A qui est valide au moment de la vente.
Le paramètre uid est-il bien rempli sur les pages où l’utilisateur est identifié ?
La métrique Présence de l’UID dépend des pages vues contenant un uid rempli.
Un même internaute utilise-t-il plusieurs comptes au cours d’une même visite ?
Cela peut incrémenter la métrique UID cookie différent.
Le uid envoyé est-il nouveau pour le système ?
Dans ce cas, la métrique New UID peut être incrémentée.
Le uid existe-t-il déjà et permet-il de relier plusieurs historiques ?
Dans ce cas, un merge peut être comptabilisé.
Un même cookie pointe-t-il successivement vers plusieurs uid différents ?
Cela peut correspondre à un cas de UID split.
Les clics sont-ils pris en compte dans l’analyse ?
La métrique UID cookie différent peut être impactée par les clics.
- Le paramètre
uid permet d’identifier formellement un utilisateur via un ID CRM. - Il est utilisé pour fusionner des historiques marketing issus de différents environnements.
- La métrique compte les pages vues contenant un
uid rempli. - La métrique peut être incrémentée lorsqu’un internaute utilise plusieurs valeurs de
uid, y compris via des clics. - La métrique correspond à la création d’un nouvel identifiant utilisateur.
- La métrique correspond à la fusion de deux historiques marketing via un
uid existant. - Le est un cas particulier où un même appareil ou cookie est associé à un identifiant différent.
- Dans un cas de split, l’historique valide au moment de la vente dépend de l’identifiant vers lequel pointe le cookie à la dernière page consultée.