GA4 — Cuidados a se tomar durante a implementação e validação
Continuando nossa série sobre GA4, neste artigo vamos abordar os cuidados necessários para implementar e validar corretamente a coleta de dados, tanto em apps quanto em sites web.
Conforme falamos no último post, o GA4 disponibiliza o Enhanced Measurement (traduzido como Métrica otimizada), que coleta alguns eventos automaticamente. Mas, para maior proveito da nova propriedade, podemos implementar eventos customizados. Para isso, é preciso ter atenção com os novos limites relacionados ao envio, análise e armazenamento dos eventos.
App vs Web
Iniciar a implementação em aplicativos ou em sites requer abordagens distintas. Para aplicativos é necessária a instalação do SDK do Firebase, que vem com o Firebase Analytics, e a coleta precisa ser implementada diretamente no código-fonte da aplicação. Além disso, em apps, o Google Tag Manager passa a ser opcional para coletar dados — os eventos do Firebase Analytics são os mesmos do GA4. Mesmo que a instalação do GTM seja opcional, a recomendação se faz necessária, pois ele pode ser utilizado para implementação de pixels de mídia e intercepção de eventos, seja para manipulação de dados ou para bloqueio de eventos. Essa instalação mostra-se muito útil quando é identificada a coleta de uma PII (informação pessoalmente identificável), por exemplo, uma infração da LGPD. Dessa forma os times de marketing conseguem atuar sem a necessidade de uma nova release para o aplicativo.
Já em sites, a instalação pode ser feita via código de acompanhamento (gtag.js) ou via Google Tag Manager, opção mais comum. A tag de configuração do GA4 é bem simples, precisando somente do Measurement ID. Se a propriedade tiver o Enhanced Measurement ativo, já irá coletar uma série de interações. A configuração do envio de eventos customizados é semelhante à do GAU.
Eventos coletados automaticamente
A lista completa de eventos pode ser encontrada na documentação oficial. Aqui destacamos alguns que são importantes para análises iniciais e que diferem entre app e web.
* Em web, os eventos de visualização de conteúdo coletam a url da página e o nome da activity da tela no app. Ambos dados podem ser personalizados, mas precisam de configurações adicionais.
** Na versão web, o evento de busca é coletado automaticamente quando a página tem a parametrização de busca na URL. Porém, para trazer informações sobre os itens exibidos na busca, é preciso fazer configurações adicionais. No caso dos aplicativos, o evento precisa ser implementado manualmente.
Regras e limites de dados
Para entender os limites, precisamos relembrar a diferença entre evento, parâmetro de evento e propriedades do usuário. Resumindo:
- Um evento contém nome e um ou mais parâmetros de evento;
- Cada parâmetro de evento contém nome e valor;
- As propriedades de usuário estão fora do escopo do evento e definem informações relacionadas ao usuário, contendo também nome e valor.
Cada uma dessas informações está sujeita a um limite diferente.
A principal mudança nos limites entre GA4 e GAU se dá nos valores dos parâmetros de eventos. O tamanho máximo do dado que pode ser coletado por parâmetro no GA4 é de 100 caracteres, isso é equivalente a dizer que uma dimensão não irá receber mais do que 100 letras. Diferentemente do seu antecessor que tem um limite de 150 bytes e suporta até 150 letras, possuindo um limite máximo do payload do hit de 8192 bytes; caso seja excedido o hit é descartado.
Além disso, os nomes dos eventos estão sujeitos a algumas regras. Existe uma série de nomes reservados e que são recomendados para casos de uso específico, como, por exemplo, criação de conta, login e compartilhamento de conteúdo. Além dos eventos de ecommerce e alguns exclusivos para coleta de jogos. Para mais detalhes sobre os eventos recomendados, consulte a documentação oficial.
Todos os limites e regras que devem ser respeitados estão disponíveis nessa documentação.
Para uma visualização eficiente de informações em coletas cross (entre plataformas) com dados homogêneos, respeitar os limites e manter os dados normalizados são chaves para o sucesso.
Armazenamento de dados
No artigo anterior, foi mencionada as mudanças no armazenamento dos dados coletados. Antes, existia uma separação física entre os dados do GAU e Firebase Analytics, ou seja, as métricas entre as ferramentas não eram equivalentes. Agora, essa arquitetura deixa de existir e o GA4 passa a possuir uma única base de dados, tornando-se um SSOT (Single source of truth) para os dados de digital analytics.
Solicitações de exclusão de dados
Como foi abordado anteriormente, o Google não aceita a coleta de dados PII, diante disso é importante mencionar que, nessa nova versão, o formulário de data deletion request (Solicitações de exclusão de dados) foi melhorada. Com a opção de informar um valor de match customizado, existem opções para excluir apenas determinados parâmetros de eventos específicos. Para conhecer mais sobre esse recurso, acesse a documentação oficial aqui.
Validação da coleta
Para a validação da coleta, o GA4 conta com uma funcionalidade nativa que é o debug view. Com ele, é possível validar os dados em tempo real de app e web. Esse recurso possui um nível de detalhamento mais técnico do que o relatório real-time do GAU, assim sendo, os dados de validação do debug view não são consolidados. Desse modo, não há o risco de sujar os relatórios com testes de desenvolvimento. Porém, para isso é necessário habilitar o modo de debug.
Apesar de todos os benefícios do debug view, existe uma limitação que só considera os dados que de fato chegam aos servidores Google. Então, caso haja algum problema que impeça a saída do hit da rede local do usuário, a validação se torna ineficiente.
Para contornar esse problema, existem diversas estratégias de validações, desde analisar as requisições http e logs, até ferramentas dedicadas de validação que exigem maior conhecimento técnico.
No ambiente web, existem diversas extensões para validações amigáveis dos disparos, como o Tag Assistant Legacy e o Roger Watcher, sendo a segunda, uma solução open source desenvolvida pela DP6. Já para as validações em aplicativos, não existem ferramentas amigáveis e de fácil utilização para homologar. Internamente, na DP6, é utilizada algumas automatizações para analisar os logs gerados pelos aplicativos, mas, para um acompanhamento em tempo real, é necessário usar um proxy para a interceptação dos hits que são enviados para o Google.
Sugestões para validações dos hits
- Web Roger Watcher
- Android e iOS console log da IDE de desenvolvimento
- Android e iOS proxy Fiddler
Conclusão
Como podemos ver, é preciso ter muitos cuidados para implementar e validar a coleta de GA4 (a quantidade de links de documentações oficiais deixa isso bem claro). Isso mostra que o planejamento da coleta se faz muito necessário, agora considerando também todas as novas regras e limites. Sobre esse assunto, recomendamos a leitura dos artigos:
- A importância do planejamento em um projeto de coleta de dados
- Boas práticas para a implementação de Coleta
Acompanhe o blog da DP6 para ficar por dentro das melhores práticas para arquiteturas de coleta de dados e monitoramento.
Perfil do autor: Joaquim Neto|Formado em Ciência da Computação na USJT, atua como engenheiro de dados na DP6 e possui 8 anos de experiência na criação de arquitetura de software.
Carlos Magalhães | Técnico em Processamento de Dados e estudante de Microeletrônica. Atualmente desenvolvedor e Engenheiro de Dados na DP6, trabalha com coleta e estruturação de dados desde 2019.
Outros canais da DP6
Site: https://www.dp6.com.br
Linkedin: https://www.linkedin.com/company/dp6
Instagram: @insta_dp6
Facebook: https://www.facebook.com/dp6.com.br
Podcast: https://anchor.fm/podcastdp6
Youtube: https://www.youtube.com/c/DP6br/videos
Projetos Open Surce: https://dp6.github.io
