Google Analytics 2027 · Capítulo 11 de 35 · 11 min
Provar que o evento chegou certo antes de confiar no relatório
Cada evento visto sair do navegador com os parâmetros certos, o tráfego que não é cliente fora da conta e um alerta que dispara antes do fechamento do mês.
Este capítulo faz parte do curso gratuito Google Analytics 2027. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
Com a mesma pessoa reconhecida entre domínios, resta a pergunta que separa medição de suposição: o evento chegou, com os parâmetros certos, no destino certo? Um relatório aceita qualquer coisa que a tag mande. Ele não avisa que purchase saiu sem valor, que add_payment_info nunca disparou no Pix ou que metade das sessões vem de um domínio que a Verde Vivo não conhece.
O custo de descobrir tarde é o mês perdido. Um evento que parou de disparar depois de um deploy só aparece quando alguém estranha a queda, e a essa altura a comparação com o mês anterior já não vale. Spam de hostname infla sessões e derruba a taxa de conversão sem que uma pessoa a mais tenha entrado no site.
Este capítulo monta a rotina de prova da Verde Vivo: quatro ferramentas de inspeção, uma matriz de testes, filtros que tiram da conta o que não é cliente e um critério de alerta que dispara antes do fechamento do mês. A cada deploy, Caio e Marina sabem em minutos se a coleta continua inteira.
Quatro ferramentas mostram o evento em momentos diferentes. Tag Assistant (o depurador do Google que lista as tags carregadas numa página e o que cada uma enviou) mostra a tag no navegador. A prévia do GTM mostra quais acionadores dispararam e com quais variáveis. DebugView (a tela do GA4 que exibe, em segundos, os eventos de um aparelho em modo de depuração) mostra o que a propriedade recebeu. O relatório em tempo real mostra o agregado dos últimos 30 minutos.
Onde cada ferramenta enxerga o evento e o que ela não prova
| Ferramenta | O que mostra | Quando usar | O que não prova |
|---|---|---|---|
| Tag Assistant | Tags carregadas na página e o que a Google tag enviou | Instalação nova, dúvida sobre tag duplicada, diagnóstico de CDN sem first-party | Se a propriedade processou o evento |
| Prévia do GTM | Acionadores disparados, variáveis lidas, tags que não dispararam e por quê | Antes de publicar qualquer versão do contêiner | Parâmetro que a tag transformou depois de sair do GTM |
| DebugView | Eventos do aparelho em depuração, com parâmetros e propriedades do usuário | Validação de evento novo, estado de consentimento, User-ID | Volume: um aparelho não diz nada sobre os outros |
| Tempo real | Eventos e usuários dos últimos 30 minutos, por página e origem | Conferir que um deploy não zerou a coleta | Parâmetro individual; dado processado só depois |
Fonte: Google Tag Manager Help, Troubleshoot tag issues with Tag Diagnostics (answer/14681508); Google Analytics Help
Inspeção de rede é o teste que nenhuma das quatro substitui. A aba de rede do navegador mostra a requisição de coleta como ela saiu: o nome do evento, cada parâmetro com o prefixo que o marca como parâmetro de evento, o estado de consentimento e o identificador da propriedade de destino. Quando o mesmo evento sai duas vezes, ou sai para uma propriedade de teste em produção, é ali que aparece.
A matriz de testes transforma a inspeção em rotina. Nas linhas, os eventos do contrato de dados do capítulo 7; nas colunas, o que varia: estado de consentimento, dispositivo, domínio e superfície. Cada célula recebe o resultado de uma verificação: disparou uma vez, com os parâmetros esperados, no destino certo. Uma célula vazia é uma combinação que ninguém testou, e é lá que o defeito costuma morar.
- Etapa 1 de 5: Prévia do GTM
Percorrer a matriz: cada evento dispara uma vez com as variáveis certas
- Etapa 2 de 5: Rede do navegador
Requisição com nome, parâmetros, consentimento e destino conferidos
- Etapa 3 de 5: DebugView
A propriedade recebeu o mesmo que saiu, inclusive User-ID
- Etapa 4 de 5: Publicar
Versão com nome, autor e a linha da matriz que motivou a mudança
- Etapa 5 de 5: Tempo real e 48 h
Volume por evento no dia seguinte contra a semana anterior
Tráfego interno e de desenvolvimento precisam sair da conta antes de qualquer leitura. Tráfego interno é o da equipe: a propriedade reconhece por faixa de IP e marca o evento com um parâmetro de tipo de tráfego. Tráfego de desenvolvimento é o do ambiente de homologação, marcado por um parâmetro de depuração. Os dois viram filtros de dados, que nascem em estado de teste e só depois passam a ativo.
Filtros de hostname são a novidade de 2026 nessa família. O filtro de exclusão entrou em junho; o de inclusão, uma lista de domínios autorizados, em 21 de setembro de 2026. Com a inclusão ativa, evento que chega sem hostname é bloqueado e evento de domínio fora da lista também. Eventos do Measurement Protocol não passam por esse filtro, porque não carregam hostname de página.
O que o filtro de hostname faz e o que exige
| Aspecto | Como se comporta | O que decidir antes de ativar |
|---|---|---|
| Estado de teste | Só marca os eventos com uma dimensão; nada é removido | Rodar em teste até ver zero evento legítimo marcado |
| Estado ativo | Apaga permanentemente o evento filtrado; ele não chega nem ao BigQuery | Listar todos os domínios reais, inclusive homologação, antes de ativar |
| Evento sem hostname | Bloqueado pelo filtro de inclusão | Conferir se algum evento do site sai sem a URL da página |
| Measurement Protocol | Não passa pelo filtro de inclusão | Spam por Measurement Protocol precisa de outra defesa: o segredo da API |
| Prazo e papel | Aplicação em 24 a 36 horas; exige papel Editor | Quem ativa e quando; o relatório do dia não reflete o filtro |
A regra geral de filtros de dados é de 10 por propriedade; a página de lançamento do filtro de inclusão não confirma o número.
Fonte: Search Engine Land, Google Analytics adds hostname allowlists (22/09/2026); Google Analytics Announcements (21/09/2026)
Problemas recorrentes têm assinatura. Spam aparece como sessões de hostname desconhecido, com engajamento zero e origem estranha. Duplicação aparece como page_view em dobro e purchase acima do número de pedidos, e a causa quase sempre é uma segunda instalação da tag. Evento ausente aparece como queda a zero num evento só, em geral depois de uma mudança de rota na aplicação de página única. Salto de volume sem campanha nova é bot, filtro que mudou ou deploy.
Latência muda o que cada tela pode provar. A coleta chega em segundos e o DebugView a mostra assim. O tempo real cobre 30 minutos. Os relatórios padrão processam ao longo de 24 a 48 horas, e a página oficial de diferenças entre relatórios e explorações lista as últimas 48 horas como uma das razões para os números não baterem. A exportação diária para o BigQuery é atualizada por até dois dias-calendário além do dia corrente.
Os prazos que a rotina de qualidade precisa respeitar
30 min
janela do relatório em tempo real
Serve para ver que a coleta não zerou, não para conferir parâmetro
48 h
janela em que relatório e exploração podem divergir
Comparação de volume só a partir do terceiro dia
24 a 36 h
para um filtro de hostname passar a valer
O dia da ativação ainda mostra o tráfego filtrado
2 dias
de atualização da tabela diária do BigQuery
Além do dia corrente; há sinal de completude do dia anterior
Fonte: Google Analytics Help, Data differences between reports and explorations (answer/9371379); BigQuery Export overview (answer/9358801); Search Engine Land (22/09/2026)
Monitoramento fecha a rotina, e ele só funciona com critério de alerta escrito. O critério compara um número da propriedade com um número de fora dela, num prazo fixo: purchase de ontem contra pedidos da Shopify de ontem, com tolerância combinada; generate_lead da semana contra leads novos no HubSpot; sessões por hostname contra a lista de domínios. Alerta sem número vira ruído, e ruído é ignorado na segunda semana.
Armadilha comum: publicar o contêiner depois de ver o evento no tempo real e considerar a validação feita. O tempo real prova que algo chegou; não prova que chegou com valor, moeda e transaction_id, nem que chegou uma vez. A prévia e a aba de rede provam isso, e é por elas que a publicação passa antes.
Na Verde Vivo, a matriz ficou com 14 eventos nas linhas e, nas colunas, os quatro estados de consentimento, dois dispositivos e as três superfícies: site, loja e app. A primeira passagem achou três defeitos. add_payment_info não disparava quando a pessoa escolhia Pix, porque o botão de Pix não passava pelo acionador do formulário. purchase saía com o valor do frete somado ao total, o que inflava a receita em 7 por cento. O app enviava page_view sem hostname, o que o filtro de inclusão bloquearia.
Os filtros vieram depois. Marina definiu o tráfego interno pela faixa de IP do escritório e da loja física e o de desenvolvimento pelo ambiente de homologação em Next.js; os dois rodaram uma semana em teste e passaram a ativo. O relatório por hostname mostrou 3,1 por cento das sessões vindas de domínios que a Verde Vivo não possui, com engajamento zero.
Com os três domínios reais na lista, o filtro de inclusão entrou em estado de teste. A decisão de ativar ficou para depois de o app corrigir o hostname, porque ativar antes apagaria os eventos do app para sempre.
O alerta ganhou três linhas na planilha de Marina: purchase do dia contra pedidos da Shopify, com tolerância de 25 por cento por causa do pagamento confirmado depois; generate_lead da semana contra leads no HubSpot, com tolerância de 10 por cento; e sessões de hostname fora da lista acima de 1 por cento.
Na segunda semana, a primeira linha disparou: purchase caiu 40 por cento num dia sem queda de pedidos, e a causa era um deploy que renomeou a página de confirmação. A correção levou uma hora, e o mês fechou inteiro.
Mudou o tempo entre o defeito e a descoberta: de semanas para um dia. Com a matriz, os filtros e as três linhas de alerta, a propriedade da Verde Vivo passou a merecer leitura, e é isso que a próxima trilha faz. Ela abre os relatórios nativos e ensina a ler cada um com o denominador certo.
Abra hoje o relatório de tecnologia da sua propriedade com a dimensão de hostname e anote cada domínio que aparece. O critério de acerto é uma lista em que você reconhece todos; qualquer domínio desconhecido acima de 1 por cento das sessões entra no filtro de exclusão em estado de teste ainda esta semana. Leve a lista para o próximo capítulo, porque a leitura dos relatórios começa por saber de onde o tráfego não deveria vir.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Voltar ao capítulo anterior: Manter a mesma pessoa no relatório entre login, domínios e dispositivos
Todos os capítulos de Google Analytics 2027
- 01Entender o que o GA4 de 2026 mede antes de instalar a tag
- 02Transformar a pergunta do negócio num plano de mensuração
- 03Ler usuários, sessões e engajamento sem somar o que não soma
- 04Desenhar conta, propriedade e fluxo para o negócio que existe
- 05Instalar a Google tag uma vez só e validar a coleta
- 06Organizar o Tag Manager para que a tag certa dispare uma vez
- 07Escrever o contrato de dados que o desenvolvedor consegue implementar
- 08Registrar dimensões personalizadas sem estourar a cardinalidade
- 09Pedir consentimento, ligar o Consent Mode e saber o que a modelagem devolve
- 10Manter a mesma pessoa no relatório entre login, domínios e dispositivos
- 11Provar que o evento chegou certo antes de confiar no relatório
- 12Ler os relatórios nativos com denominador certo e comparação justa
- 13Marcar campanhas com UTM e ler canais sem cair em Direct e Unassigned
- 14Medir busca orgânica e tráfego de assistentes de IA sem superestimar nenhum
- 15Descobrir por que a página cheia de tráfego não produz resultado
- 16Achar onde a jornada perde gente com exploração, segmento e funil
- 17Medir retenção, ativação e valor por coorte em vez de por mês
- 18Construir públicos que a mídia usa e saber quando o preditivo não existe
- 19Instrumentar a loja do view_item ao refund e conciliar com o financeiro
- 20Ligar o clique ao contrato assinado com eventos de lead e CRM
- 21Medir o aplicativo e a assinatura com Firebase sem perder a pessoa entre plataformas
- 22Escolher quais eventos-chave viram conversão no Google Ads e quais só analisam
- 23Explicar por que duas plataformas reivindicam a mesma venda
- 24Importar custo de mídia e comparar plataformas com o mesmo indicador
- 25Planejar orçamento entre canais e separar crédito de causa
- 26Montar o painel executivo dentro do próprio Analytics
- 27Contar o resultado do mês no Data Studio sem multiplicar linhas
- 28Usar Ask Advisor e insights automáticos sem aceitar resposta sem conferir
- 29Ligar a exportação para o BigQuery e entender o que ela não reproduz
- 30Responder às perguntas do negócio em SQL sobre os dados brutos
- 31Enviar do servidor o evento que o navegador não vê, sem duplicar
- 32Automatizar relatório, auditoria e alerta com as APIs do Analytics
- 33Decidir entre Standard e 360 e governar a propriedade como ativo da empresa
- 34Diagnosticar os onze problemas clássicos do GA4 com método
- 35Entregar o projeto de mensuração e manter a rotina que o conserva