Connecteur source Adobe Analytics pour les données de suite de rapports
Adobe Experience Platform vous permet d’ingérer des données Adobe Analytics par le biais du connecteur source Analytics. Le connecteur source Analytics diffuse en temps réel les données collectées par Analytics vers Experience Platform, en convertissant les données Analytics au format SCDS en champs Experience Data Model (XDM) utilisables par Experience Platform.
Ce document présente une vue d’ensemble des Analytics et décrit des cas d’utilisation des données Analytics.
Adobe Analytics et données Analytics
Analytics est un moteur puissant qui vous permet d’en savoir plus sur vos clients, sur la manière dont ils interagissent avec vos propriétés web, de déterminer l’efficacité de vos dépenses en marketing numérique et d’identifier les améliorations à apporter. Analytics gère des trillions de transactions web par an et le connecteur source Analytics vous permet d’exploiter facilement ces riches données comportementales et d’enrichir le Real-Time Customer Profile en quelques minutes.
À un niveau élevé, Analytics collecte des données à partir de divers canaux numériques et de plusieurs centres de données dans le monde entier. Une fois les données collectées, les règles VISTA (Visitor Identification, Segmentation and Transformation Architecture) et les règles de traitement sont appliquées pour donner forme aux données entrantes. Une fois que les données brutes ont subi ce traitement léger, elles sont considérées comme prêtes à être utilisées par Real-Time Customer Profile. Parallèlement à ce qui précède, les mêmes données traitées sont microbatchées et ingérées dans des jeux de données Experience Platform pour être utilisées par Query Service et d’autres applications de découverte de données.
Pour plus d’informations sur les règles de traitement🔗 consultez la présentation des règles de traitement .
Modèle de données d’expérience (XDM)
XDM est une spécification documentée publiquement qui fournit des structures et des définitions communes à une application pour communiquer avec des services sur Experience Platform.
Le respect des normes XDM permet d’intégrer uniformément les données, ce qui facilite la diffusion des données et la collecte des informations.
Pour en savoir plus sur XDM, consultez la présentation du système XDM.
Comment les champs sont-ils mappés d’Adobe Analytics à XDM ?
Lorsqu’une connexion source est établie pour importer des données Analytics dans Experience Platform à l’aide de l’interface utilisateur d’Experience Platform, les champs de données sont automatiquement mappés et ingérés dans Real-Time Customer Profile en quelques minutes. Pour plus d’informations sur la création d’une connexion source avec Analytics à l’aide de l’interface utilisateur d’Experience Platform, consultez le tutoriel Connecteur source Analytics.
Pour plus d’informations sur le mappage des champs entre Analytics et Experience Platform, consultez le guide Mappage des champs Adobe Analytics .
Quelle est la latence attendue pour les données Analytics sur Experience Platform ?
La latence attendue pour les données Analytics sur Experience Platform est décrite dans le tableau ci-dessous. La latence varie en fonction de la configuration du client, des volumes de données et des applications clientes. Par exemple, si l’implémentation d’Analytics est configurée avec A4T, la latence du pipeline passera à 5-10 minutes.
Pour plus d’informations sur les latences de Customer Journey Analytics, voir : Mécanismes de sécurisation de Customer Journey Analytics.
Le renvoi Analytics pour les sandbox de production est défini par défaut sur 13 mois. Pour les données Analytics dans les sandbox hors production, le renvoi est défini sur trois mois. La limite de 10 milliards d’événements mentionnée dans le tableau ci-dessus est strictement liée à la latence attendue.
Lorsque vous créez un flux de données source Analytics dans un sandbox de production, deux flux de données sont créés :
- Flux de données qui renvoie pendant 13 mois les données historiques de la suite de rapports dans le lac de données. Ce flux de données se termine lorsque le renvoi est terminé.
- Flux de données qui envoie des données actives au lac de données et à Real-Time Customer Profile. Ce flux de données s’exécute en continu.
Identifiants de Principal dans les données Analytics
Chaque accès du connecteur source Analytics contient un identifiant principal qui dépend de l’existence ou non d’un ECID ou d’un AAID. S’il existe un ECID, l’ECID est désigné comme identifiant principal. S’il existe un AAID, l’AAID est désigné comme principal.
Le tableau suivant fournit des informations supplémentaires sur les champs d’identité dans vos données Analytics.
s_vi. Malgré cela, un AAID est créé même en l’absence du cookie s_vi. L’AAID est représenté par les colonnes post_visid_high et post_visid_low dans les Analytics flux de données. Sur un événement donné, le champ AAID contient une seule identité qui peut être l’un des différents types décrits dans l’ordre des opérations pour les Analytics IDs. Remarque : au sein d’une suite de rapports complète, un AAID peut contenir plusieurs types d’événements.mcvisid dans les flux de données Analytics. Pour plus d’informations sur l’ECID, consultez la présentation de l’ECID. Pour plus d’informations sur le fonctionnement de l’ECID avec Analytics, consultez le document sur les demandes d’identification Analytics et Experience Cloud.s.VisitorID dans l’implémentation Analytics. L’AACUSTOMID est représenté par la colonne cust_visid dans Analytics flux de données. Si l’AACUSTOMID est présent, l’AAID sera basé sur l’AACUSTOMID, car l’AACUSTOMID surpasse tous les autres identifiants comme défini par l’ordre des opérations pour les Analytics ID.Traitement des identités par la source de Analytics
La source Analytics transmet ces identités à Experience Platform sous forme XDM sous la forme suivante :
endUserIDs._experience.aaid.idendUserIDs._experience.mcid.idendUserIDs._experience.aacustomid.id
Ces champs ne sont pas marqués comme identités. Au lieu de cela, les mêmes identités (si elles sont présentes dans l’événement) sont copiées dans le identityMap de XDM en tant que paires clé-valeur :
{ "key": "AAID", "value": [ { "id": "<identity>", "primary": <true or false> } ] }{ "key": "ECID", "value": [ { "id": "<identity>", "primary": <true or false> } ] }{ "key": "AACUSTOMID", "value": [ { "id": "<identity>", "primary": false } ] }
Lorsque l’identité ou les identités sont copiées dans identityMap, endUserIDs._experience.mcid.namespace.code est également défini sur le même événement :
- Si l’AAID est présent,
endUserIDs._experience.aaid.namespace.codeest défini sur « AAID ». - Si l’ECID est présent,
endUserIDs._experience.mcid.namespace.codeest défini sur « ECID ». - Si l’AACUSTOMID est présent,
endUserIDs._experience.aacustomid.namespace.codeest défini sur « AACUSTOMID ».
Dans le mappage d’identités, si l’ECID est présent, il est marqué comme l’identité principale de l’événement. Dans ce cas, l’AAID peut être basé sur l’ECID en raison de la période de grâce du service d’identités. Dans le cas contraire, l’AAID est marqué comme l’identité principale de l’événement. L’AACUSTOMID n’est jamais marqué comme l’ID de Principal de l’événement. Cependant, en présence d’un AACUSTOMID, l’AAID est basé sur l’AACUSTOMID en raison de l’ordre des opérations d’Experience Cloud.