Validação, filtros e qualidade: aprovar a coleta com evidências

Com a identidade definida, 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 a compra saiu sem valor, que o pagamento por Pix nunca disparou ou que parte das sessões vem de um domínio que a empresa não conhece.

Descobrir tarde custa o mês. Um evento que parou depois de uma atualização do site só aparece quando alguém estranha a queda, e a comparação com o mês anterior já não vale. O capítulo segue um pedido de teste do disparo até a comparação com a loja, e mostra qual prova cada etapa entrega.

Um pedido de teste, cinco provas diferentes

Caio faz uma compra de teste em homologação e acompanha o pedido por cinco etapas. Até o pedido criado, o caminho é o do navegador; a compra confirmada sai do servidor da loja e tem a sua prova no registro de envio. Cada etapa responde a uma pergunta diferente, e a ferramenta muda quando a pergunta muda, como numa entrega acompanhada da expedição até a assinatura do recebedor.

A prévia do Tag Manager mostra o disparo. A aba de rede do navegador mostra a requisição como ela saiu: nome do evento, cada parâmetro, estado de consentimento e destino. O DebugView, tela do Analytics que exibe em segundos os eventos de um aparelho em modo de depuração, mostra o que a propriedade recebeu. O tempo real mostra o agregado dos últimos 30 minutos, e os relatórios só fecham o dia depois do processamento.

A matriz de testes muda conforme o caminho do evento

A matriz transforma a prova em rotina: nas linhas, os eventos da especificação; nas colunas, o que varia, como estado de consentimento, dispositivo e superfície. Uma célula vazia é uma combinação que ninguém testou, e é ali que o defeito costuma morar.

Os eventos não chegam todos pelo mesmo caminho. Os do site saem da tag no navegador, os do aplicativo saem do kit de desenvolvimento instalado no app e os do servidor, como o Pix confirmado, saem de um sistema da empresa direto para o Google. Cada caminho tem a sua ferramenta de saída e de chegada.

Filtros excluem tráfego conforme regras definidas

O tráfego da equipe e o dos ambientes de teste saem antes de qualquer leitura. O tráfego interno é reconhecido pela faixa de IP do escritório e da loja física; o de desenvolvimento, pelo modo de depuração. Os dois viram filtros de dados, que nascem no estado Testes, quando só marcam os eventos, e passam a Ativo depois de uma semana sem marcar nenhum cliente.

Desde 21 de setembro de 2026, o filtro de hostname, o nome do domínio que aparece no endereço da página, tem também o tipo Incluir: uma lista de domínios autorizados, e só eles entram. O Google avisa que esse tipo bloqueia automaticamente eventos sem hostname e não se aplica a eventos enviados pelo Measurement Protocol, o canal de envio pelo servidor. A ajuda trata o recurso como filtro de hostnames da web e lembra que filtros valem só para dados novos.

A lista de domínios autorizados é uma decisão com risco de perda permanente. Antes de ativar, a equipe faz o inventário de todos os destinos legítimos: o site, a loja, o blog, as páginas de campanha hospedadas em ferramentas externas e o retorno do meio de pagamento. Depois, testa os fluxos web legítimos, inclusive envios sem hostname. O filtro documentado é da web; a validação de app e de Measurement Protocol tem critérios próprios e não deve depender dessa lista. Se um domínio legítimo ficar de fora de um filtro ativo, seus dados novos abrangidos pelo filtro serão excluídos de forma permanente. O histórico já coletado não é apagado.

Cada defeito tem uma assinatura

Spam aparece como sessões de domínio desconhecido, com engajamento zero e origem estranha. Duplicação aparece como visualizações em dobro ou compras acima do número de pedidos, e a causa costuma ser uma segunda instalação da tag. Evento ausente aparece como queda a zero num evento só, em geral depois de uma mudança no site. Salto de volume sem campanha nova pede investigação de robôs, de filtro alterado ou de publicação recente.

A latência muda o que cada tela prova. A coleta chega em segundos e o DebugView mostra assim; o tempo real cobre 30 minutos; os relatórios padrão podem divergir das explorações nas últimas 48 horas; a tabela diária do BigQuery ainda é atualizada por dois dias além do dia corrente.

O alerta compara com uma fonte de fora, numa faixa conhecida

Monitoramento só funciona com critério escrito: um número da propriedade comparado com um de fora dela, para a mesma população e o mesmo período. Compras do Analytics contra pedidos pagos da Shopify do mesmo dia; pedidos de orçamento da semana contra registros novos no HubSpot. A faixa aceitável sai do histórico daquela comparação, e não de uma regra universal: recusa de cookies, pagamento confirmado depois e modelagem mudam a diferença normal de cada empresa.

Uma armadilha frequente é publicar o contêiner porque o evento apareceu no tempo real. O tempo real prova que algo chegou; não prova que chegou com valor, moeda e número do pedido, nem que chegou uma vez. Essa prova vem da prévia e da aba de rede.

A primeira passagem na Verde Vivo achou dois defeitos

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. O evento de pagamento informado não disparava quando a pessoa escolhia Pix, porque o botão de Pix não passava pelo acionador do formulário. A compra saía com o frete somado ao valor, o que inflava a receita em 7%; o catálogo do Google pede o valor dos itens, sem frete nem imposto.

Os filtros vieram depois. O tráfego interno e o de desenvolvimento rodaram uma semana em teste e passaram a ativo. O relatório por hostname mostrou 3,1% das sessões vindas de domínios que a Verde Vivo não possui, com engajamento zero. O filtro do tipo Incluir entrou em teste com os domínios reais e só será ativado depois de conferir o tráfego web legítimo. Aplicativo e envios pelo Measurement Protocol são validados separadamente.

Marina calculou a diferença média entre compras do Analytics e pedidos pagos da Shopify nas quatro semanas anteriores e definiu o alerta como saída dessa faixa. Na segunda semana, ele disparou: as compras caíram 40% num dia sem queda de pedidos, e a causa era uma atualização do sistema da loja que mudou o nome do campo de pagamento confirmado, e a fila de envio passou a recusar os pedidos. A correção levou uma hora; os pedidos parados foram reenviados dentro das 72 horas aceitas pelo Measurement Protocol, com a data original, e o mês fechou sem lacuna. O tempo entre o defeito e a descoberta caiu de semanas para um dia.

O que pedir à equipe

Peça a matriz de testes preenchida, com uma linha por evento e as colunas de consentimento, dispositivo e caminho, e a prova de saída e de chegada em cada célula. Peça também o inventário de domínios antes de qualquer filtro do tipo Incluir e o critério de alerta escrito, com a faixa calculada a partir do histórico.

Com a coleta provada, os relatórios passam a merecer leitura, e a leitura também tem armadilhas. O capítulo Ler relatórios sem se enganar: período, denominador e comparação mostra como evitar as mais comuns.