A tecnologia avança muito rapidamente e sempre evolui com o objetivo de ser melhor, mais rápida e mais barata. Com as novas tecnologias de SPA (single-page application), o conteúdo das páginas recarrega dinamicamente, sem recarregar toda a página. Porém, este é o princípio básico de funcionamento de ferramentas como Google Analytics e Google Tag Manager.
O que é SPA?
SPA, em tecnologia, é a sigla para Single-Page Application, e define as tecnologia mais recentes de interfaces web onde o conteúdo da página é carregado dinamicamente sempre que você clica em um link, aparentemente recarregando toda a página, porém sem necessariamente fazer isso.
No modelo tradicional, sempre que uma página é carregada, ela "chama" novamente seus arquivos HTML, javaScript e CSS para formar o conteúdo. Já por SPA, estes arquivos são carregados apenas uma vez, e à cada transição de página carrega-se somente os dados referentes ao conteúdo da nova página, tornando-a mais leve e rápida.
Algumas das bibliotecas mais comuns de SPA são React e Angular.
Qual o problema do SPA para Analytics?
Este funcionamento do SPA, de não recarregar completamente a página, é exatamente o padrão de funcionamento das tecnologias de Analytics e tags de mídia em geral, utilizar o evento de carregamento de página para coletar os dados necessários e enviar às ferramentas apropriadas, como o Google Analytics, por exemplo.
Em uma instalação padrão do Google Analytics, a única visualização de página acontecerá na primeira página que o usuário carregar, pois somente nela será "chamado" o arquivo javaScript do GA. Todas as outras páginas navegadas após esta não serão contabilizadas.
Como instalar o Google Analytics em sites SPA?
A documentação do Google sobre Acompanhamento de SPA explica muito superficialmente o que acontece e como o Google Analytics deve ser adaptado para acompanhar todas as páginas e ações do site. Este nem menciona o funcionamento com Google Tag Manager (GTM).
Como a grande maioria dos sites hoje já usam GTM, talvez a referência mais completa seja How to track single page app with Google Tag Manager, da AnalyticsMania. Neste, Julius Fedorovicius ensina, passo-a-passo, como realizar o disparo das tags do GA para o carregamento "virtual" das páginas, tanto utilizando a API de mudança de histórico do navegador, quanto implementando eventos no dataLayer para disparar tags.
Nosso formato preferido para fazer esta instalação é através de eventos personalizados na camada de dados (dataLayer).
Com a ajuda dos desenvolvedores, definimos um evento que "simule" o carregamento normal da página. À cada nova página navegada, que tem seu carregamento dinâmico, é disparado um evento chamado 'virtualPageview', por exemplo.
Utilizamos este evento personalizado da camada de dados como Acionador das tags do Google Analytics, ou qualquer outra tag que deva disparar no carregamento das páginas.
A maioria das plataformas utiliza URL's virtuais no SPA, assim a URL da página é atualizada da mesma forma, não necessitando de ajustes neste ponto, na grande maioria dos casos.
Porém, o maior cuidado com Analytics em SPA é com a perda da origem de tráfego!
Perda da origem de tráfego no Analytics em SPA
O problema que interfaces SPA têm apresentado em Analytics é quando há um carregamento completo da página ao longo da navegação. Até então, enquanto o site carregar a página completa apenas na primeira requisição, e depois só carregar o conteúdo dinâmico, não haverá problema.
Já quando há outro carregamento completo no meio da navegação, há também a atualização de dois atributos de extrema importância para o Google Analytics: document.location e document.referrer.
Location é a URL completa e original da página (não virtual), e Referrer é o domínio através do qual o usuário acessou o site. Estes atributos são primordiais porque é através deles que o Google Analytics atribui a origem de tráfego do usuário.
Quando a interface SPA faz um carregamento completo da página quando não deveria, o browser atualiza as informações de Location e Referrer, e o Google Analytics entende que há uma alteração na origem de tráfego do site. Além de alterar os dados de Origem / Mídia nos relatórios, isso caracteriza uma nova sessão, alterando também métricas como Sessões, Páginas/Sessão, Taxa de Rejeição, Taxa de Conversão, entre outras.
Uma solução aplicável para este problema pode ser vista em detalhes no post sobre Rogue Referral do Simo Ahava.
Problema da plataforma Oracle Cloud Commerce (OCC) em Analytics
A plataforma de e-commerce Oracle Cloud Commerce (OCC), utilizada amplamente no mercado, apresenta exatamente este comportamento, realizando o carregamento completo da página no meio da navegação em SPA.
Diversos clientes no Brasil e no mundo utilizam versões da plataforma OCC e podem estar tomando decisões sobre seu Google Analytics completamente distorcido.
Um teste pode ser realizado muito facilmente: Utilizando o relatório "Tempo Real > Origens de Tráfego" do Google Analytics, acesse seu site simulando parâmetros UTMs de testes (?utm_source=teste&utm_medium=teste&utm_campaign=teste) para poder identificar a sua navegação. Com isso sua Origem e Mídia no Tempo Real serão "teste". Clique nela para que seja feito um filtro.
Filtrando seu acesso, vá ao relatório "Tempo Real > Conteúdo" e navegue amplamente pelo site, avaliando no GA a URL que você está navegando. Enquanto houver um usuário ativo (você) na URL correta que vocês está navegando no site, está tudo ok. Caso você "perca" seu acesso de vista no relatório, sua origem de tráfego mudou. Basta retirar o filtro da Origem "teste" e encontrar a página que você está navegando no relatório para fazer o caminho contrário: filtrar pela página e visualizar a origem de tráfego.
Conclusão sobre SPA e Analytics
SPA é um caminho sem volta, pois traz muitos benefícios para aplicações web. O próprio GA tende a trabalhar melhor com esta tecnologia assim que o novo GA4 for amplamente utilizado. Mas enquanto utilizamos a versão Universal Analytics do GA, o trabalho para a correta mensuração do site em SPA é longo.
Combinando as soluções mencionadas neste post, da Analytics Mania e do Simo Ahava, ainda assim não foi possível eliminar completamente a perda de origem e mídia em sites utilizando a plataforma OCC.
O próprio Simo Ahava, uma das maiores referências do mundo em GTM, não contemplou completamente a solução, pois não contava que haveria recarregamentos completos de página durante a navegação em SPA.
Na Lume, conseguimos chegar a uma solução ainda mais próxima criando um script para armazenar as informações de Location e Referrer em cookies no navegador, e definindo regras de comportamento destes dois atributos para definir quando eles devem ser atualizados no Cookie (quando há realmente uma troca de origem do usuário) e quando o valor original do cookie deve ser preservado (quando há um carregamento de página durante a navegação).
