Migrando a implementação de AAM do seu site 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 AAM 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 de análise 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 em 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 obter dados do Adobe Analytics no AAM, significa que você tem duas ocorrências provenientes 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 retornadas de AAM para a página, onde podem ser usadas 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-alvo AAM para o Analytics, de modo que 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 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 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 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 de Experience Cloud ID (ECID)

O pré-requisito principal para migrar para Server-Side Forwarding é ter o Serviço de ID do Experience Cloud 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 do Adobe ou nenhum TMS, implemente o ECID para executar antes de qualquer outra solução do 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 no código DIL

À medida que você se prepara para migrar do Client-Side DIL para Server-Side Forwarding, a primeira etapa é identificar tudo o que você está fazendo com o DIL code, 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 de DIL siteCatalyst.init - Você não precisará se preocupar com essa, pois seu trabalho é apenas enviar as variáveis normais Analytics para cima, 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 pelo 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 DIL code para Server-Side Forwarding no Experience Platform Launch.

"Na página" ou não Adobe Tag Manager

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

NOTA: 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 do 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 de ID de Experience Cloud (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 do DIL para SSF PER report suite para que você habilite 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 em 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 do 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 eles sobre seu plano de migração para que eles possam ajudar conforme necessário

Validação e solução de problemas

A maneira principal 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.