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

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 =  Experimente as dicas de localização do Edge. Os nós regionais do AAM estão descritos nesta documentação, enquanto os mesmos nós regionais da Experience Edge estã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:

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, ele é transmitido no objeto experienceCloud.audienceManager.locationHint da carga da solicitação:

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

Observação: 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á apenas ..../ee/v1/..... No entanto, as chamadas subsequentes incluirão as informações do nó regional entre os elementos de caminho /ee/ and /v1/.

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 enviem dados para o nó regional correto AAM (e da biblioteca de Público-alvo).

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 as funções getMarketingCloudVisitorID (serviço de ID) ou getIdentity (SDK da Web). No entanto, além de obter a ECID, a dica de local também deve ser recuperada e usada usando a função getLocationHint (Serviço de ID) ou recuperando-a da carga de resposta das chamadas de 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, nós o convidamos a exibir nossa publicação do blog da Comunidade Experience League que inclui este artigo, envie-nos suas perguntas e comentários e participe da nossa Comunidade do Experience League!