Utilizar práticas recomendadas ao rastrear aplicativos de página única (SPA) no Adobe Analytics

Neste documento, descreveremos várias práticas recomendadas às quais você deve seguir e estar ciente ao usar o Adobe Analytics para rastrear aplicativos de página única (SPA). Este documento se concentrará no uso do Adobe Experience Platform Launch, que é o método de implementação recomendado.

OBSERVAÇÕES INICIAIS:

  • Os itens abaixo assumirão que você está usando o Experience Platform Launch para implementar no seu site. As considerações ainda existiriam se você não estivesse usando o Experience Platform Launch, mas seria necessário adaptá-las ao seu método de implementação.
  • Todos os SPAs são diferentes, portanto, talvez seja necessário ajustar alguns dos itens a seguir para atender melhor a sua necessidade, mas queremos compartilhar algumas práticas recomendadas com você; itens que precisam ser considerados ao implementar o Adobe Analytics em páginas SPA.

Diagrama simples do trabalho com SPA no Experience Platform Launch

SPA para o Analytics no Launch

OBSERVAÇÃO: Conforme dito, este é um diagrama simplificado de como as páginas de SPA são tratadas em uma implementação do Adobe Analytics usando o Experience Platform Launch. Nas seções a seguir desta página, discutiremos as etapas e problemas os quais você deve considerar ou agir com cuidado.

Definir a camada de dados

Quando o novo conteúdo é carregado em uma página de SPA ou quando uma ação ocorre em uma página de SPA, uma das primeiras coisas que você deve fazer é atualizar a camada de dados. Isso precisa ocorrer ANTES que o evento personalizado seja disparado e acione as regras no Experience Platform Launch, para que o Experience Platform Launch possa coletar os novos valores da camada de dados e enviá-los para o Adobe Analytics.

A seguir, há uma amostra de camada de dados cujos elementos podem ser modificados na alteração de exibição ou na ação em seu SPA. Por exemplo, em uma alteração de tela inteira/maior parte, seria comum alterar um elemento "pageName" para que o novo pudesse ser capturado no Experience Platform Launch e enviado para o 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>

Configuração de eventos personalizados e acompanhamento no Experience Platform Launch

Quando o novo conteúdo for carregado na página ou quando uma ação ocorrer no site, você deverá informar o Experience Platform Launch para que possa executar uma regra e enviar dados para o Analytics. Há algumas maneiras diferentes de fazer isso: Regras de chamada direta ou Eventos personalizados.

  • Regras de chamada direta: no Experience Platform Launch, você pode configurar uma regra de chamada direta que é executada ao ser chamada diretamente da página. Se o carregamento da página ou a ação no site for muito simples, ou se for exclusivo e puder executar um conjunto específico de instruções todas as vezes (definir eVar4 como X e acionar event2 toda vez), você pode usar uma regra de chamada direta. Consulte a documentação do Experience Platform Launch sobre criação de regras de chamada direta.
  • Eventos personalizados: Para obter mais funcionalidades e a capacidade de anexar dinamicamente uma carga com valores diferentes, você deve definir eventos JavaScript personalizados e acompanhá-los no Experience Platform Launch, onde é possível usar a carga para definir variáveis e enviar os dados para o Adobe Analytics. É mais provável que você precisará dessa funcionalidade e, portanto, essa opção é considerada a prática recomendada. No entanto, cada função no seu site pode determinar qual método será mais apropriado. Vamos avançar neste documento supondo que você precisará usar esse método de eventos personalizados.

Exemplos: NESTE documento de ajuda, há links para exemplos de sites SPA que implementaram o Analytics (e outras soluções da Experience Cloud), além de documentos que descrevem o que foi implementado. Nessas amostras de SPA, os seguintes eventos personalizados foram usados:

  • event-view-start: Esse evento deve ser disparado no início da exibição/estado que está sendo carregado.
  • event-view-end: Esse evento deve ser disparado mesmo quando uma alteração de exibição/estado ocorrer e todos os componentes de SPA na página tiverem sido carregados. Normalmente, esse é o evento que aciona uma chamada no Adobe Analytics.
  • event-action-trigger: Esse evento deve ser disparado quando qualquer evento ocorrer na página, exceto o carregamento de exibição/estado. Esse pode ser um evento de clique ou uma alteração de conteúdo menor sem modificar a exibição.

Consulte as páginas/documentos mencionados acima para obter mais informações sobre como/quando eles são disparados. Você não precisa usar esses mesmos nomes de evento, mas a funcionalidade listada aqui é a prática recomendada. O vídeo a seguir mostrará um site de exemplo e de onde no Experience Platform Launch é possível acompanhar os eventos personalizados.

Execução de s.t() ou s.tl() na Regra do Experience Platform Launch

Uma das coisas mais importantes para entender sobre o Analytics ao trabalhar com um SPA é a diferença entre s.t() e s.tl(). Você acionará um desses métodos no Experience Platform Launch para enviar dados para o Analytics, mas você precisa saber quando enviar cada um deles.

  • s.t() - O “t” significa “track” e é uma exibição de página normal. Mesmo que a URL não mude, a exibição muda o suficiente para você considerá-la uma nova “página”? Se sim, defina a variável s.pageName e use s.t() para enviar a chamada para o Analytics

  • s.tl() - O “tl” significa “track link” e é usado normalmente para rastrear cliques ou pequenas alterações de conteúdo na página, em vez de uma alteração de tela inteira. Se a alteração na sua página for pequena, a ponto de você não considerá-la uma “página” totalmente nova, use s.tl() e não se preocupe em definir a variável s.pageName, pois ela será ignorada pelo Analytics.

DICA: Algumas pessoas usam uma diretriz geral de que, se a tela for alterada em mais de 50%, ela deverá ser considerada uma exibição de página, portanto usa-se s.t(). Se a tela for alterada em menos de 50%, usa-se s.tl(). No entanto, depende totalmente de você e do que você considera uma nova “página” e como gostaria de rastrear o seu site no Adobe Analytics.

O vídeo a seguir mostra onde/como acionar o s.t() ou o s.tl() no Experience Platform Launch.

Limpar variáveis

Ao rastrear o seu site com o Adobe Analytics, é claro que você só deseja enviar os dados certos para o Analytics na hora certa. Em um ambiente de SPA, um valor rastreado em uma variável do Analytics pode persistir e ser reenviado para o Analytics, possivelmente quando não o queremos mais. Por isso, há uma função na extensão Analytics Launch para limpar as variáveis, de modo que você possa começar do zero ao executar a próxima solicitação de imagem e enviar os dados para o Analytics.

No diagrama acima, ela está listada no final do processo, limpando as variáveis depois que você envia a ocorrência. Na realidade, isso pode ser feito antes OU depois que a ocorrência é enviada, mas deve ser consistente nas suas regras do Experience Platform Launch, para que você sempre limpe antes ou depois de definir as variáveis e enviá-las. Lembre-se, se você for limpar as variáveis antes de executar o s.t(), certifique-se de limpá-las primeiro, depois definir as novas variáveis e, em seguida, enviar os novos dados para o Analytics.

OBSERVAÇÃO: Limpar as variáveis nem sempre é necessário ao executar o s.tl(), porque s.tl() exige o uso da variável linkTrackVars ao lado dele a cada vez para que o Analytics saiba quais variáveis serão definidas (adicionadas automaticamente em segundo plano no Experience Platform Launch). Isso significa que as variáveis errantes geralmente não aparecem ao usar s.tl(), mas isso é bastante recomendado ao usar s.t() em um ambiente SPA. Dito isto, gostaria de propor como prática recomendada o uso da função Limpar variáveis para ambos s.t() e s.tl() em um ambiente SPA, apenas para garantir uma coleta de dados de qualidade.

O vídeo a seguir mostra onde/como limpar as variáveis no Launch.

Considerações adicionais

Janelas de código personalizado no Experience Platform Launch

Na extensão Launch Analytics há dois lugares onde você pode inserir o código personalizado: na seção de gerenciamento da biblioteca e na seção extra “Configurar o rastreador usando um código personalizado”.

Janelas de código personalizado no Launch Analytics

É importante saber que qualquer um desses locais só executará o código uma vez, quando o carregamento da página inicial ocorrer em sua página de SPA. Se precisar que o código seja executado em uma alteração de visualização ou em uma ação no seu site, insira uma ação adicional na regra apropriada (Por exemplo, na regra "page load: event-view-end"), para que o código seja executado toda vez 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.

“Híbrido” de SPA/Sites normais

Alguns sites são uma combinação de páginas “normais” e páginas de SPA. Nesta instância, será necessário usar uma estratégia que funcione para ambos os tipos de página. Ao configurar os seus eventos personalizados no site e acionar as regras no Experience Platform Launch, tenha cuidado para que não haja ocorrências duplas da página entrando no Analytics, por conta de alterações de hash etc. (se foi assim que você optou por acionar a regra do Experience Platform Launch). Nesse caso, será necessário suprimir uma das exibições de página para que ela não forneça dados corrompidos no Adobe Analytics.

Se você decidir dividir a funcionalidade em regras separadas para ter mais controle sobre ela, certifique-se de lembrar/documentar que você fez isso, para que qualquer alteração em uma regra possa também ser feita à outra regra, protegendo a integridade dos dados do Analytics.

Integração com o Target através do A4T

Só uma rápida observação. Se estiver integrando com o Target usando o A4T, certifique-se de que a solicitação do Target e a solicitação do Analytics na mesma alteração de exibição têm a mesma SDID. Isso garantirá que os seus dados sejam sincronizados corretamente nas soluções.

Para ver as ocorrências, use um programa de depurador ou analisador de pacotes. Você também pode usar o Experience Cloud Debugger, uma extensão do Chrome que pode ser baixada AQUI. O Target deve ser acionado primeiro na página, para que você também possa verificar isso no depurador ou no console do JavaScript.

Recursos adicionais

Nesta página