Dicas de localização, Nós regionais do AAM DCS e Dicas de localização do serviço de ID

Saiba mais sobre a relação entre as Dicas de localização do SDK da Web da Adobe Experience Platform (AEP), as Dicas de localização do serviço de ID de Experience Cloud e os Nós regionais do DCS da Adobe Audience Manager AAM ().

Descrição description

Ambiente

  • Experience Platform
  • Audience Manager

Problema/Sintomas

Qual é a relação entre as Dicas de localização do SDK da Web da AEP (Adobe Experience Platform), o Serviço de ID de Experience Cloud, as dicas de localização e os Nós regionais do DCS do AAM e por que é importante entender essa relação?

Resolução resolution

O AEP WebSDK (que envia dados para o Experience Edge) e a coleta de dados em tempo real do Adobe Audience Manager (AAM) ocorrem em nós regionais dispersos em todo o mundo. Há 7 nós regionais e a coleta de dados do AEP WebSDK/Experience Edge e AAM usa os mesmos nós. Os Servidores de coleta de dados (DCS) da AAM utilizam a mesma infraestrutura de rede que compõem a Experience Edge. Da mesma forma, como o serviço da Experience Cloud ID utiliza a tecnologia AAM, as dicas de localização do serviço de ID são as mesmas dos nós de coleta de dados regionais do AAM. Em outras palavras, nós DCS do AAM = Dicas de localização do serviço de ID = Dicas de localização da Experience Edge. Os nós regionais do AAM são descritos neste documentação, enquanto os mesmos nós regionais da Experience Edge são descritos nesta documentação.

Embora os nós regionais do AAM e as dicas de localização do serviço de ID sejam identificados por números e as da Experience Edge sejam identificadas por caracteres alfanuméricos, você observará que todos eles se alinham às mesmas áreas (exceto o Brasil).  A tabela de pesquisa abaixo demonstra como eles se alinham:

Dica de localização da Experience Edge
Dica de localização do nó/serviço de ID da região DCS do AAM
spg3
ID: 3 Host: apse.demdex.net
irl1
ID: 6 Host: irl1.demdex.net
va6
ID: 7 Host: use.demdex.net
aus3
ID: 8 Host: apse2.demdex.net
ou2
ID: 9 Host: usw2.demdex.net
jpn3
ID: 11 Host: tyo3.demdex.net
ind1
ID: 12 Host: ind1.demdex.net

A maioria da funcionalidade do Adobe Experience Cloud que requer respostas em tempo real utiliza esses nós regionais. A primeira chamada do Serviço de ID de chamada ou da Experience Edge em uma página da Web ou aplicativo móvel determina qual nó regional usar. As dicas de localização podem ser encontradas em resposta a essas chamadas:

Serviço de ID de Experience Cloud:

AEP Web SDK:

Depois de determinar o nó regional mais próximo do usuário final, o identificador de região é transmitido por meio do Analytics, Target e chamadas AEP WebSDK a partir de agora. No Analytics, ele é passado como o parâmetro da cadeia de caracteres de consulta aamlh:

No Target, ela é passada no experienceCloud.audienceManager.locationHint objeto da carga da solicitação:

Para o SDK da Web da AEP, o caminho da chamada é atualizado para refletir o nó regional:

Nota:  A primeira chamada interativa do AEP WebSDK NÃO terá a região no caminho porque, a região ainda não foi determinada, mas a dica de localização estará na resposta (como observado acima). O caminho da solicitação original será ..../ee/v1/.... No entanto, os convites subsequentes incluirão as informações sobre os nós regionais /ee/ and /v1/ elementos de caminho.

Esses parâmetros garantem que os dados encaminhados do Analytics pelo lado do servidor sejam encaminhados para o nó de borda AAM correto, que o Target solicite informações de segmento desse mesmo nó de borda e que Os dados da AEP enviam dados para o AAM (e da biblioteca de público-alvo) corrija o nó regional.

Essas informações são importantes para saber ao enviar ocorrências do lado do servidor ou do lado do usuário de maneiras não padrão para soluções de Adobe. Por exemplo, uma chamada de SDK da Web da AEP construída manualmente em uma página exclusivamente para sincronizar uma ECID (ID de Experience Cloud) com um perfil da AEP precisa ser enviada para o nó regional correto da Experience Edge. Caso contrário, quaisquer dados compartilhados de AEP para AAM irão para o banco de dados de back-end AAM e levarão 48 horas adicionais para o AAM AAM enviar esses dados para cada nó de borda, reduzindo drasticamente o tempo que o Target poderia usar quaisquer segmentos de AEP enviados para o (ou Biblioteca de público-alvo). Ou se uma solicitação do Analytics do lado do servidor for enviada para o nó 7, mas a implementação do Target na página do usuário usar a região 9, os dados serão encaminhados para o nó Leste dos EUA do AAM, enquanto o Target faz o ping do nó Oeste dos EUA para obter informações de segmento. O usuário final não poderia se qualificar para atividades do Target usando públicos-alvo da Biblioteca de público-alvo/segmentos AAM até que os nós finais fossem sincronizados 24 a 48 horas depois. É prática padrão em casos de uso como este obter a ECID usando o getMarketingCloudVisitorID (serviço de ID) ou getIdentity (SDK da Web). No entanto, além de obter a ECID, a dica de localização também deve ser recuperada e usada usando o getLocationHint (Serviço de ID) ou recuperando-a da carga de resposta das chamadas do SDK da Web.

Faça Perguntas Em Nossa Comunidade Do Experience League Campaign
Se você tiver perguntas que gostaria que fossem respondidas sobre este tópico ou ler perguntas já respondidas, convidamos você a ver as nossas Publicação do blog da comunidade do Experience League que inclui este artigo, envie-nos suas perguntas e comentários e junte-se à nossa Comunidade do Experience League Campaign!

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f