Conseils d’emplacement, nœuds régionaux AAM DCS et conseils d’emplacement du service ID

Découvrez la relation entre les conseils d’emplacement du SDK Web Adobe Experience Platform (AEP), les conseils d’emplacement du service Experience Cloud ID et les nœuds régionaux du serveur de collecte de données Adobe Audience Manager (AAM).

Description description

Environnement

Problème/Symptômes

Quelle est la relation entre les conseils d’emplacement du SDK WebSDK AEP (Adobe Experience Platform), le service Experience Cloud ID, les conseils d’emplacement et les nœuds régionaux AAM DCS et pourquoi est-il important de comprendre cette relation ?

Résolution resolution

La collecte de données en temps réel AEP WebSDK (qui envoie des données à Experience Edge) et Adobe Audience Manager (AAM) s’effectue sur des nœuds régionaux répartis dans le monde entier. Il existe 7 nœuds régionaux et AEP WebSDK/Experience Edge et la collecte de données AAM utilisent les mêmes nœuds. Les serveurs de collecte de données (DCS) d’AAM utilisent la même infrastructure réseau que celle d’Experience Edge. De même, puisque le service Experience Cloud ID utilise la technologie AAM, les indications d’emplacement du service d’ID sont les mêmes que les nœuds de collecte de données régionale AAM. En d’autres termes, Nœuds DCS AAM = Indicateurs d’emplacement du service d’ID =  Conseils d’emplacement pour Experience Edge. Les nœuds régionaux AAM sont décrits dans cette documentation, tandis que les mêmes nœuds régionaux Experience Edge sont décrits dans cette documentation.

Bien que les nœuds régionaux d’AAM et les indications d’emplacement du service d’ID soient identifiés par des chiffres et que l’Experience Edge soit identifié par des caractères alphanumériques, vous remarquerez qu’ils s’alignent tous sur les mêmes zones (sauf le Brésil).  Le tableau de recherche ci-dessous montre comment ils s’alignent :

La plupart des fonctionnalités de Adobe Experience Cloud qui nécessitent des réponses en temps réel utilisent ces nœuds régionaux. Le premier appel du service d’ID d’appel ou d’Experience Edge sur une page web ou une application mobile détermine le nœud régional à utiliser. Les indications d’emplacement se trouvent en réponse à ces appels :

Service Experience Cloud ID :

AEP Web SDK :

Une fois que le nœud régional le plus proche de l’utilisateur final est déterminé, l’identifiant de région est transmis via les appels Analytics, Target et AEP WebSDK. Dans Analytics, il est transmis en tant que paramètre de chaîne de requête aamlh :

Dans Target, il est transmis dans l’objet experienceCloud.audienceManager.locationHint de la payload de requête :

Pour AEP Web SDK, le chemin d’accès de l’appel est mis à jour pour refléter le nœud régional :

Remarque : La région ne figure PAS dans le chemin du premier appel d’interaction à partir du WebSDK AEP, car la région n’a pas encore été déterminée, mais l’indice d’emplacement sera dans la réponse (comme indiqué ci-dessus). Le chemin d’accès de la requête d’origine sera simplement ..../ee/v1/..... Cependant, les appels suivants incluront les informations du nœud régional entre les éléments de chemin d’accès /ee/ and /v1/.

Ces paramètres garantissent que les données Analytics transférées côté serveur sont transférées vers le nœud Edge d’AAM approprié, que Target demande des informations sur les segments à partir de ce même nœud Edge et que les données AEP envoient des données au nœud régional approprié d’AAM (et de la bibliothèque d’audiences).

Ces informations sont importantes à connaître lors de l’envoi d’accès côté serveur ou côté utilisateur de manière non standard à des solutions Adobe. Par exemple, un appel WebSDK AEP construit manuellement sur une page uniquement pour synchroniser un ECID (Experience Cloud ID) avec un profil AEP doit être envoyé au nœud régional Experience Edge approprié. Dans le cas contraire, toutes les données partagées d’AEP vers AAM seront transférées vers la base de données principale d’AAM, puis il faudra 48 heures supplémentaires à AAM pour transférer ces données vers chaque nœud Edge, ce qui ralentira considérablement le temps pendant lequel Target pourra utiliser les segments d’AEP envoyés à AAM (ou à la bibliothèque d’audiences). Ou si une requête Analytics côté serveur est envoyée au nœud 7, mais que l’implémentation Target sur la page de l’utilisateur utilise la région 9, les données sont transférées vers le nœud Est des États-Unis d’AAM, tandis que Target envoie un ping au nœud Ouest des États-Unis pour obtenir des informations sur le segment. L’utilisateur final ne pourrait pas se qualifier pour des activités Target utilisant les audiences de la bibliothèque d’audiences/les segments AAM tant que les nœuds finaux ne seront pas synchronisés 24 à 48 heures plus tard. Il est recommandé dans des cas d’utilisation comme ceux-ci d’obtenir l’ECID à l’aide des fonctions getMarketingCloudVisitorID (service d’ID) ou getIdentity (Web SDK). Cependant, en plus d’obtenir l’ECID, l’indicateur d’emplacement doit également être récupéré et utilisé à l’aide de la fonction getLocationHint (service d’ID) ou en le récupérant à partir de la payload de réponse des appels Web SDK.

Posez Des Questions Dans Notre Communauté Experience League Campaign
Si vous avez des questions à ce sujet ou si vous souhaitez lire les réponses aux questions précédentes, nous vous invitons à consulter notre article de blog de la communauté Experience League qui comprend cet article, à nous envoyer vos questions et commentaires et à rejoindre notre communauté Experience League Campaign.