Aprenda algumas práticas recomendadas para implementação do Adobe Analytics em aplicativos de página única (SPAs). Isso inclui o uso do Experience Platform Tags, que é o método de implementação recomendado.
OBSERVAÇÕES INICIAIS:
NOTA: este é um diagrama simplificado de como as páginas do SPA são tratadas em uma implementação do Adobe Analytics usando o Experience Platform Tags. As seções a seguir identificam etapas e problemas a serem considerados.
Quando o novo conteúdo for carregado ou quando uma ação ocorrer em uma página do SPA, atualize a camada de dados primeiro. Isto tem de acontecer antes de um evento personalizado que aciona uma regra ser executado no Experience Platform Tags. Isso garante que os valores corretos da camada de dados sejam enviados às tags e, em seguida, para o Adobe Analytics.
Veja a seguir um exemplo de camada de dados. Qualquer um desses elementos pode ser alterado com base na exibição inicial ou na alteração subsequente da exibição, considerando uma ação realizada na página do SPA. Por exemplo, em uma alteração de exibição completa ou majoritária, é um requisito comum transmitir um valor “pageName” exclusivo para diferenciar as exibições nos relatórios do Adobe Analytics.
<script>
digitalData = {
pageInstanceID: "Launch Demo Site",
page:{
pageInfo:{
pageID: '2745374',
pageName: 'acs demo - product listing page'
},
attributes:{
project: "Experience Platform Launch Project"
}
},
user : [ {
"profile" : [ {
"attributes" : {
"gender" : "male",
"age" : "35"
}
} ]
}],
libraries : {
adobe : {
launch : {
state : 0, // 0 = not loaded , 1 = loaded
domain : "assets.adobedtm.com"
}
}
}
};
</script>
Quando um novo conteúdo é carregado ou quando uma ação ocorre na página do SPA, as tags da Experience Platform precisam ser orientadas a executar uma regra que envia dados para o Analytics. Há algumas abordagens para isso: Regras de chamada direta ou Eventos personalizados.
Exemplos: Neste documento de ajuda, há links para exemplos de sites de SPA que implementam o Analytics e outras soluções da Experience Cloud. Nesses exemplos, os seguintes eventos personalizados foram usados:
Consulte as páginas e os documentos referenciados acima para obter mais informações sobre como e quando esses eventos são acionados. Não é necessário usar os mesmos nomes de evento na implementação. O caso de uso funcional do método usado é essencial para entender a prática recomendada para cada um. O vídeo a seguir demonstra um exemplo de página de SPA e um código de amostra no Experience Platform Tags que acompanha os eventos personalizados.
Um conceito importante para compreender o Analytics ao trabalhar com um SPA é a diferença entre s.t()
e s.tl()
. Seu código aciona um desses métodos no Experience Platform Tags para enviar dados ao Analytics.
s.t() - O “t” significa “track” e representa uma exibição de página Se a visualização for alterada o suficiente para você a considerar uma nova “página”, use esta chamada. Defina um valor exclusivo para a variável s.pageName e use s.t()
para enviar os dados ao Analytics.
s.tl() - O “tl” significa “track link” e representa um clique em um link ou uma pequena alteração de conteúdo. Se a mudança de exibição for mínima, use s.tl()
para transmitir um valor exclusivo sobre a interação para o Analytics. Essa variável transmitida não é s.pageName, pois isso é ignorado no Analytics quando chamadas s.tl()
são recebidas.
DICA: Como diretriz geral, se a tela for alterada em mais de 50%, use a chamada de exibição de página s.t()
. Caso contrário, use s.tl()
. No entanto, tome sua própria decisão ao considerar quais ações constituem uma nova “página” e como elas devem ser apresentadas nos relatórios do Adobe Analytics.
O vídeo a seguir mostra onde e como acionar s.t()
ou s.tl()
em tags.
Envie os dados corretos para o Analytics na hora certa. Em um ambiente de SPA, um valor armazenado em uma variável Analytics persiste e é reenviado para o Analytics, possivelmente quando você não o desejar mais. Existe uma função na extensão Analytics Tags para limpar as variáveis, garantindo que a próxima chamada não envie dados erroneamente para o Analytics.
O diagrama acima mostra as variáveis limpas após o envio dos dados. Na realidade, isso pode acontecer antes OU depois da chamada, no entanto, seja consistente em suas regras do Experience Platform Tags para realizar uma implementação mais limpa. Se você limpar variáveis antes de executar s.t()
, defina as novas variáveis imediatamente após a chamada e, em seguida, envie os novos dados para o Analytics.
OBSERVAÇÃO: Limpar variáveis nem sempre é necessário ao executar s.tl()
. Esta chamada requer o uso da variável linkTrackVars para instruir o Analytics sobre quais variáveis devem ser definidas. Isso acontece automaticamente no Experience Platform Tags por meio de configuração. Isso impede que variáveis errantes sejam configuradas em contraste com o comportamento com chamadas s.t()
em um ambiente de SPA. Para garantir uma implementação mais limpa e confiável, é provavelmente mais fácil usar a função de limpar variáveis para ambas as chamadas em um ambiente de SPA.
O vídeo a seguir mostra onde e como limpar as variáveis no Tags.
Na extensão Tags Analytics, há dois lugares onde o código personalizado pode ser inserido: as seções “Gerenciamento de biblioteca” e “Configurar rastreador usando código personalizado”.
Qualquer um desses locais executa o código contido neles assim que a página inicial carrega sua página de SPA. Se o código deve ser executado em uma exibição ou alteração de ação, implemente-o na regra apropriada (por exemplo, a regra “carregamento de página: final da visualização do evento”), para garantir que o código seja executado sempre que a regra for executada. Ao criar essa ação na regra, defina a Extensão = Principal e o Tipo de ação = Código personalizado.
Alguns sites são compostos de uma combinação de páginas tradicionais e de SPA. Nesta instância, use uma estratégia que funcione para ambos os tipos de página. Ao configurar seus eventos personalizados no site e acionar as regras em no Experience Platform Tags, certifique-se de que as ocorrências duplas não sejam enviadas para o Analytics com base em alterações de hash e assim por diante. Nesse caso, suprima uma das exibições de página para impedir que dados duplicados sejam enviados ao Adobe Analytics.
Se você decidir separar a funcionalidade em uma única regra para ter mais controle, lembre-se de documentar que você fez isso. Se você alterar uma regra, efetue a mesma alteração na outra regra.
Ao integrar com o Target usando o A4T, confirme se as solicitações do Target e do Analytics enviadas na mesma visualização ou ação passam o mesmo valor do parâmetro SDID. Isso garante que seus dados sejam sincronizados corretamente no back-end.
Para exibir essas ocorrências, use um depurador ou ferramenta de monitoramento de pacotes. A Adobe fornece o Experience Platform Debugger para essa finalidade. Essa é uma extensão do Chrome que pode ser baixada aqui. O Target deve ser executado primeiro na página. Isso também pode ser verificado no depurador.