Les consommateurs d'aujourd'hui s'attendent à ce que les interactions avec leur marque soient personnalisées et cohérentes sur tous les canaux. Dans l'écosystème numérique, proposer ces expériences n'est toutefois pas une tâche facile. Aujourd'hui, un parcours client typique comprend plusieurs points de contact, tels que des sites Web, des applications mobiles et des interactions en magasin, et s'étend souvent sur plusieurs sessions. Cela pose des défis aux chefs de produit et aux spécialistes du marketing qui tentent de comprendre l'engagement des clients. Pour proposer les expériences cohérentes auxquelles les clients s'attendent, il est impératif de disposer d'une vue unique et précise du comportement des clients sur tous les canaux. Cela peut être réalisé en unifiant les événements organisés sur des plateformes distinctes en un seul profil client à l'aide d'identifiants clients uniques, ou en résolvant les identités.

Lorsqu'il s'agit de résoudre les problèmes d'identité, les entreprises peuvent adopter l'une des deux principales approches suivantes : la création ou l'achat. Dans la première approche, les ingénieurs de données internes créent eux-mêmes cette fonctionnalité, ce qui constitue un processus à forte intensité de main-d'œuvre qui nécessite un travail de développement continu pour suivre l'évolution des besoins commerciaux en matière d'engagement des clients et d'analyse. Dans cette dernière approche, une entreprise adopte une plateforme de données qui gère la résolution des identités. Bien que cette option présente l'avantage immédiat d'éviter les frais d'ingénierie, les acheteurs doivent faire preuve de discernement lorsqu'ils déterminent la plateforme à adopter. Le marché ne manque pas de solutions promettant une « vision unique du client », mais la plupart de ces solutions échouent dans deux domaines critiques : la transparence des règles de fusion et le contrôle de l'établissement et de la modification des règles de fusion.

Dans la suite de leur article, nous verrons comment l'offre de résolution des identités de mParticle favorise la visibilité et la flexibilité, et soulignerons la valeur que les équipes chargées des données tirent de cette approche.

Comment fonctionne IDSync : résolution des identités adaptée à votre entreprise

La résolution d'identité est une fonctionnalité essentielle que mParticle fournit à tous ses clients dès le départ. Dès que vous mettrez en œuvre la collecte de données avec mParticle sur vos plateformes numériques, IDSync (le framework d'identité mParticle) commence à créer des profils clients unifiés à partir d'événements multicanaux sur la base d'une stratégie d'identité établie.

Explorez les principaux composants d'IDSync.

L'API Identity : le cheval de bataille d'IDSync

L'épine dorsale d'IDSync est l'API Identity. Cette API est ce que tous les différents SDK de mParticle utilisent pour déterminer le statut de connexion d'un utilisateur, ainsi que pour rechercher et modifier l'identité d'un utilisateur actuel. Chaque utilisateur de mParticle est défini par son identifiant mParticle (mPID), et cet identifiant permet à l'API Identity de relier les points de données entrants à un profil unique.

Le schéma ci-dessous illustre le fonctionnement d'un appel à l'API Identity :

A data flow diagram illustrating how identity data is unified using an IDSync API. On the left, multiple requests containing combinations of customer ID, email, and device ID are sent into the IDSync API. The API processes these inputs and returns a unified identifier called "mPID" (main Profile ID). This mPID is then linked to a consolidated user profile containing user identities, attributes, and devices, as well as associated events. The flow visualizes how fragmented identifiers are merged into a single user view for better tracking and personalization.

Les requêtes adressées à l'API Identity contiennent tous les identifiants connus de l'utilisateur actuel. Une fois la demande reçue, l'API Identity associe ces identifiants à tous les profils utilisateur du système en fonction d'une priorité d'identité établie (dont nous parlerons prochainement). Si tous les identificateurs correspondent à un profil, Identity API renverra le profil complet de cet utilisateur. Si certains identifiants se trouvent sur un profil, mais pas tous, IDSync mettra à jour ce profil pour inclure les nouveaux identifiants. Si aucune correspondance n'est trouvée, un nouveau profil utilisateur avec un nouveau MPid et les identifiants sera créé. Cette fonctionnalité de l'API Identity permet aux utilisateurs de mParticle d'utiliser différentes stratégies d'identité et de définir des priorités pour les types d'identité.

Stratégies d'identité : choisissez votre méthode de résolution d'identité

La stratégie optimale pour faire correspondre les identités des utilisateurs entre les sessions et les canaux dépend de nombreux facteurs, tels que les objectifs commerciaux et les obligations légales de l'entreprise. mParticle permet aux équipes de prendre leurs propres décisions sur la manière d'assurer la continuité des utilisateurs en fonction de leurs besoins spécifiques. Cette approche améliore le contrôle des données et garantit une visibilité complète sur la manière dont les profils utilisateurs sont créés et mis à jour.

La stratégie d'identité sélectionnée par un client orientera l'API Identity selon deux comportements clés :

  1. Déterminer le profil utilisateur auquel ajouter des points de données entrants lorsqu'une correspondance d'identité est trouvée
  2. Gestion des scénarios dans lesquels l'identité d'un utilisateur entrant est inconnue

mParticle a conçu cinq stratégies d'identité distinctes adaptées aux diverses exigences commerciales et de confidentialité.

  • Conversion de profil : cette stratégie donne la priorité à la formation d'une image complète d'un utilisateur tout au long de l'entonnoir de vente. Grâce à la conversion de profil, lorsqu'un nouvel identifiant de connexion est reçu, aucun nouveau MPID (et donc un nouveau profil utilisateur) n'est pas créé et le nouveau login est ajouté au profil qui a été créé pour capturer les données de cet utilisateur lorsqu'il était anonyme. Cette stratégie optimise l'amélioration de la visibilité sur les trajets qui couvrent les états anonymes et connectés.
  • Configuration IDSync par défaut : il s'agit d'une légère variation de la stratégie de conversion de profil dans laquelle l'identifiant unique et l'identifiant de connexion doit être défini sur customer_id. Cela ne peut pas être modifié. Cela réduit le risque que plusieurs identifiants de connexion produisent des doublons indésirables de profils utilisateur.
  • Lien vers le profil : visant à suivre les raisons qui poussent les utilisateurs à créer des comptes et à effectuer des achats, cette stratégie permet de mettre en lumière les événements de transition entre utilisateurs anonymes et utilisateurs connus en attribuant l'activité anonyme de l'application au prochain utilisateur connecté.
  • Isolation des profils : pratique dans les situations où les réglementations en matière de confidentialité interdisent d'attribuer des données anonymes à des utilisateurs connus, cette stratégie optimise la préservation de l'exactitude et de la fiabilité de chaque profil utilisateur.
  • Meilleure adéquation : cette stratégie convient aux modèles commerciaux dans lesquels les profils doivent être organisés en fonction des identifiants des appareils plutôt que des utilisateurs uniques. Les cas d'utilisation de Best Match incluent des marques qui ne prennent en charge aucun comportement de connexion ou des applications qui obligent les utilisateurs à créer un compte avant de les utiliser.

Les priorités en matière d'identité offrent un autre niveau de contrôle sur la création de profils

La définition d'une stratégie d'identité n'est pas la seule façon dont les clients de mParticle peuvent adapter la résolution des identités à leur activité. La possibilité de spécifier des priorités d'identité offre aux utilisateurs de mParticle un autre mécanisme pour affiner la manière dont les données entrantes seront traitées au niveau des profils clients.

Les priorités d'identité sont un ordre de priorité dans lequel différents identifiants seront utilisés pour faire correspondre les données entrantes à un profil utilisateur. Lorsqu'une demande d'identité est reçue, mParticle recherche les profils correspondants pour chaque identifiant de la demande en fonction de leur ordre de priorité. Si aucune correspondance n'est trouvée, un nouveau profil sera créé.

Regardons un exemple de la façon dont cela fonctionne dans la pratique. Supposons que nous ayons actuellement les deux profils d'utilisateurs suivants dans notre système :

A side-by-side comparison of two user profiles showing shared and unique identifiers. Both Profile 1 and Profile 2 have the same email (h.jekyll.md@example.com). Profile 1 includes IDFV 1234 and other ID AAAA, while Profile 2 includes GAID 2345 and other ID BBBB. This highlights identity fragmentation across profiles despite a shared email.

Voyons maintenant ce qui se passerait dans deux paires distinctes de priorités d'identité/demandes d'API :

A table showing how identity resolution requests to the IDSync API are processed based on defined identity priority. On the left, two ordered lists rank identifiers by priority—Customer ID first, followed by Email, then either “Other” or “IDFV” and GAID. On the right, corresponding IDSync API requests include different combinations of identifiers (e.g., email, IDFV, GAID, and a custom “Other” ID like AAAA or BBBB). This demonstrates how the API uses identity hierarchy to unify user profiles based on available data.

Dans le scénario le plus élevé, l'identité la plus prioritaire (e-mail) renverrait les deux profils dans le système. Ensuite, l'API Identity considérerait « Autre » comme identifiant de priorité le plus élevé suivant, et le profil 1 serait renvoyé. Le seul autre identifiant de la requête « IDFV » étant déjà présent sur le profil 1, il ne serait pas nécessaire d'ajouter cet identifiant au profil.

Dans le scénario inférieur, la recherche la plus prioritaire (e-mail) renverrait à nouveau les deux profils. L'API Identity considérait alors IDFV comme la priorité la plus élevée. Constant que l'IDFV ne figure pas dans la demande, il rechercherait GAID, qui renverrait alors le profil 2.

Les avantages d'IDSync pour les équipes de l'entreprise

Maintenant que nous avons jeté un coup d'œil à IDSync, explorons certains des avantages spécifiques que cette solution d'identité ouverte et transparente offre aux équipes d'une organisation.

Les équipes marketing offrent une meilleure personnalisation

Grâce à des profils clients unifiés hébergés dans mParticle, les spécialistes du marketing peuvent transmettre une vision globale de chaque utilisateur aux outils d'engagement en aval. Ils peuvent y diffuser des messages et améliorer les expériences clients en se basant sur une compréhension complète du comportement du client, et non sur une vision limitée de l'interaction sur un seul canal. De plus, comme ces équipes de croissance disposent d'une visibilité complète sur la manière dont les profils sont créés, elles peuvent être sûres qu'elles basent leurs campagnes d'engagement sur des informations précises et à jour.

Les équipes produit obtiennent des informations plus approfondies sur le parcours des utilisateurs

Les interactions des utilisateurs avec les produits numériques sont généralement fragmentées et se déroulent sur différents appareils et états de connexion. Par exemple, il n'est pas rare qu'un utilisateur télécharge une application, navigue sans créer de compte, crée un compte ultérieurement, continue à naviguer tout en étant connecté, puis effectue enfin un achat. En étant en mesure d'unifier les données avant et après la connexion, les chefs de produit peuvent développer une image beaucoup plus claire de l'ensemble du parcours utilisateur, identifier les points faibles et les blocages, et optimiser les flux d'utilisateurs afin de maximiser les chances de conversion.

Les équipes chargées de la confidentialité gèrent plus facilement la conformité

En étant en mesure de déterminer comment les profils utilisateur sont créés et mis à jour, les équipes chargées de la confidentialité peuvent adapter les stratégies d'identité afin de les aligner sur les exigences légales avant leur mise en œuvre. En outre, le fait de regrouper tous les attributs et événements comportementaux d'un utilisateur dans un seul profil permet aux équipes chargées de la confidentialité de répondre plus facilement aux demandes des personnes concernées (DSR) de manière rapide et rentable. Sans un processus automatisé transparent pour la gestion des DSR, ce processus coûte en moyenne aux organisations 1 524$ par demande, selon Gartner.

Les ingénieurs n'ont plus à créer et à gérer eux-mêmes la résolution des identités

Pour les ingénieurs de données, créer les pipelines de données qui alimentent la résolution des identités n'est pas une mince affaire. En fonction de l'ampleur des données clients d'une entreprise, l'unification des points de données sur les différents canaux en temps réel peut nécessiter des équipes importantes de développeurs entièrement dédiées à cette tâche. En déléguant le processus de résolution des identités à mParticle, les ingénieurs des données seront soulagés de cette charge permanente et permettront à ces équipes de se concentrer sur les fonctionnalités de base et les initiatives commerciales. C'est exactement la voie que les ingénieurs de Reverb ont décidé de suivre lorsqu'ils ont réalisé que leurs pipelines de données locaux devenaient ingérables.

No items found.
Précédent
Suivant