La mise en œuvre de Customer Journey Analytics (CJA) s’accompagne de règles d’ingestion de données strictes, de limitations de mappage d’identités, de difficultés liées à l’ingestion de données historiques et de complexités dans la gestion des données de produit. La compréhension de ces problèmes et des solutions permet aux équipes d’éviter les écueils courants et de créer une configuration de CJA plus fiable.

Customer Journey Analytics (CJA) offre de puissantes fonctionnalités pour comprendre les expériences clientèle sur plusieurs points de contact. Cependant, mon expérience pratique révèle plusieurs difficultés et idées que j’aurais aimé connaître à l’avance. Dans cette publication, je partage quatre leçons essentielles sur l’ingestion de données, le mappage d’identités, l’ingestion de données historiques et la gestion des données de produit dans Adobe Experience Platform (AEP). Si vous devez faire face aux complexités de CJA, ces points à retenir peuvent vous aider à éviter les pièges courants.

1. Ingestion de données : règles strictes et difficultés cachées

L’un des premiers obstacles que j’ai rencontrés était les exigences d’ingestion de données plus strictes dans CJA par rapport à Adobe Analytics. Dans AEP, le schéma XDM sert de source unique de vérité, ce qui signifie que chaque attribut doit respecter précisément son format défini. Dans le cas contraire, il est rejeté. Voici quelques exemples clés :

• Les valeurs nulles ne sont pas autorisées.Tout attribut de valeur nulle est immédiatement refusé.
• Application stricte du type.Si un attribut est défini sous la forme d’une chaîne mais reçoit un entier (ou inversement), les données sont rejetées.

En revanche, Adobe Analytics collectait historiquement des données même lorsqu’elles étaient incorrectement formatées. Bien que cette clémence ait été pratique, l’application d’une qualité stricte des données dans AEP garantit des jeux de données plus propres et plus fiables.

Identification des erreurs d’ingestion dans AEP

Il n’est pas toujours simple de déterminer la cause première des erreurs d’ingestion dans AEP. Par exemple, si vous ingérez des données provenant de plusieurs propriétés Launch dans un seul jeu de données, des erreurs peuvent provenir de diverses sources. Malheureusement, l’interface d’utilisation du jeu de données d’AEP ne fournit pas suffisamment d’informations pour identifier la cause exacte. La résolution nécessite un processus de validation robuste. Les deux principaux emplacements pour le diagnostic d’erreur sont les suivants :

• Sources > Flux de données > Prévisualiser le diagnostic d’erreur : vous obtenez ainsi une prévisualisation de 100 erreurs au maximum.

• Journaux d’API : à l’aide d’outils tels que Postman, vous pouvez accéder à davantage de journaux granulaires à l’aide de l’API d’accès aux données (en savoir plus).

  Barry Mann a publié un article intéressant sur Medium qui explore en détail la grande variété d’erreurs d’ingestion.

2. CJA et mappage d’identités : pas vraiment un bon ménage

J’ai d’abord supposé que CJA traitait le mappage d’identités de la même manière qu’Adobe Customer Data Platform (CDP), où les éléments suivants sont vrais :

1. Un jeu de données d’expérience comprend un ID principal (par exemple, ECID) et un ID secondaire (par exemple, un numéro clientèle haché).
2. Un jeu de données de profil inclut l’ID principal (par exemple, un numéro clientèle haché).
3. En raison du graphique d’identité, les profils sont regroupés, fusionnant les données d’expérience et les données de profil pour obtenir une vue clientèle holistique.

Malheureusement, CJA ne prend pas en charge les graphiques d’identité de la même manière. Lors de la configuration de jeux de données dans CJA, vous pouvez uniquement mapper l’ID principal, ce qui signifie que CJA ne reconnaît pas le graphique d’identité.

Le groupement à la rescousse

Le groupement basé sur les champs (ou le groupement basé sur les graphiques, selon votre contrat) fournit une solution de contournement. Une fois configuré et ingéré dans CJA, il vous permet de joindre des jeux de données en fonction d’un ID transitoire (par exemple, le numéro clientèle haché) et d’un ID persistant (par exemple, ECID), ce qui produit le comportement attendu. Cependant, il est essentiel de comprendre que le groupement basé sur les champs crée un schéma et un jeu de données supplémentaires. Toutes les modifications apportées à votre schéma d’origine doivent également être appliquées au schéma groupé, ce qui ajoute une couche de complexité supplémentaire. Cela devrait être amélioré à partir du début de l’année 2026, car le groupement devrait être possible directement dans l’interface d’utilisation de connexion de CJA.

Selon les notes de mise à jour Adobe, «  le groupement dans les connexions simplifie le groupement Customer Journey Analytics. Au lieu de dupliquer un jeu de données et d’appliquer un groupement sur le jeu de données dupliqué, le groupement est désormais effectué sur l’ingestion de données dans Customer Journey Analytics, ce qui supprime l’exigence de jeux de données et de schémas dupliqués.  »

3. Ingestion des données historiques via le connecteur source Adobe Analytics : plus facile à dire qu’à faire

Mon plan initial était d’utiliser le connecteur source Adobe Analytics (AASC) pour ingérer des données historiques. Comme il crée deux flux de données et un jeu de données, j’ai supposé que je pouvais supprimer le flux de données continu et conserver les données historiques. Je me suis rendu compte que non.

Si vous supprimez le flux de données continu, le jeu de données est également supprimé, ce qui entraîne la perte des données historiques. En outre, l’utilisation d’AASC implique que vous devez conserver les eVars et props dans CJA, car le groupe de champs Expérience d’Adobe Analytics est obligatoire. Bien qu’il soit possible de mapper votre schéma XDM personnalisé, cette approche transfère inutilement l’intégralité de la structure eVar/prop dans AEP, ce qui n’est pas idéal.

Alternative : les flux de données

À la place, nous avons opté pour les flux de données, ce qui nous a permis de contourner les limitations d’AASC. Si vous ne connaissez pas les flux de données, ils fournissent des données d’analyse traitées, où chaque ligne représente une occurrence, y compris les eVars traitées ultérieurement (post_evar). Les flux de données incluent également des fichiers de recherche pour des dimensions telles que le pays, le navigateur ou le système d’exploitation, qui doivent être classées séparément. Nous avons géré l’ensemble du processus ETL à l’aide de scripts Python, qui ont :

1. exporté les flux de données ;
2. classé le fichier exporté à l’aide de fichiers de recherche ;
3. importé les données traitées dans AEP.

Cette approche s’est avérée plus flexible, mais a introduit des difficultés supplémentaires pour l’ingestion des données de produit, comme décrit ci-dessous.

4. Gestion des données de produit avec les flux de données : procéder avec précaution

Bien que les flux de données offrent un meilleur contrôle, l’ingestion de données de produit dans AEP posait plusieurs problèmes. Nous avons dû effectuer plusieurs itérations avant de trouver une solution fiable en raison de deux problèmes principaux :

1. Sensibilité des fonctions calculées dans les préparations de données AEP

AEP fournit des fonctions Adobe Analytics (par exemple, des fonctions aa_get) pour extraire des informations de la chaîne de produit. Toutefois :

• Si la chaîne de produit est vide (ce qui est courant pour les interactions hors e-commerce), une erreur NullPointer se produit, empêchant tout traitement ultérieur.

Si product_list n’est pas disponible, la vérification de la valeur nulle ne fonctionne pas correctement.

Solution : nous avons créé un attribut (isProductData) qui détermine si une ligne contient des données e-commerce (oui/non) et l’avons appliqué à la condition iif() pour contourner le problème.

2. Erreurs de formatage dans la chaîne du produit

• En raison de certains problèmes du côté du développement, certains noms de produits contenaient des points-virgules, ce qui a perturbé le traitement. Pire encore, si de telles erreurs s’affichaient dans les 10 premières lignes, le fichier entier était rejeté.

Les fonctions d’Adobe Analytics ne peuvent pas gérer les chaînes de produit configurées de manière incorrecte.

Ces problèmes soulignent l’importance de la validation robuste des données avant l’ingestion, en particulier pour les jeux de données liés aux produits.

Conclusion : comprendre les complexités de CJA

La transition vers CJA a été plus difficile que prévu en raison de ses exigences strictes en matière de données, des limites du mappage d’identités et de la complexité de la gestion des données de produit. Cependant, ses puissantes capacités d’analyse rendent l’effort pleinement justifié.

Points clés à retenir :

• Validez vos données rigoureusement avant l’ingestion pour éviter les échecs de traitement.
• Comprenez les limites du mappage d’identités et utilisez le groupement basé sur les champs si nécessaire.
• Planifiez soigneusement votre stratégie d’ingestion de données historiques : les flux de données constituent une alternative flexible à AASC.
• Testez minutieusement l’ingestion des données de produit, car les fonctions calculées sont sensibles aux erreurs de formatage.

Malgré les difficultés, la maîtrise de CJA permet d’obtenir de précieuses informations sur le comportement de la clientèle. Consacrer du temps pour comprendre ses complexités vaudra le coup au bout du compte.