Création de politiques de fusion

Dans cette leçon, vous allez créer des politiques de fusion pour donner la priorité à la manière dont plusieurs sources de données fusionnent en profils.

Adobe Experience Platform vous permet de rassembler des données issues de plusieurs sources et de les combiner pour obtenir une vue complète de chaque client. Lors du regroupement de ces données, les politiques de fusion déterminent la priorité des données et les données combinées pour créer cette vue unifiée.

Nous nous en tiendrons à l’interface utilisateur pour cette leçon, mais il existe également des options d’API pour créer des politiques de fusion.

Architectes de données devront créer des politiques de fusion en dehors de ce tutoriel.

Avant de commencer les exercices, regardez cette courte vidéo pour en savoir plus sur les politiques de fusion :

Autorisations requises

Dans la leçon Configurer les autorisations, vous allez configurer tous les contrôles d’accès requis pour suivre cette leçon.

À propos des politiques de fusion et du schéma d’union

Vous vous souvenez peut-être que dans la leçon sur l’ingestion par lots, nous avons chargé deux enregistrements avec des informations légèrement différentes pour le même client. Dans les données Loyalty, le prénom du client était Daniel et il vivait en New York City, mais dans les données CRM, le prénom du client était Danny et il vivait en Portland. Les données clients changent au fil du temps. Peut-être est-il passé de Portland à New York City. D’autres éléments changent également, tels que les numéros de téléphone et les adresses e-mail. Les politiques de fusion vous aident à décider comment gérer ces types de conflits lorsque deux sources de données fournissent des informations différentes pour le même utilisateur.

Alors, pourquoi Danny a-t-il gagné comme prénom ? Jetons un coup d’œil :

Lorsque plusieurs schémas sont activés pour le profil, un schéma d’union est automatiquement créé pour tous les schémas d’enregistrement compatibles avec le profil et partageant une classe de base. Vous pouvez afficher les Schémas d’union en accédant à l’onglet Schéma d’union.

Notez qu’il n’existe pas de schéma d’union pour la classe ExperienceEvent. Bien que les données ExperienceEvent soient toujours conservées dans le profil, car elles sont basées sur des séries temporelles, chaque événement inclut une date et une heure, ainsi qu’un identifiant, et les collisions ne posent pas de problème.

Que se passe-t-il si vous n’aimez pas cette politique de fusion par défaut ? Que se passe-t-il si Luma décide que son système de fidélité doit être la source de vérité en cas de conflit ? Pour cela, nous allons créer une politique de fusion.

Créer une politique de fusion dans l’interface utilisateur

Validation de la politique de fusion

Voyons si la politique de fusion fonctionne comme prévu :

Créer une politique de fusion avec des jeux de données limités

Lors de la création de politiques de fusion à l’aide de la priorité du jeu de données, seuls les jeux de données de la même classe de base que celle que vous incluez à droite sont inclus dans le profil. Configurez une autre politique de fusion

Validation de la politique de fusion

Examinons maintenant l’effet de cette politique de fusion :

L’identifiant CRM est un champ d’identité de la Luma Loyalty Dataset, mais seules les identités principales peuvent être utilisées pour rechercher des profils. Recherchons donc le profil à l’aide de l’identité principale, Luma Loyalty Id »

En savoir plus sur les politiques de fusion

Dans la recherche de profil, redéfinissez la politique de fusion utilisée sur Default Timebased et sélectionnez le bouton Afficher le profil. Danny est de retour !

Que se passe-t-il ici ? Eh bien, la fusion de profils n'est pas une chose unique. Les profils clients en temps réel sont assemblés à la volée, en fonction de divers facteurs, y compris la politique de fusion utilisée. Vous pouvez créer plusieurs politiques de fusion à utiliser dans différents contextes, en fonction de la vue du client que vous souhaitez.

Un cas d’utilisation clé des politiques de fusion concerne la gouvernance des données. Supposons, par exemple, que vous ingériez des données tierces dans Platform qui ne peuvent pas être utilisées pour les cas d’utilisation de la personnalisation, mais peuvent être utilisées pour les cas d’utilisation de la publicité. Vous pouvez créer une politique de fusion qui exclut ce jeu de données tiers et utiliser cette politique de fusion pour créer des segments pour vos cas d’utilisation publicitaire.

Ressources supplémentaires

Passons maintenant au cadre de gouvernance des données.