Durante três meses, a equipe de marketing digital de um e-commerce de médio porte celebrou um aumento de 340% nos eventos de "adicionar ao carrinho" registrados no Google Analytics 4. O board aprovou orçamento extra para SEO, o time de produto priorizou categorias baseadas nesses sinais - até que alguém cruzou os números com o CRM e descobriu que as vendas reais haviam crescido apenas 12%. A auditoria revelou que cada clique no botão "Adicionar" disparava o mesmo evento quatro vezes por causa de uma tag mal configurada no Google Tag Manager. O erro? Ninguém entendia de fato o que é contagem de eventos no Google Analytics nem como validá-la.
Esse cenário se repete com frequência porque a migração do Universal Analytics para o GA4 trouxe uma mudança profunda na arquitetura de rastreamento. O modelo baseado em pageviews deu lugar a um modelo centrado em eventos, onde praticamente toda interação vira um registro independente. Sem compreender a lógica por trás da contagem de eventos - e sem mecanismos de validação - empresas tomam decisões estratégicas sobre dados inflados, duplicados ou simplesmente fantasmas.
Este artigo desmonta a mecânica da contagem de eventos no GA4, mostra onde os erros mais comuns acontecem e ensina como usar esses dados para decisões reais de SEO e CRO. Se você gerencia analytics e suspeita que seus números não fecham, continue lendo.
O que é contagem de eventos no Google Analytics
No Google Analytics 4, contagem de eventos refere-se ao número total de vezes que um evento específico foi registrado dentro de um período selecionado. Diferentemente do Universal Analytics - onde pageviews, eventos e transações eram categorias separadas de hits -, o GA4 trata tudo como evento: desde o carregamento de uma página (page_view) até um clique em botão, envio de formulário ou rolagem de tela. Cada instância registrada incrementa o contador daquele evento, e essa métrica aparece nos relatórios como "Contagem de eventos" ou event_count.
A contagem de eventos é a base de qualquer análise comportamental no GA4. Quando você navega até Relatórios > Engajamento > Eventos, cada linha mostra o nome de um evento e quantas vezes ele ocorreu. Esses números alimentam desde relatórios de funil até dashboards executivos. Porém, ao contrário de uma métrica simples de pageviews, a contagem de eventos depende de implementação correta de tags, triggers e parâmetros - o que multiplica os pontos de falha.
Entender essa métrica exige distinguir três conceitos que muitas vezes se confundem: evento, hit e sessão. Um evento é qualquer interação rastreada (clique, scroll, visualização de vídeo). Um hit, termo herdado do Universal Analytics, era a unidade mínima de dado enviada ao Google - no GA4, todo hit é tecnicamente um evento. Já uma sessão agrupa múltiplos eventos dentro de uma janela de atividade do usuário. A contagem de eventos não respeita limites de sessão: se um usuário clicar 10 vezes no mesmo botão em 10 visitas diferentes, você verá event_count = 10, independentemente de quantas sessões ocorreram.
Diferença entre evento, hit e sessão
No Universal Analytics, a taxonomia era rígida: havia pageviews, eventos (categoria/ação/label), transações (e-commerce) e hits sociais. Cada tipo de hit tinha seu próprio contador. No GA4, essa hierarquia desapareceu. Tudo vira evento, diferenciado apenas pelo nome do evento e pelos parâmetros anexados. Um page_view é um evento, um click é um evento, um purchase é um evento. Isso simplifica a coleta, mas exige disciplina na nomenclatura e na estrutura de parâmetros.
A confusão entre hit e evento surge porque, tecnicamente, cada evento enviado ao GA4 é um "hit" - um pacote de dados transmitido ao servidor do Google. Porém, no vocabulário do GA4, o termo "hit" foi abandonado em favor de "evento". O que importa para você: cada disparo de tag no Google Tag Manager ou cada chamada gtag('event', ...) gera um incremento na contagem de eventos, desde que a tag esteja configurada para enviar dados ao GA4.
Sessões, por sua vez, são janelas de atividade que agrupam eventos. O GA4 define sessão como um período de engajamento que termina após 30 minutos de inatividade (configurável). A métrica "Sessões" conta quantas dessas janelas ocorreram, enquanto a métrica "Contagem de eventos" soma todos os eventos disparados, independentemente de quantas sessões os geraram. Isso significa que a taxa de engajamento e outras métricas baseadas em sessão não têm relação direta com a contagem bruta de eventos - um erro comum em análises é comparar "eventos por sessão" sem perceber que disparos duplicados inflam o numerador.
Como o GA4 registra eventos em comparação ao Universal Analytics
No Universal Analytics, você enviava um evento manualmente via ga('send', 'event', 'categoria', 'ação', 'label'). Cada chamada criava um hit de evento, e você visualizava a contagem somada na interface. Eventos não disparavam automaticamente - exceto se você habilitasse o Enhanced Link Attribution ou usasse plugins específicos. No GA4, a filosofia é oposta: o enhanced measurement (medição aprimorada) rastreia automaticamente scroll, cliques em links externos, buscas internas, downloads de arquivo, visualizações de vídeo e engajamento com formulários, sem necessidade de código adicional.
Essa automação acelera a implementação inicial, mas introduz ruído se você não auditar quais eventos automáticos estão ativos. Por exemplo, o evento file_download dispara toda vez que alguém clica em um link para .pdf, .xlsx, .docx - mas se seu site disponibiliza PDFs técnicos que usuários clicam repetidamente para conferir especificações, a contagem de file_download não reflete downloads únicos, e sim cliques totais. No Universal Analytics, você teria que instrumentar isso manualmente e teria controle fino; no GA4, o evento já existe, e cabe a você decidir se deve desativá-lo, renomeá-lo ou criar um evento personalizado mais específico.
Outra diferença crítica: o GA4 introduziu o conceito de event_count como métrica explícita, ao lado de event_count_per_user (quantos eventos únicos cada usuário disparou). Essas métricas aparecem em explorações personalizadas e no BigQuery export, mas não estão sempre visíveis nos relatórios padrão - o que leva analistas a confiar cegamente nos totais de eventos sem cruzar com a contagem por usuário. No Universal Analytics, você tinha "Total de eventos" e "Eventos únicos"; no GA4, a métrica "Eventos únicos" não existe mais por padrão, embora você possa construí-la via exploração com a dimensão user_pseudo_id.
Como funciona a lógica de contagem de eventos
Quando o GA4 recebe um evento, ele incrementa o contador daquele nome de evento no banco de dados da propriedade. Internamente, cada evento carrega um carimbo de data/hora, um identificador de usuário (ou pseudônimo de cliente), a origem (web, app, servidor), e um conjunto de parâmetros de evento - campos adicionais como page_location, value, currency, item_id. A contagem agregada que você vê no relatório é a soma de todos os registros com aquele nome, aplicando qualquer filtro de data, segmento ou dimensão secundária que você tenha escolhido.
A lógica parece simples, mas ganha complexidade quando você considera triggers no Google Tag Manager, condições de disparo, e a interação com o dataLayer. Um evento GA4 só é contado se a tag correspondente for disparada e se o JavaScript do gtag.js (ou a biblioteca do Google Tag Manager) conseguir enviar o pacote ao servidor. Bloqueadores de anúncios, consent mode restritivo, timeouts de página e erros de rede podem impedir que eventos sejam registrados - o que gera lacunas na contagem. Por outro lado, triggers mal configurados (por exemplo, um trigger de clique sem filtro de elemento) podem disparar eventos múltiplas vezes por ação, inflando artificialmente a contagem.
No backend, o GA4 processa eventos em near-realtime e os agrupa em tabelas diárias. Se você exporta dados para o BigQuery, cada linha da tabela events_YYYYMMDD representa um evento individual, e a contagem que você vê na interface é um COUNT(*) sobre essas linhas filtradas por event_name. Isso significa que qualquer duplicação na origem - seja por JavaScript duplicado, tags concorrentes ou re-disparo acidental - se propaga integralmente para o relatório.
Eventos automáticos, recomendados e personalizados
O GA4 classifica eventos em três categorias. Eventos automáticos são aqueles coletados pelo enhanced measurement sem código adicional: page_view, scroll, click, file_download, video_start, video_complete, view_search_results. Você ativa ou desativa cada um deles no painel de Configuração > Fluxos de dados. Eventos recomendados seguem nomenclatura padrão do Google para casos de uso comuns - login, sign_up, search, add_to_cart, purchase - e vêm com parâmetros pré-definidos (ex.: search deve incluir search_term). Implementá-los corretamente garante compatibilidade futura com recursos do GA4, como relatórios de e-commerce e integrações com Google Ads.
Eventos personalizados são aqueles que você define com nomes próprios, adequados ao seu negócio: clique_cta_hero, abertura_modal_orcamento, download_whitepaper_seo. Aqui, a contagem depende 100% da sua implementação via Google Tag Manager ou código direto. A armadilha: se você criar um evento personalizado com o mesmo nome de um evento automático (por exemplo, criar uma tag GA4 com nome page_view), o GA4 somará ambos os disparos - o automático e o seu -, duplicando a contagem. Sempre que possível, use nomes distintos ou desative o evento automático correspondente.
A decisão de usar evento recomendado versus personalizado impacta a contagem porque eventos recomendados têm validação de schema: se você enviar um purchase sem o parâmetro currency, o evento será registrado, mas métricas derivadas (como receita) ficarão vazias. Eventos personalizados aceitam qualquer parâmetro, mas você perde relatórios prontos. Para SEO e CRO, a prática recomendada é começar com eventos recomendados sempre que houver match, e criar personalizados apenas para interações muito específicas (ex.: "scroll até seção de depoimentos").
O papel do event_count e event_count_per_user
A métrica event_count é o total bruto de eventos registrados. Se 100 usuários clicaram 5 vezes cada no botão "Saiba mais", event_count será 500. Já event_count_per_user calcula a média de eventos por usuário ativo: nesse exemplo, 5. Essa distinção é crucial para identificar comportamentos anormais. Um event_count alto com event_count_per_user baixo indica ampla distribuição; um event_count alto com event_count_per_user também alto sugere que poucos usuários estão disparando o evento repetidamente - ou que há duplicação técnica.
Essas métricas aparecem em Exploração > Exploração livre, onde você pode arrastar event_name para linhas e event_count ou event_count_per_user para valores. No relatório padrão de Eventos, você vê apenas "Contagem de eventos"; para obter a contagem por usuário, precisa criar uma exploração. Esse passo adicional faz com que muitos analistas ignorem a métrica por-usuário, perdendo sinais de duplicação. Por exemplo, se event_count de form_submit for 1.200 e event_count_per_user for 12, algo está errado - usuários normais não enviam formulários 12 vezes em média.
Outro uso avançado: correlacionar event_count com o hit rate (eventos por sessão). Se você tem 10 mil sessões e 50 mil eventos, seu hit rate médio é 5. Se esse número subir de repente para 20 sem mudança no comportamento do site, há forte indicação de tags duplicadas ou loops de disparo. Monitorar essa proporção ao longo do tempo - em conjunto com event_count_per_user - oferece um sistema de alerta precoce contra distorções nos dados.
Erros comuns que distorcem a contagem de eventos
A qualidade dos dados de eventos no GA4 depende de uma cadeia frágil: JavaScript correto, triggers bem configurados, ausência de concorrência entre tags, e proteção contra bots. Qualquer elo quebrado gera contagens infladas, deflacionadas ou simplesmente erradas. Os erros mais recorrentes surgem em três áreas: disparos duplicados, eventos fantasmas (incluindo tráfego não-humano), e confusão entre métricas de sessão e de evento. Cada um tem assinatura característica nos dados e exige abordagem diferente de correção.
Disparos duplicados são o erro número um. Eles acontecem quando o mesmo evento é enviado mais de uma vez por ação do usuário, seja por tags concorrentes (por exemplo, uma tag GA4 nativa e outra via GTM disparando ambas ao carregar a página), seja por triggers configurados com condições sobrepostas (um trigger de clique genérico e outro específico para o mesmo botão). A assinatura: você vê picos súbitos em event_count sem correspondência em sessões ou usuários. Cruzar event_count com event_count_per_user revela a discrepância - se a contagem por usuário dobrar de um dia para o outro, mas o número de usuários ativos permanecer estável, você tem duplicação.
Disparos duplicados por tag mal configurada
A causa raiz dos disparos duplicados costuma estar no Google Tag Manager. Cenários típicos incluem: (1) criar uma tag GA4 com trigger "All Pages" enquanto o enhanced measurement já rastreia page_view automaticamente - resultado: dois eventos page_view por carregamento; (2) usar um trigger de clique em "All Elements" sem filtrar por classe CSS ou ID, capturando cliques em elementos-pai e elementos-filho simultaneamente; (3) disparar a mesma tag duas vezes por usar triggers baseados em eventos do dataLayer que são enviados mais de uma vez por um script de terceiros (ex.: certas bibliotecas de e-commerce enviam dataLayer.push ao abrir e ao fechar o modal de produto).
A técnica mais eficaz para identificar duplicação é usar o DebugView no GA4. Com o modo de depuração ativo (via extensão Google Tag Assistant ou parâmetro debug_mode=true na URL), você vê cada evento chegando em tempo real. Se clicar uma vez em um botão e ver dois eventos button_click consecutivos no DebugView, a duplicação está confirmada. O próximo passo é abrir o Google Tag Manager Preview, reproduzir a ação e verificar quais tags dispararam. Se ambas as tags mostrarem "Tag Fired", você tem conflito.
Outra armadilha: tags legadas do Universal Analytics coexistindo com tags GA4. Se você ainda tem uma tag analytics.js ativa e adiciona `gtag