Migrando a implementação do AAM de Client-Side DIL para Server-Side Forwarding

Este tutorial se aplica a você se tiver o Adobe Audience Manager (AAM) e o Adobe Analytics, e estiver enviando uma ocorrência da página para o AAM no momento usando o código "DIL" (Data Integration Library), e também enviando uma ocorrência da página para o Adobe Analytics. Como você tem ambas as soluções, e como elas são parte da Adobe Experience Cloud, você tem a oportunidade de seguir a prática recomendada de ativar o "Server-Side Forwarding (SSF)", que permite que os servidores de coleta de dados Analytics encaminhem os dados analíticos do site em tempo real para o Audience Manager, em vez de ter o código client-side envie uma ocorrência adicional da página para o AAM. Este tutorial o guiará pelas etapas da mudança da implementação mais antiga "Client-Side DIL" para o método mais recente "Server-Side forwarding".

Client-Side (DIL) vs. Server-Side

Ao comparar e contrastar esses dois métodos de colocar os dados do Adobe Analytics no AAM, pode ser útil primeiro visualizar as diferenças na imagem a seguir:

Client-side Implementação de DIL

Se estiver usando esse método para inserir dados do Adobe Analytics no AAM, significa que você tem duas ocorrências vindas de suas páginas da Web: Um indo para Analytics, e outro indo para AAM (após ter copiado os dados Analytics na página da Web. Segments são retornados do AAM para a página, onde podem ser usados para personalização, etc. Essa é uma implementação "herdada" e não é mais recomendada.

Além do fato de que isso não está seguindo as práticas recomendadas, as desvantagens de usar esse método incluem:

• Duas ocorrências vêm da página, em vez de apenas uma
• Server-Side Forwarding é necessário para o compartilhamento em tempo real de públicos do AAM com o Analytics, portanto, Client-side as implementações não permitem esse recurso (e possivelmente outros recursos no futuro)

Recomenda-se mudar para um método Server-Side Forwarding de implementação do AAM.

Server-Side Forwarding Implementação

Como mostrado na imagem acima, uma ocorrência vem da página da Web para o Adobe Analytics. Analytics em seguida, encaminha esses dados para o AAM em tempo real, e os visitantes são avaliados em AAM traits e segments, como se a ocorrência tivesse vindo diretamente da página.

Segments são retornados na mesma ocorrência em tempo real para Analytics, o que encaminha a resposta na página da Web para personalização etc.

Não há tempo para mudar para o encaminhamento pelo lado do servidor. Recomendamos que qualquer pessoa que tenha o Audience Manager e Analytics utilize esse método de implementação.

Existem DUAS Tarefas Principais

Há bastante informação nesta página, e é tudo importante, é claro. No entanto, tudo se resume a duas coisas principais que você precisa fazer:

1. Altere seu código de Client-Side DIL code para Server-Side Forwarding code
2. Inverta o switch no Analytics Admin Console para iniciar o encaminhamento real de dados (de acordo com report suite)

Se você ignorar qualquer um desses dois, o SSF não funcionará corretamente. As etapas e dados adicionais foram adicionados a este documento para ajudar você a executar essas duas etapas corretamente para sua configuração.

Opções de implementação

À medida que você muda de client-side para server-side, uma das tarefas que terá é alterar o código para o novo código Server-Side Forwarding. Isso é feito usando uma das seguintes opções:

• Adobe Experience Platform Launch - nossa opção de implementação recomendada para propriedades da Web. Você verá que esta é uma tarefa muito fácil, pois Launch fez tudo o que era difícil para você.
• Na página - Você também pode colocar o novo código SSF diretamente na função doPlugins dentro do arquivo appMeasurement.js, se não estiver (ainda) usando o Adobe Launch
• Outros gerenciadores de tags - Eles podem ser tratados da mesma forma que a opção anterior (Na página), já que você ainda colocará o código SSF em doPlugins, onde quer que o outro gerenciador de tags esteja armazenando o código AppMeasurement

Analisaremos cada um desses itens abaixo na seção Atualização do código .

Etapas da implementação

Etapa 0: Pré-requisito: Serviço da Experience Cloud ID (ECID)

O pré-requisito principal para migrar para Server-Side Forwarding é ter o Serviço da Experience Cloud ID implementado. Isso é feito com mais facilidade se estiver usando o Experience Platform Launch, nesse caso, basta instalar a extensão ECID e ele fará o resto.

Se você estiver usando um TMS que não seja da Adobe ou nenhum TMS, implemente a ECID para executar antes de de qualquer outra solução da Adobe. Consulte a documentação da ECID para obter mais detalhes. O único outro pré-requisito é relacionado às versões de código, de modo que você simplesmente aplique as versões mais recentes do código nas etapas a seguir, tudo ficará bem.

Etapa 1: Registrar opções atualmente usadas do código DIL

À medida que você se prepara para mudar do Client-Side código DIL para Server-Side Forwarding, a primeira etapa é identificar tudo o que você está fazendo com o código DIL, incluindo configurações personalizadas e dados enviados para o AAM. As coisas a serem notadas e consideradas incluem:

• Variáveis normais Analytics, usando o módulo siteCatalyst.init DIL - Você não precisará se preocupar com essa, pois seu trabalho é apenas enviar as variáveis normais Analytics pelo, e isso acontecerá em virtude de simplesmente ter o SSF ativado.
• Subdomínio do parceiro - Na função DIL.create , anote o parâmetro partner . Isso é conhecido como "subdomínio do parceiro" ou, às vezes, "ID do parceiro" e será necessário ao colocar o novo código SSF.
• Visitor Service Namespace - Também conhecido como "Org ID" ou "IMS Org ID," você também precisará disso ao configurar o novo código SSF. Tome nota disso.
• containerNSID, uuidCookie e outras opções avançadas - Anote todas as opções avançadas adicionais que estiver usando para que você possa defini-las no código SSF também.
• Variáveis de página adicionais - Se outras variáveis estiverem sendo enviadas para o AAM a partir da página (além das variáveis Analytics normais manipuladas pelo siteCatalyst.init), você precisará tomar nota delas para que possam ser enviadas por meio do SSF (alerta de spoiler: por meio de variáveis contextData).

Etapa 2: Atualização do código

Na seção acima intitulada "Opções de implementação", várias opções são fornecidas em relação a como/onde você está implementando Server-Side Forwarding. Para que esta seção seja eficaz, precisamos dividi-la nestas seções (com duas delas combinadas). Vá para o método desta seção que descreve melhor suas necessidades.

Adobe Experience Platform Launch

Assista ao vídeo abaixo para saber mais sobre como mover as opções de implementação do Client-Side código DIL para Server-Side Forwarding no Experience Platform Launch.

"Na página" ou Gerenciador de tags que não são da Adobe

Assista ao vídeo abaixo para saber mais sobre como mover as opções de implementação do Client-Side código DIL para Server-Side Forwarding no código AppMeasurement, residindo em um arquivo ou em um sistema de gerenciamento de tags que não seja da Adobe.

Etapa 3: Ativar o encaminhamento (de acordo com Report Suite)

Até agora neste tutorial, gastamos todo o nosso tempo alternando o código do Client-Side DIL código para Server-Side Forwarding. Tudo bem, porque é a parte mais difícil. Esta seção, embora você veja que é super fácil, é tão importante quanto atualizar o código. Neste vídeo, você verá como virar o switch que permite o encaminhamento real de dados do Analytics para o Audience Manager.

OBSERVAÇÃO: conforme declarado no vídeo, lembre-se de que a ativação do encaminhamento levará até 4 horas para ser totalmente implementada no back-end da Experience Cloud.

Tempo

Como lembrete, há duas tarefas principais para mudar de Client-Side DIL para Server-Side Forwarding:

1. Atualização do código
2. Deslizando o switch no Analytics Admin Console

Mas a questão é, qual delas você faz primeiro? Isso importa? OK, desculpe, isso foram duas perguntas. Mas as respostas são… depende, e sim, isso pode importar. Como isso é vago? Vamos dividir. Mas primeiro uma pergunta adicional que pode surgir se você for uma grande organização com muitos sites: Eu tenho que fazer tudo de uma vez? Esse é um pouco mais fácil. Não. Pode-se fazer isso, peça a peça… tipo. 😃

Um pouco mais profundo

O motivo pelo qual o tempo e a ordem são importantes é por causa de como o encaminhamento *realmente *funciona, que pode ser resumido nos seguintes fatos técnicos:

• Se o Serviço da Experience Cloud ID (ECID) estiver implementado e o switch no Analytics Admin Console ("o switch") estiver ativado, os dados serão encaminhados do Analytics para o AAM, mesmo que você ainda não tenha atualizado o código.
• Se você não tiver o ECID implementado, os dados não serão encaminhados, mesmo que você tenha a chave ligada, e terá o código SSF.
• O código SSF (seja em Launch ou na página) realmente lida com a resposta e é, claro, necessário para concluir a migração.
• Lembre-se de que o switch SSF é habilitado por Report Suite, mas que o código é manipulado pela propriedade em Launch ou por AppMeasurement arquivo, se você não usar Launch

Práticas recomendadas

Com base nesses detalhes técnicos, aqui estão as recomendações para o tempo de "o que fazer quando":

Se você NÃO tiver a ECID implementada

1. Inverta o switch em Analytics para cada report suite que você ativará para SSF

   1. O encaminhamento ainda não será iniciado porque você não tem ECID

2. Por site, atualize seu código de Client-Side DIL para SSF (isso pode estar em Launch ou na página, conforme discutido em outra seção acima)

   1. O encaminhamento agora fluirá (conforme você adicionou o ECID) e também deverá receber uma resposta JSON adequada ao beacon Analytics (consulte a seção Validação e solução de problemas abaixo para obter mais detalhes)

Se você tiver a ECID implementada

1. Prepare e planeje de forma que esteja pronto para atualizar seu código de DIL para SSF PER report suite que você habilitará para SSF:

   1. Inverta o switch em Analytics para ativar o SSF

      1. O encaminhamento será iniciado porque a ECID está habilitada

   2. Assim que possível, atualize seu código de Client-Side DIL para SSF (isso pode estar em Launch ou na página, conforme discutido em outra seção acima)

      1. Você deve receber uma resposta JSON adequada ao beacon Analytics (consulte a seção Validação e solução de problemas abaixo para obter mais detalhes)

NOTA 1: É importante fazer essas duas etapas o mais próximo possível uma da outra, pois entre as etapas 1 e 2 acima, você terá duplicação de dados entrando no AAM. Em outras palavras, o SSF começará a enviar dados de Analytics para o AAM e, como o código DIL ainda está na página, também haverá uma ocorrência indo diretamente da página para o AAM, dobrando os dados. Assim que você atualizar o código de DIL para SSF, isso será atenuado.

NOTA 2: se preferir ter uma pequena discrepância nos dados em vez de uma pequena duplicação de dados, você pode alterar a ordem das etapas 1 e 2 acima. Mover o código do DIL para o SSF interromperia o fluxo de dados para o AAM até que você pudesse virar o switch para ativar o SSF para o report suite. Normalmente, os clientes preferem ter uma pequena duplicação de dados em vez de deixar de colocar os visitantes em traits e segments.

Tempo de migração quando você tem muitos sites e Report Suites

Este tópico é brevemente abordado em seções anteriores, na medida em que a estratégia principal pode ser resumida pelo seguinte:

Migre um site/report suite (ou grupo de sites/report suites) de cada vez.

No entanto, isso pode se tornar um pouco complicado com base em alguns cenários possíveis:

• Você tem um site que contém vários report suites distintos
• Você tem um report suite que inclui vários sites (como um report suite global)
• Você usa uma propriedade Launch para abranger vários sites
• Você tem diferentes equipes de desenvolvimento para sites diferentes

Por causa desses itens, pode ficar um pouco complicado. As melhores coisas que posso sugerir são:

• Reserve algum tempo para fazer uma estratégia de migração para SSF, com base nas informações explicadas acima
• Com base no fato de que uma única propriedade em Launch (ou um único arquivo AppMeasurement) normalmente mapeia para 1 ou 2 report suites distintas, você provavelmente poderá fazer um plano que funcione nesses grupos distintos um por um, atualizando sua empresa para SSF
• Se você estiver trabalhando com a Adobe Consulting, fale com ela sobre seu plano de migração para que ela possa ajudar conforme necessário

Validação e solução de problemas

A principal maneira de validar que o Server-Side Forwarding está em execução é observar a resposta a qualquer uma das ocorrências do Adobe Analytics que vêm do aplicativo.

Se você não estiver fazendo server-side forwarding de dados de Analytics para o Audience Manager, então não há resposta para o sinal Analytics (fora um pixel com dimensões 2x2). No entanto, se estiver fazendo SSF, há itens que você pode verificar na solicitação e resposta Analytics que informam que Analytics está se comunicando corretamente com o Audience Manager, encaminhando a ocorrência e obtendo uma resposta.

AVISO: Cuidado com o falso “sucesso” - Se houver uma resposta e tudo parecer estar funcionando, verifique se você tem o objeto “stuff” na resposta. Caso contrário, você poderá ver uma mensagem que diz “status”:“SUCCESS”. Por mais louco que isso pareça, isso é prova de que NÃO está funcionando corretamente. Caso veja isso, significa que você concluiu a atualização do código em Launch ou AppMeasurement, mas que o encaminhamento no Analytics Admin Console ainda não foi concluído. Nesse caso, você precisa verificar se ativou o SSF no Analytics Admin Console para seu report suite. Se você tiver, e ainda não tiver passado quatro horas, seja paciente, pois pode levar tanto tempo para fazer todas as alterações necessárias no back-end.

Para obter mais informações sobre Server-Side Forwarding, consulte a documentação.