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

Neste documento, descreveremos várias práticas recomendadas que 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.

NOTAS INICIAIS:

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

Diagrama simples de como trabalhar com SPA em Experience Platform Launch

spa para analytics no launch

OBSERVAÇÃO: conforme declarado, 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 quaisquer problemas que você deve considerar ou agir com cuidado.

Configuração da 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 acionado e dispare regras em Experience Platform Launch, para que 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 alterados na alteração da exibição ou na ação em seu SPA. Por exemplo, em uma alteração de tela cheia/maioria, seria comum alterar um elemento "pageName", para que o novo pudesse ser capturado em 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>

Definir eventos personalizados e escuta em Experience Platform Launch

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

  • Regras de chamada direta: no Experience Platform Launch, você pode configurar uma regra de chamada direta que é executada quando é chamada diretamente da página. Se o carregamento da página ou a ação no site for muito simples, ou se for exclusiva e puder executar um conjunto específico de instruções todas as vezes (defina eVar4 como X e acione event2 sempre), você poderá usar uma chamada direta rule. Consulte a documentação Experience Platform Launch sobre como criar chamada direta regras.
  • Eventos personalizados: Para obter mais funcionalidades e para a capacidade de anexar dinamicamente uma carga com valores diferentes, você deve definir eventos JavaScript personalizados e ouvi-los em 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ê precise dessa funcionalidade e, portanto, essa opção é considerada a prática recomendada. No entanto, cada função no 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 de SPA que foram implementados Analytics (e outras soluções do Experience Cloud), bem como documentos que descrevem o que foi implementado. Nesses SPA exemplos, os seguintes eventos personalizados foram usados:

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

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

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

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

  • s.t() - O "t" representa "track" e é uma exibição de página normal. Mesmo que o URL não seja alterado, a exibição muda o suficiente para considerar como uma nova "página"? Em caso positivo, defina a variável s.pageName e use s.t() para enviar a chamada para Analytics

  • s.tl() - O "tl" significa "rastrear 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 cheia. Se a alteração na sua página for pequena, para que você não a considere uma "página" totalmente nova, use s.tl() e não se preocupe em definir a variável s.pageName , pois Analytics a ignorará.

DICA: Algumas pessoas usam uma diretriz geral de que, se a tela mudar mais de 50%, ela deverá ser considerada uma exibição de página e usada s.t(). Se for menor que 50% de alteração na tela, use s.tl(). No entanto, depende totalmente de você e do que você considera uma nova "página" e como você gostaria de rastrear seu site no Adobe Analytics.

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

Limpando variáveis

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

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

OBSERVAÇÃO: a limpeza de variáveis nem sempre é necessária durante a execução s.tl(), pois s.tl() requer o uso da linkTrackVars variável ao lado dela de cada vez para informar Analytics quais variáveis serão definidas (adicionadas automaticamente nos bastidores em Experience Platform Launch). Isso significa que as variáveis errantes geralmente não aparecem ao usar s.tl(), mas é muito recomendado usar s.t() em um ambiente de SPA. Dito isso, gostaria de recomendar como prática recomendada o uso da função Limpar variáveis para s.t() e s.tl() em um ambiente SPA, apenas para garantir a coleta de dados de qualidade.

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

Considerações adicionais

Janelas de código personalizado em Experience Platform Launch

Na extensão Launch Analytics, há dois lugares onde você pode inserir o código personalizado: A seção gerenciamento de biblioteca e a seção extra "Configurar rastreador usando código personalizado".

Iniciar janelas de código personalizado do Analytics

É importante saber que qualquer um desses locais realmente só executará o código neles uma vez, quando o carregamento da página inicial ocorrer em sua página de SPA. Se você precisar que o código seja executado em uma alteração de exibição ou em uma ação no site, deverá adicionar uma Ação adicional ao rule apropriado (por exemplo, no "carregamento de página: event-view-end" rule), para que o código seja executado sempre que rule for executado. Ao criar essa Ação no rule, defina Extension = Core e Action Type = Custom Code.

SPA "Híbrido"/Sites Regulares

Alguns sites são uma combinação de páginas "regulares" 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 seus eventos personalizados no site e acionar as regras em Experience Platform Launch, tenha cuidado para não haver ocorrências duplas entrando em Analytics da página, com base em alterações de hash etc. (se foi assim que você optou por acionar a regra Experience Platform Launch). Nesse caso, será necessário suprimir uma das exibições de página para que ela não forneça dados defeituosos no Adobe Analytics.

Se você decidir dividir a funcionalidade em rules separadas para ter mais controle sobre ela, lembre-se/documente que fez isso, para que todas as alterações em uma rule possam ser feitas em outra rule também, protegendo sua integridade de dados Analytics.

Integração com Target via A4T

Só um rápido chamado aqui. Se estiver integrando com Target usando A4T, verifique se a solicitação Target e a solicitação Analytics na mesma alteração de exibição têm a mesma SDID. Isso garantirá que 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 HERE. Target O deve ser acionado primeiro na página, para que você também possa verificar isso no console ou no depurador do JavaScript.

Recursos adicionais

Nesta página