Migrar a implementação de Audience Manager do seu site do DIL do lado do cliente para o encaminhamento do lado do servidor migrating-your-site-s-aam-implementation-from-client-side-dil-to-server-side-forwarding

Este tutorial se aplica se você tiver o Adobe Audience Manager (AAM) e o Adobe Analytics e estiver enviando uma ocorrência da página para o AAM usando o DIL (Data Integration Library) e também enviando uma ocorrência da página para a Adobe Analytics. Como essas duas soluções existem e como elas fazem parte da Adobe Experience Cloud, você tem a oportunidade de seguir a prática recomendada de ativar o encaminhamento pelo lado do servidor, o que permite Analytics servidores de coleta de dados para encaminhar os dados de análise do site em tempo real para o Audience Manager, em vez de fazer com que o código do lado do cliente envie uma ocorrência adicional da página para o AAM. Este tutorial o guiará pelas etapas de mudança da implementação de DIL do lado do cliente mais antiga para o método de encaminhamento do lado do servidor mais recente.

Lado do cliente (DIL) vs. lado do servidor client-side-dil-vs-server-side

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

do lado do cliente para o lado do servidor

Implementação de DIL do lado do cliente client-side-dil-implementation

Se você usar esse método para inserir dados do Adobe Analytics no AAM, você terá duas ocorrências vindas das suas páginas da Web: uma vai para Analytics, e um para AAM (após ter copiado o Analytics dados na página da Web. Segments são retornados do AAM para a página, onde podem ser usados para personalização e assim por diante. Essa é uma implementação herdada e não é mais recomendada.

Além de não seguir as práticas recomendadas, as desvantagens de usar esse método incluem:

  • Duas ocorrências vindas da página em vez de apenas uma
  • o encaminhamento pelo lado do servidor é necessário para o compartilhamento em tempo real de públicos-alvo do AAM para Analytics, portanto, as implementações do lado do cliente não permitem esse recurso (e possivelmente outros recursos no futuro)

É recomendável mudar para um método de encaminhamento do lado do servidor de implementação do AAM.

Implementação do encaminhamento pelo lado do servidor server-side-forwarding-implementation

Como mostrado na imagem acima, uma ocorrência vem da página da Web para o Adobe Analytics. Analytics em seguida, o encaminha esses dados para o AAM em tempo real, e os visitantes são avaliados em características de AAM 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, que encaminha a resposta à página da Web para personalização e assim por diante.

Não há desvantagem de tempo para migrar para o encaminhamento pelo lado do servidor. A Adobe recomenda que qualquer pessoa que tenha Audience Manager e Analytics O usa esse método de implementação.

Você tem duas tarefas principais you-have-two-main-tasks

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

  1. Altere o código de DIL do lado do cliente para código de encaminhamento do lado do servidor
  2. Inverta o switch no Analytics Admin Console para iniciar o encaminhamento real de dados (por report suite)

Se você ignorar qualquer uma dessas tarefas, o encaminhamento pelo lado do servidor não funcionará corretamente. Etapas e dados adicionais foram adicionados a este documento para ajudá-lo a executar essas duas etapas corretamente para sua configuração.

Opções de implementação implementation-options

À medida que você migra do encaminhamento pelo lado do cliente para o do lado do servidor, uma das tarefas que você terá é alterar o código para o novo código de encaminhamento do lado do servidor. Isso é feito usando uma das seguintes opções:

  • Tags do Adobe Experience Platform - opção de implementação recomendada para propriedades da Web do Adobe. Você perceberá que essa é uma tarefa fácil, já que as tags da Platform fizeram todo o trabalho árduo para você.
  • Na página - Também é possível colocar o novo código SSF diretamente no doPlugins função dentro do seu appMeasurement.js arquivo, se você não estiver (ainda) usando o Adobe Launch
  • Outros gerenciadores de tags - Eles podem ser tratados como a opção anterior (na página), pois você ainda colocará o código SSF no doPlugins, onde quer que o outro gerenciador de tags armazene a AppMeasurement código

Examinaremos cada um desses itens abaixo no Atualização do código seção.

Etapas de implementação implementation-steps

As etapas a seguir descrevem a implementação.

Etapa 0: Pré-requisito: Experience Cloud ID Service (ECID) step-prerequisite-experience-cloud-id-service-ecid

O principal pré-requisito para migrar para o encaminhamento pelo lado do servidor é ter o Serviço de ID de Experience Cloud implementado. Isso é feito com mais facilidade se você estiver usando o Experience Platform Launch, nesse caso, basta instalar a extensão ECID e ela fará o resto.

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

NOTE
Leia todo este documento antes de implementar. A seção "Intervalos" abaixo contém informações importantes sobre quando você deve implementar cada parte, incluindo a ECID (se ainda não estiver implementada).

Etapa 1: Registrar opções usadas atualmente do código DIL step-record-currently-used-options-from-dil-code

À medida que você se prepara para mudar do código de DIL do lado do cliente para o encaminhamento do lado do servidor, a primeira etapa é identificar tudo o que você está fazendo com o código de DIL, incluindo configurações personalizadas e dados enviados para o AAM. Os aspectos a serem observados e considerados incluem:

  • Normal Analytics variáveis, usando o siteCatalyst.init módulo DIL - Você não precisa se preocupar com este, porque seu trabalho é apenas enviar o normal Analytics sobre, e isso acontece em virtude de simplesmente ter o encaminhamento pelo lado do servidor ativado.
  • Subdomínio do parceiro - na DIL.create faça uma anotação da partner parâmetro. Isso é conhecido como "subdomínio do parceiro", ou, às vezes, "ID do parceiro", e será necessário ao inserir o novo código de encaminhamento do lado do servidor.
  • Visitor Service Namespace - Também conhecido como "Org ID" ou "IMS Org ID," você também precisará disso ao configurar o novo código de encaminhamento do lado do servidor. Anote-o.
  • containerNSID, uuidCookie e outras opções avançadas - Anote as opções avançadas adicionais que você estiver usando para que também possa defini-las no código de encaminhamento do lado do servidor.
  • Variáveis de página adicionais - Se outras variáveis estiverem sendo enviadas para o AAM na página (além das variáveis normais Analytics variáveis manipuladas pelo siteCatalyst.init), será necessário anotá-las para que possam ser enviadas por meio do encaminhamento pelo lado do servidor (alerta do spoiler: via contextData variáveis).

Etapa 2: atualizar o código step-updating-the-code

Entrada Opções de implementação (acima), várias opções são fornecidas em relação a como e onde você está implementando o encaminhamento pelo lado do servidor. Para que essa seção seja eficaz, precisamos dividi-la nessas seções (com duas delas combinadas). Vá para o método desta seção que melhor descreve suas necessidades.

Tags do Adobe Experience Platform launch-by-adobe

Assista ao vídeo abaixo para saber mais sobre como mover as opções de implementação do código de DIL do lado do cliente para o encaminhamento do lado do servidor no Experience Platform Launch.

"Na página" ou gerenciador de tags não-Adobe on-the-page-or-non-adobe-tag-manager

Assista ao vídeo abaixo para saber mais sobre como mover as opções de implementação do código de DIL do lado do cliente para o encaminhamento do lado do servidor no AppMeasurement código, residente em um arquivo ou em um sistema de gerenciamento de tags não-Adobe.

Etapa 3: Ativação do encaminhamento (por Report Suite) step-enabling-the-forwarding-per-report-suite

Até agora, neste tutorial, gastamos todo o nosso tempo na alternância do código de DIL do lado do cliente para o encaminhamento do lado do servidor. Isso é bom, porque é a parte mais difícil. Esta seção, embora você queira vê-la como super fácil, é tão importante quanto atualizar o código. Neste vídeo, você verá como virar a chave que permite o encaminhamento real de dados do Analytics para o Audience Manager.

NOTA: Conforme mencionado no vídeo, lembre-se de que levará até 4 horas para que a ativação do encaminhamento seja totalmente implementada no back-end do Experience Cloud.

Tempo timing

Como lembrete, há duas tarefas principais para migrar do DIL do lado do cliente para o encaminhamento do lado do servidor:

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

Mas a questão é, qual você faz primeiro? Isso importa? OK, desculpe, foram duas perguntas. Mas as respostas são… depende, e sim, depende pode matéria. Como isso é vago? Vamos analisar isso. Mas, primeiro, uma pergunta adicional que pode surgir se você for uma grande organização com vários sites: Eu preciso fazer tudo de uma vez? Aquela é um pouco mais fácil. Não. Você pode fazer isso peça por peça.

Um mergulho um pouco mais profundo a-little-deeper-dive

O motivo pelo qual o tempo e o pedido são importantes é por causa do encaminhamento realmente que podem ser resumidas nos seguintes fatos técnicos:

  • Se você tiver o Serviço de ID de Experience Cloud (ECID) implementado e o switch no estado Analytics Admin Console ("o switch") estiver ativado, os dados SERÃO encaminhados do Analytics ao AAM, mesmo que você ainda não tenha atualizado o código.
  • Se você não tiver a ECID implementada, os dados não serão encaminhados, mesmo se o switch estiver ativado e o código de encaminhamento do lado do servidor estiver instalado.
  • O código de encaminhamento do lado do servidor (seja nas tags da Platform ou na página) realmente lida com a resposta e é necessário para concluir a migração.
  • Lembre-se de que o switch de encaminhamento do lado do servidor está habilitado pelo report suite, mas que o código é manipulado pela propriedade nas tags da Platform, ou pelo AppMeasurement se você não usar tags da Platform.

Práticas recomendadas best-practices

Com base nesses detalhes técnicos, veja as recomendações para o momento do que fazer e quando:

Se você AINDA NÃO tiver o ECID implementado if-you-do-not-have-ecid-yet-implemented

  1. Ligue o interruptor Analytics para cada report suite que você ativará para o encaminhamento pelo lado do servidor.

    1. O encaminhamento ainda não começa porque você não tem uma ECID.
  2. Por site, atualize seu código do DIL do lado do cliente para o encaminhamento do lado do servidor (pode estar nas tags da Platform ) ou na página, conforme discutido em outra seção acima).

    1. O encaminhamento agora flui (já que você adicionou a ECID), e você também deve receber uma resposta JSON adequada aos Analytics (consulte a seção Validação e solução de problemas abaixo para obter mais detalhes).

Se você tiver a ECID implementada if-you-do-have-ecid-implemented

  1. Prepare e planeje para estar pronto para atualizar seu código do DIL para o encaminhamento pelo lado do servidor PER report suite que você ativará para o encaminhamento pelo lado do servidor:

    1. Ligue o interruptor Analytics para ativar o encaminhamento pelo lado do servidor.

      1. O encaminhamento SERÁ iniciado porque você tem a ECID ativada.
    2. Assim que possível, atualize seu código do DIL do lado do cliente para o encaminhamento de lado único (isso pode estar nas tags da Platform ou na página, conforme discutido em outra seção acima).

      1. Você deve receber uma resposta JSON adequada aos seus Analytics (consulte a Validação e solução de problemas abaixo para obter mais detalhes).
NOTE
É importante fazer essas duas etapas o mais próximo possível uma da outra, pois, entre as etapas 1 e 2 acima, você terá a duplicação de dados que entram no AAM. Em outras palavras, o encaminhamento por um único lado terá começado a enviar dados do Analytics para AAM, e como o código DIL ainda está na página, também haverá um hit indo diretamente da página para o AAM, duplicando assim os dados. Assim que você atualizar o código do DIL para o encaminhamento do lado do servidor, isso será atenuado.
NOTE
Se você preferir ter uma pequena discrepância nos dados, em vez de uma pequena duplicação de dados, é possível alternar a ordem das etapas 1 e 2 acima. Mover o código do encaminhamento do lado do servidor para o DIL interromperia o fluxo de dados no AAM até que você pudesse virar a chave para ativar o encaminhamento do lado do servidor para o report suite. Normalmente, os clientes prefeririam ter uma pequena duplicação de dados, em vez de perder a oportunidade de colocar os visitantes em características e segments.

Tempo de migração quando você tem muitos sites e report suites migration-timing-when-you-have-many-sites-and-report-suites

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

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

No entanto, isso pode ser complicado com base em alguns cenários possíveis:

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

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

  • Reserve algum tempo para criar uma estratégia de migração para o encaminhamento pelo lado do servidor, com base nas explicações acima
  • Com base no fato de que uma única propriedade nas tags da Platform (ou uma única AppMeasurement arquivo) normalmente mapeia para 1 ou 2 report suites, você provavelmente poderá fazer um plano que funcione nesses grupos distintos um por um, atualizando sua empresa para o encaminhamento pelo lado do servidor
  • Se você estiver trabalhando com a Adobe Consulting, converse com eles sobre o seu plano de migração, para que possam ajudar conforme necessário

Validação e solução de problemas validation-and-troubleshooting

A forma principal de validar que o encaminhamento pelo lado do servidor está em execução é observar a resposta a qualquer uma das ocorrências do Adobe Analytics que vierem do aplicativo.

Se você não estiver fazendo o encaminhamento de dados pelo lado do servidor do Analytics para o Audience Manager, então não há realmente nenhuma resposta para o Analytics sinal (fora de um pixel com dimensões 2x2). No entanto, se estiver fazendo o encaminhamento pelo lado do servidor, há itens que você pode verificar no Analytics solicitação e resposta que informam que Analytics O está se comunicando corretamente com o Audience Manager, encaminhando a ocorrência e obtendo uma resposta.

WARNING
Cuidado com o falso “Sucesso”. Se houver uma resposta e tudo parecer estar funcionando, verifique se você tem a stuff objeto na resposta. Caso não tenha, você poderá ver uma mensagem que diz "status":"SUCCESS". Por mais louco que pareça, isso prova que NÃO está funcionando corretamente.
Se vir isso, significa que você concluiu a atualização de código nas tags da Platform ou AppMeasurement, mas que o encaminhamento no Analytics Admin Console ainda não foi concluído. Nesse caso, é necessário verificar se o encaminhamento pelo lado do servidor foi ativado na variável Analytics Admin Console para seu report suite. Se tiver ativado e ainda não tiver passado quatro horas, aguarde, pois pode demorar para fazer todas as alterações necessárias no back-end.

falso sucesso

Para obter mais informações sobre o encaminhamento pelo lado do servidor, consulte o documentação.

recommendation-more-help
468cbaa0-07ce-4354-9a38-4f23b645a466