Conector de origem do Adobe Analytics para dados do conjunto de relatórios
O Adobe Experience Platform permite assimilar dados do Adobe Analytics por meio do conector de origem do Analytics. O conector transmite os dados do conjunto de relatórios para um conjunto de dados da Platform em tempo real, convertendo-os para o formato XDM.
Funcionamento do conector de origem do Analytics
Você continua a usar sua implementação existente do Adobe Analytics, como a AppMeasurement ou a extensão de tag da Adobe Analytics, para coletar dados em seus conjuntos de relatórios. O conector de origem não altera a forma como você coleta ou relata esses dados. Depois que os dados chegam aos servidores de coleta de dados do Analytics, o conector captura uma cópia deles.
Esta cópia é um formulário parcialmente processado de cada ocorrência, conhecido como valores médios. O Analytics produz valores médios após o pré-processamento (como regras de processamento), mas antes do processamento no nível da visita e do visitante. Como resultado, eles não incluem o contexto pós-processado, como o número de visitas. A ocorrência original continua pelo pipeline para ser gravada no conjunto de relatórios como de costume.
O conector transmite esses valores médios em um conjunto de dados na Experience Platform em tempo real. No data lake, os dados estão disponíveis para o Serviço de consulta e outros aplicativos de descoberta de dados e também podem enriquecer o Perfil do cliente em tempo real.
Para obter detalhes sobre como o Analytics coleta e processa dados, incluindo o estágio de valor médio, consulte Ordem de processamento dos dados no Adobe Analytics.
Mapeamento de campos do Adobe Analytics para o XDM
Ao criar uma conexão de origem na interface do usuário do Experience Platform, os campos do Analytics são mapeados automaticamente para XDM e assimilados em um conjunto de dados da Platform. Para obter instruções, consulte o Tutorial do conector de origem do Analytics.
Para obter informações detalhadas sobre o mapeamento de campos que ocorre entre o Analytics e o Experience Platform, consulte o guia Mapeamento de campos do Adobe Analytics.
Identificadores primários em dados do Analytics
Cada ocorrência do conector de origem do Analytics contém um identificador principal que depende de uma ECID ou AAID existir. Se houver uma ECID, a ECID será designada como o identificador principal. Se houver uma AAID, ela será designada como a principal.
A tabela a seguir fornece mais informações sobre campos de identidade nos dados do Analytics.
s_vi ID do cookie. Apesar disso, uma AAID é criada mesmo se o cookie s_vi não estiver presente. A AAID é representada pelas colunas post_visid_high e post_visid_low em Feeds de dados do Analytics. Em qualquer evento, o campo AAID contém uma única identidade que pode ser um dos vários tipos diferentes descritos na ordem de operações das IDs do Analytics. Observação: em um conjunto de relatórios inteiro, uma AAID pode conter uma combinação de tipos entre eventos.mcvisid nos feeds de dados do Analytics. Para obter mais informações sobre a ECID, consulte a visão geral da ECID. Para obter informações sobre como a ECID funciona com o Analytics, consulte o documento sobre Solicitações do Analytics e da Experience Cloud ID.visitorID na implementação do Analytics. Se a AACUSTOMID estiver presente, a AAID será baseada na AACUSTOMID, pois ela supera todos os outros identificadores, conforme definido pela ordem de operações das IDs do Analytics.Como a origem do Analytics trata identidades
A origem do Analytics passa essas identidades para o Experience Platform no formato XDM como:
endUserIDs._experience.aaid.idendUserIDs._experience.mcid.idendUserIDs._experience.aacustomid.id
Esses campos não são marcados como identidades. Em vez disso, as mesmas identidades (se presentes no evento) são copiadas para o identityMap do XDM como pares de valores chave:
{ "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 } ] }
Quando a identidade ou identidades são copiadas para identityMap, endUserIDs._experience.mcid.namespace.code também é definido no mesmo evento:
- Se a AAID estiver presente,
endUserIDs._experience.aaid.namespace.codeserá definido como “AAID”. - Se a ECID estiver presente,
endUserIDs._experience.mcid.namespace.codeserá definido como “ECID”. - Se AACUSTOMID estiver presente,
endUserIDs._experience.aacustomid.namespace.codeserá definido como “AACUSTOMID”.
No mapa de identidade, se a ECID estiver presente, ela será marcada como a identidade principal do evento. Nesse caso, a AAID pode se basear na ECID devido ao período de carência do Serviço de identidade. Caso contrário, a AAID será marcada como a identidade principal do evento. AACUSTOMID nunca é marcada como a ID primária do evento. No entanto, se a AACUSTOMID estiver presente, a AAID será baseada na AACUSTOMID devido à ordem de operações da Experience Cloud.
Precisão do carimbo de data e hora da ocorrência e ordenação de eventos
O conector recebe dados do Analytics como valores médios, que carregam carimbos de data e hora de ocorrência de segundo nível. Como o Analytics registra o tempo somente com precisão de segundo nível e não rastreia o tempo em subsegundos, a ordem das ocorrências coletadas no mesmo segundo não é determinística. Como resultado, a ordem dos eventos de mesmo segundo assimilados por meio do conector pode ser diferente da ordem mostrada nos relatórios do Analytics.
O Customer Journey Analytics resolve os carimbos de data e hora para milissegundo, mas os dados obtidos pelo Analytics são preenchidos apenas por segundos inteiros. O carimbo de data e hora por si só não pode estabelecer a ordem relativa de eventos que compartilham o mesmo segundo. Isso é mais notável quando várias ocorrências são coletadas no mesmo segundo (por exemplo, uma exibição de página e uma ocorrência do Adobe Target (A4T)).
Para obter mais informações sobre a precisão do carimbo de data e hora do Analytics, consulte a variável carimbo de data e hora da Adobe Analytics e a documentação Profundidade da ocorrência. Para os campos de carimbo de data/hora que o conector mapeia para XDM (hit_time_gmt e post_cust_hit_time_gmt), consulte o guia de mapeamento de campos do Adobe Analytics.
Suas opções para precisão de carimbo de data e hora incluem:
- Aceitar pequenas diferenças de ordenação de mesmo segundo. Para a maioria dos relatórios, o efeito é limitado a eventos que compartilham o mesmo segundo e não afeta métricas agregadas. Essa é a abordagem recomendada, incluindo para cenários mistos de visualização de página e Adobe Target (A4T).
- Para casos de uso que diferenciam pedidos, prefira o Web SDK. O envio de dados por meio da Adobe Experience Platform Web SDK diretamente para o Experience Platform e o Customer Journey Analytics preserva a precisão do carimbo de data/hora de subsegundos (milissegundos) e evita o reprocessamento do Analytics. Essa abordagem é recomendada quando a ordem dos eventos é importante.
Latência e preenchimento retroativo de dados
A latência esperada para dados do Analytics no Experience Platform é descrita na tabela abaixo. A latência varia dependendo da configuração do cliente, dos volumes de dados e dos aplicativos do consumidor. Por exemplo, se a implementação do Analytics estiver configurada com A4T, a latência para o pipeline aumenta de 5 a 10 minutos.
Para obter mais informações sobre latências de Customer Journey Analytics, consulte: Medidas de Proteção do Customer Journey Analytics.
O preenchimento retroativo do Analytics para sandboxes de produção assume o padrão de 13 meses. Para dados do Analytics em sandboxes de não produção, o preenchimento retroativo é definido como três meses. O limite de 10 bilhões de eventos mencionados na tabela acima diz respeito estritamente à latência esperada.
Ao criar um fluxo de dados de origem do Analytics em uma sandbox de produção, dois fluxos de dados são criados:
- Um fluxo de dados que faz um preenchimento retroativo de 13 meses de dados históricos do conjunto de relatórios no data lake. Esse fluxo de dados termina quando o preenchimento retroativo é concluído.
- Um fluxo de dados que envia dados em tempo real ao data lake e ao Perfil do cliente em tempo real. Esse fluxo de dados é executado continuamente.
Práticas recomendadas
Siga estas práticas recomendadas para não exceder seus direitos de licença e sobrecarregar suas métricas de armazenamento total e riqueza de dados:
- Configure o TTL (Time-To-Live, tempo de vida útil) de retenção do conjunto de dados do evento de experiência no início para otimizar o gerenciamento do ciclo de vida dos dados e a eficiência do armazenamento. Para obter mais detalhes, consulte o manual sobre gerenciamento da Retenção do Conjunto de Dados do Evento de Experiência no data lake usando TTL.
- Ao criar um fluxo de dados de origem do Analytics, comece configurando o conector para assimilar dados somente no data lake. Depois de confirmar que o fluxo de dados está funcionando, você pode ativar a Assimilação de perfil para o conjunto de dados. Essa abordagem funciona melhor quando os filtros de linha e coluna reduzem efetivamente o volume de dados. Saiba mais na documentação conectando o Adobe Analytics ao Experience Platform.