Como implementar o GA4: eventos, conversões e erros

De todas as auditorias de analytics que fizemos, ainda não encontramos uma instalação de GA4 perfeita. Nem uma. O habitual é encontrar eventos duplicados que inflam as métricas, um consent mode mal configurado que descarta metade dos dados e conversões sem definir — com o que as campanhas de paid otimizam às cegas.

E o problema é sério: todo o growth marketing se apoia nos dados. Se o tracking está quebrado, cada teste A/B, cada decisão de orçamento e cada dashboard construído em cima está contaminado. Neste guia explicamos como implementar o GA4 bem: o modelo de eventos, o que medir, como montá-lo com o Google Tag Manager e os erros que vemos se repetir em quase todas as contas.

Por que a maioria das instalações de GA4 está quebrada

Três causas explicam 90% dos desastres que auditamos:

1. Dados duplicados. A combinação clássica: o snippet do gtag.js colado no template e o GA4 disparando também a partir do Google Tag Manager. Resultado: dois page_view por página, conversões em dobro e taxas que não batem com o negócio. Também acontece com plugins de CMS que “já incluem analytics” convivendo com a tag manual.
2. Consent mode mal implementado (ou ausente). Desde março de 2024, o consent mode v2 é obrigatório para usar audiências e remarketing do Google no EEE. Vemos implementações erradas constantemente: o banner de cookies bloqueia o GA4 por completo (perda total dos dados de quem recusa), ou o contrário, dispara tudo sem esperar o consentimento (problema legal).
3. Conversões sem definir. O GA4 não sabe o que é importante para o seu negócio. Se ninguém marca eventos como conversão (key events), o Google Ads otimiza para cliques, os relatórios não respondem perguntas de negócio e “ter analytics” fica reduzido a ter um contador de visitas.

A boa notícia: nada disso é difícil de consertar. O difícil é detectar, porque um tracking quebrado produz números tão bonitos quanto um saudável.

O modelo de eventos do GA4: esqueça as categorias do Universal Analytics

Se você vem do Universal Analytics, o primeiro passo é desaprender. O UA tinha tipos de hit distintos (pageviews, eventos com categoria/ação/rótulo, transações). No GA4 tudo é um evento com parâmetros:

evento: sign_up
parâmetros: { method: "google", plan: "free" }

Isso tem duas implicações práticas:

• Não coloque a informação no nome do evento. click_botao_verde_home é um antipadrão; o correto é um evento genérico (cta_click) com parâmetros (location: "home", cta_text: "..."). Menos eventos, mais parâmetros.
• Os parâmetros personalizados não aparecem nos relatórios por mágica. É preciso registrá-los como dimensões ou métricas personalizadas na propriedade. É o esquecimento mais comum: eventos ricos em parâmetros que ninguém consegue consultar.

O GA4 ainda traz eventos automáticos (page_view, session_start) e de medição aprimorada (scroll, click de saída, file_download, video_start…). Revise-os antes de criar os seus: não meça manualmente o que já vem de fábrica.

O que medir: um plano de mensuração ligado ao funil

O erro de base normalmente não é técnico, mas de design: medir sem plano. Nosso ponto de partida é sempre o mesmo: um evento bem definido por cada etapa do funil AARRR.

O plano de mensuração é um documento (uma planilha basta) com: nome do evento, quando dispara, parâmetros, quem o consome e para qual decisão. Se um evento não tem resposta para “qual decisão ele alimenta?”, não é implementado. Dez eventos documentados valem mais que cem improvisados.

Implementação com Google Tag Manager

Nossa recomendação padrão: um único ponto de entrada (GTM) e um dataLayer bem populado. Nada de gtag.js hardcoded convivendo com o container.

• O dataLayer é o contrato entre desenvolvimento e marketing. A equipe de produto faz push dos eventos com seus parâmetros (dataLayer.push({event: "sign_up", method: "google"})) e o GTM os traduz em tags. Assim o tracking sobrevive a redesigns: não depende de classes CSS nem de seletores frágeis.
• Convenções de nomes desde o primeiro dia: snake_case sempre (o GA4 diferencia maiúsculas: sign_up e Sign_Up são dois eventos distintos), verbos em inglês consistentes com os eventos recomendados do Google (sign_up, purchase, generate_lead) e prefixos para o que é custom, se ajudar (sw_ para eventos próprios). Documentado no plano de mensuração.
• Ambientes e versões: o GTM permite testar em preview, publicar com versões e fazer rollback. Use isso. Uma mudança de tracking sem teste é um incidente de dados esperando uma data.

Conversões e audiências

Com os eventos fluindo, faltam dois passos que quase ninguém dá:

1. Marque como conversão (key event) apenas o que é negócio: lead, cadastro, compra, demo solicitada. Marcar scroll ou page_view como conversão destrói a utilidade do dado e confunde o Google Ads. Entre 3 e 5 conversões bem escolhidas é o normal.
2. Construa audiências sobre comportamento: usuários que ativaram mas não pagaram, carrinhos abandonados, visitantes de pricing sem conversão. Exportadas para o Google Ads, elas convertem seu analytics em músculo de remarketing e similar audiences. É a parte do GA4 que paga a conta.

Consent mode v2 e a perda de dados

Com o consent mode v2 bem implementado, quando o usuário recusa cookies o GA4 envia pings anônimos (sem cookies) em vez de não enviar nada. Com eles, o Google aplica modelagem de comportamento e conversões: estima estatisticamente os dados de quem recusou, a partir dos padrões de quem aceitou.

O que é preciso assumir: você vai perder granularidade de qualquer jeito. Com taxas de recusa de 20-40% habituais na Europa, seus números absolutos são parcialmente modelados. As implicações práticas:

• Configure o consent mode no modo avançado (pings anônimos) e não no básico (bloqueio total) se quiser que a modelagem funcione.
• Trate o GA4 como ferramenta direcional: tendências e comparativos confiáveis, números absolutos aproximados.
• A fonte da verdade do negócio (vendas, leads) deve ser o seu backend ou CRM, nunca a ferramenta de analytics.

Quando dar o próximo passo: server-side e analytics de produto

O GA4 client-side bem montado cobre muito, mas tem teto:

• Tracking server-side (GTM Server-Side): faz sentido quando os adblockers e o ITP comem uma parte relevante dos dados e o investimento em paid justifica recuperá-la, ou quando você quer enriquecer eventos com dados de backend e controlar o que é compartilhado com cada plataforma. É infraestrutura: exige engenharia, não apenas configuração.
• Ferramenta de analytics de produto (PostHog, Mixpanel, Amplitude): quando as perguntas deixam de ser de marketing (“qual canal converte?”) e passam a ser de produto (“o que fazem os usuários que retêm e não fazem os que vão embora?”). Coortes flexíveis, funis ad hoc, session replay e feature flags — terreno onde o GA4 não chega.

A combinação habitual em empresas com produto digital: GA4 para marketing e campanhas + uma ferramenta de produto para comportamento. Se você está nesse ponto, é exatamente o que montamos no nosso serviço de data & analytics.

Checklist de auditoria GA4

Antes de dar o tracking por bom:

• Um único ponto de disparo (GTM ou gtag, não ambos) e sem page_view duplicados no DebugView
• Plano de mensuração documentado: eventos, parâmetros, responsável e decisão que alimentam
• Convenção de nomes consistente (snake_case, eventos recomendados do Google onde existirem)
• Parâmetros personalizados registrados como dimensões/métricas personalizadas
• Conversões (key events) definidas: apenas eventos de negócio, entre 3 e 5
• Consent mode v2 em modo avançado, verificado com o banner aceitando e recusando
• Retenção de dados aumentada de 2 para 14 meses (vem em 2 por padrão)
• Tráfego interno e de desenvolvimento filtrado
• Vínculo com Google Ads e Search Console ativo
• Verificação no DebugView e Realtime após cada publicação do GTM

Erros comuns (e como evitá-los)

Conclusão

Implementar o GA4 bem não é colar um snippet: é desenhar um plano de mensuração ligado ao funil, executá-lo com disciplina de engenharia (dataLayer, convenções, versões, verificação) e assumir honestamente os limites do dado com consentimento. A diferença entre fazer bem e fazer mais ou menos não aparece no site — aparece três meses depois, quando as decisões tomadas com esses dados funcionam ou não.

E se algo aprendemos auditando contas: é muito mais barato montar o tracking bem uma vez do que decidir seis meses sobre dados quebrados.

Suspeita que o seu GA4 está medindo errado? Nós auditamos e deixamos afinado →