Perda de Rastreamento em Teste A/B: o dado que some

Perda de rastreamento não enviesa um teste A/B por ser grande, enviesa por ser diferencial. Se as duas variações perdem a mesma fração de eventos, o experimento fica com menos dado, perde poder e continua honesto; se a variação nova perde mais que a antiga, o número lido está errado e nenhum tamanho de amostra conserta. Este guia mostra as três camadas que apagam dado hoje, com as datas e os limites oficiais, um exemplo trabalhado em que 8 por cento de conversões não registradas apagam um ganho real de 10 por cento, e o que muda quando a perda toca o denominador em vez do numerador. Faz parte do nosso guia completo de teste A/B e é o irmão de coleta do viés de instrumentação: lá o instrumento mede errado, aqui o instrumento não mede.

Três camadas apagam dado, por motivos diferentes

Vale separar as camadas porque elas têm remédios distintos e prazos distintos.

Camada 1, consentimento. Onde a base legal exige consentimento prévio para medição, o visitante que recusa não deve ser medido. Isso não é uma falha técnica a ser contornada, é o funcionamento correto do sistema. O que interessa ao experimento é o tamanho do buraco e a simetria dele.

Camada 2, bloqueadores. Extensões e listas de bloqueio impedem o carregamento do script ou o envio do evento. A perda aqui é seletiva por domínio, por nome de arquivo e por padrão de requisição, o que a torna estruturalmente assimétrica: um script novo, hospedado num caminho novo, é mais fácil de bloquear do que um que já está em produção há um ano.

Camada 3, políticas do navegador. Esta é a que mais surpreende quem monta experimento, porque atinge cookie de primeira parte. O WebKit anunciou em 21 de fevereiro de 2019, com a Intelligent Tracking Prevention 2.1 no iOS 12.2 e no Safari 12.1, que todos os cookies persistentes escritos pelo cliente, ou seja, criados através de document.cookie, passam a ter validade limitada a sete dias. Em 24 de março de 2020, com o iOS e iPadOS 13.4 e o Safari 13.1 no macOS, o WebKit foi além e passou a bloquear por padrão os cookies para recursos de outros sites, além de apagar todo o armazenamento gravável por script (IndexedDB, LocalStorage, chaves de mídia, SessionStorage e registros de Service Worker) depois de sete dias de uso do Safari sem interação do usuário no site. A Mozilla, em 14 de junho de 2022, passou a distribuir a Total Cookie Protection por padrão para mais usuários de Firefox no mundo todo, em Windows, Mac, Linux e Android, criando um pote de cookies separado para cada site visitado.

camada	mecanismo	o que se perde	escala de tempo
Consentimento	base legal, banner	tudo daquele visitante	imediato
Bloqueador de conteúdo	script ou requisição barrada	eventos, às vezes a atribuição inteira	imediato
Validade de cookie escrito por script	7 dias no Safari desde a ITP 2.1	a identidade entre visitas	a partir do 8º dia
Limpeza de armazenamento gravável por script	7 dias sem interação, desde março de 2020	identidade guardada fora do cookie	a partir do 8º dia
Isolamento por site	pote de cookies por site no Firefox	costura entre domínios	imediato

A terceira e a quarta linha merecem atenção especial de quem roda teste A/B, porque elas não apagam um evento, apagam a identidade. Um visitante que volta no décimo dia não é reconhecido como o mesmo, é sorteado de novo e pode cair na outra variação. O efeito prático não é só perda de dado: é diluição do efeito medido, porque parte das pessoas atribuídas ao tratamento passa a ver o controle. O tratamento correto da unidade sorteada está em unidade de sorteio.

Sobre o cerco aos cookies de terceiros, uma correção de rumo importante: em 22 de abril de 2025, Anthony Chavez, vice-presidente do Privacy Sandbox, publicou que o Google decidiu manter a abordagem atual de oferecer escolha ao usuário sobre cookies de terceiros no Chrome e que não vai lançar um novo aviso dedicado para isso. Para experimentação, isso muda pouco, porque um teste A/B bem montado nunca dependeu de cookie de terceiro. O que aperta o experimento é o limite de validade sobre o cookie de primeira parte escrito por JavaScript, e esse limite continua de pé.

Perda de rastreamento simétrica e diferencial

Existe uma armadilha de raciocínio comum aqui. Alguém observa que 30 por cento dos eventos se perdem, conclui que o dado é lixo e para de testar. Se essa perda for simétrica, a conclusão está errada: com 30 por cento a menos de dado você precisa de mais tempo, não de outra decisão. E existe a armadilha oposta, mais cara: alguém observa que a perda é de apenas 5 por cento, considera desprezível e não checa a simetria. Cinco por cento concentrados num braço só bastam para virar um resultado, como o exemplo abaixo mostra.

Exemplo trabalhado: 8 por cento que apagam um ganho de 10 por cento

Todos os números vieram da calculadora de significância embutida logo adiante, com teste bilateral. Você pode colar as contagens e reproduzir cada linha.

O cenário: a variação B move o botão de compra para um componente novo, e a conversão dessa variação é registrada por um evento novo, servido a partir de um caminho novo do seu domínio. Esse caminho está numa lista de bloqueio popular. O evento do controle, que existe há dois anos, não está.

A verdade. A recebeu 30.000 visitantes e 1.500 pedidos, taxa de 5,000 por cento. B recebeu 30.000 visitantes e 1.650 pedidos, taxa de 5,500 por cento. A calculadora devolve lift relativo de 10,00 por cento, z igual a 2,7457 e valor-p de 0,006039, com intervalo de 0,143 a 0,857 ponto percentual. B vence.

O que o painel mostra. Oito por cento das conversões de B nunca foram registradas. B aparece com 1.518 pedidos sobre os mesmos 30.000 visitantes, taxa de 5,060 por cento. A calculadora devolve lift relativo de 1,20 por cento, z igual a 0,3362 e valor-p de 0,736707, com intervalo de menos 0,290 a 0,410 ponto percentual. Inconclusivo.

leitura	pedidos A	pedidos B registrados	taxa B	lift relativo	z	valor-p	veredito
Nada perdido	1.500	1.650	5,500%	+10,00%	2,7457	0,006039	B vence
4% das conversões de B perdidas	1.500	1.584	5,280%	+5,60%	1,5530	0,120415	inconclusivo
8% das conversões de B perdidas	1.500	1.518	5,060%	+1,20%	0,3362	0,736707	inconclusivo

Repare que em nenhuma linha o painel grita. Não aparece erro, não aparece alarme, e a variação B nunca chega a “perder”: ela simplesmente para de ganhar. Esse é o formato mais perigoso de falha de dado, porque o desfecho é indistinguível de uma hipótese que não funcionou. A maldição do vencedor trata do erro na direção oposta, o de superestimar o vencedor; aqui o erro é apagar o vencedor.

Controle (A)

VisitantesConversões

Variação (B)

VisitantesConversões

Confiança90%95%99%

Controle (A) · Taxa-

Variação (B) · Taxa-

Melhora relativa-

valor-p-

IC 95% da diferença-

Teste z bilateral de duas proporções. "Sem significância" quase sempre quer dizer que falta amostra, não que as versões são iguais.

Quando a perda toca o denominador

O caso acima é perda no numerador: a conversão aconteceu e não foi registrada. Existe um caso pior de diagnosticar e mais fácil de detectar: perda no denominador, quando a própria exposição do visitante à variação não chega ao servidor.

Perda no denominador é mais fácil de detectar porque ela deixa uma marca aritmética: a proporção observada de visitantes entre os braços deixa de bater com a alocação configurada. É exatamente o que o teste de divisão desigual de tráfego mede, e os números abaixo saíram do verificador de SRM, num teste de aderência qui-quadrado contra a alocação esperada de 50 por cento para cada lado.

exposições em A	exposições em B	fração observada de B	qui-quadrado	valor-p	passa no guardrail de 0,01?
30.000	29.700 (1% perdido)	49,749%	1,51	0,2195	sim
30.000	29.400 (2% perdido)	49,495%	6,06	0,0138	sim, no limite
30.000	28.800 (4% perdido)	48,980%	24,49	0,00000075	não
30.000	27.600 (8% perdido)	47,917%	100,00	abaixo de 0,000001	não

A leitura útil dessa tabela é a segunda linha. Uma perda de 2 por cento no registro de exposição produz valor-p de 0,0138, que passa no limiar convencional de 0,01 usado como guardrail de divisão desigual, e mesmo assim já é o bastante para mover a taxa observada. Ou seja: o alarme de divisão desigual é um piso, não um teto. Ele pega a falha grosseira e deixa passar a falha pequena o suficiente para ser silenciosa e grande o suficiente para importar.

Por que a variação nova quase sempre perde mais

A assimetria não é azar, é consequência estrutural de como um teste é implementado. Vale ter a lista à mão porque ela funciona como roteiro de revisão antes de subir o experimento.

1. Script novo em caminho novo. Domínios e caminhos recém-criados não têm histórico e são mais fáceis de casar com regras genéricas de bloqueio.
2. Evento novo com nome novo. O evento do controle sobreviveu a dois anos de ajustes de rastreamento; o da variação nasceu ontem.
3. Etapa a mais no funil. Se a variação insere uma tela, cada tela adicional é mais uma chance de o visitante sair antes do disparo.
4. Momento do disparo. Um evento disparado no descarregamento da página, ou depois de uma navegação, perde mais que um disparado no clique.
5. Peso e tempo de carga. Uma variação mais pesada chega a registrar menos porque parte dos visitantes abandona antes do script terminar de carregar.
6. Mudança no consentimento. Qualquer variação que toque o banner altera a própria taxa de consentimento, e aí a perda é diferencial por construção.
7. Domínio de terceiros na conversão. Se a variação leva a um provedor de pagamento diferente, a conversão cruza uma fronteira de domínio a mais.

Os pontos 1, 2 e 7 caem inteiros dentro do território de dados de primeira parte, e o ponto 5 é uma das razões pelas quais uma variação com desempenho pior de carregamento pode parecer pior de conversão sem que a mudança visual tenha nada a ver com isso.

O que efetivamente reduz o problema

Em ordem de impacto, para quem precisa escolher onde investir primeiro:

1. Registrar a exposição no servidor. Estabiliza o denominador e é o único movimento que ataca a divisão desigual na origem. O caminho está em teste A/B no servidor e a comparação entre as duas arquiteturas em cliente contra servidor.
2. Usar identificador de primeira parte com validade definida no servidor. Um cookie definido pelo servidor não cai na regra de sete dias que atinge os cookies escritos por document.cookie.
3. Manter a coleta da variação idêntica à do controle. Mesmo script, mesmo caminho, mesmo momento de disparo. Só muda o que aparece na tela.
4. Medir a taxa de perda como métrica de guardrail. Registre a razão entre eventos esperados e eventos recebidos, por variação, ao lado do resultado. O papel dessas travas está em métricas de guardrail.
5. Escolher a unidade de sorteio compatível com a durabilidade real da identidade. Se a identidade não sobrevive sete dias naquele navegador, um teste de quatro semanas medindo comportamento por usuário não está medindo o que promete.
6. Declarar a política de consentimento no plano de análise. Quem entra na conta e quem não entra é decisão de desenho, não de análise, e está no plano de análise pré-registrado.

Checklist antes de ler o resultado

1. A taxa de eventos recebidos sobre eventos esperados está medida por variação?
2. A divisão de tráfego observada bate com a configurada, e você olhou o valor-p e não só a diferença percentual?
3. A variação usa o mesmo script, o mesmo caminho e o mesmo momento de disparo do controle?
4. A variação toca o banner de consentimento de alguma forma?
5. A duração do teste é compatível com a durabilidade da identidade no navegador dominante do seu público?
6. A taxa de recusa de consentimento é parecida nos dois braços?
7. Existe alguma métrica lida no servidor, como pedido pago, para comparar com a métrica lida no navegador?

O item 7 é o mais subestimado. Comparar a contagem de pedidos do seu banco com a contagem de conversões do seu rastreador, por variação, é a auditoria mais barata que existe e resolve a maioria dos casos em uma consulta.

Erros comuns

• Concluir que o dado é inútil porque a perda é alta. Perda simétrica custa poder, não conclusão.
• Considerar 5 por cento de perda desprezível sem checar a simetria. Cinco por cento concentrados num braço mudam vencedor.
• Testar mudanças no banner de consentimento e ler o resultado pelo evento do navegador. A perda ali é diferencial por construção.
• Confiar que o guardrail de divisão desigual pega tudo. Ele passou com folga na perda de 2 por cento da tabela acima.
• Tratar a política do Safari como assunto de cookie de terceiro. A regra de sete dias atinge o cookie de primeira parte escrito por script.
• Achar que a decisão do Chrome de manter cookies de terceiros resolveu a questão. Ela nunca foi sobre isso, para experimentação.
• Comparar apenas totais e nunca a razão entre esperado e recebido por variação. O total esconde exatamente a assimetria que importa.

Faça isso automático na Donnu

O buraco raro é técnico. O buraco comum é organizacional: a perda de dado é conhecida por quem cuida do rastreamento, o resultado do teste é lido por quem cuida do produto, e as duas informações nunca aparecem na mesma tela.

Na Donnu, a divisão observada de visitantes por variação fica ao lado do resultado desde o primeiro dia, com o valor-p da aderência, porque desvio de alocação é o sintoma comum de perda no denominador, de erro de sorteio e de tráfego de bot. O sorteio e o registro de exposição podem ser feitos no servidor, sem depender de cookie escrito por script, e a mesma calculadora de significância aceita as contagens do seu banco de dados para você comparar a leitura do navegador com a leitura do servidor antes de decidir qualquer coisa.

Referências

• WebKit. Intelligent Tracking Prevention 2.1. 21 de fevereiro de 2019. Fonte do limite de sete dias: com a ITP 2.1, no iOS 12.2 e no Safari 12.1, todos os cookies persistentes escritos pelo cliente, isto é, cookies persistentes criados através de document.cookie, passam a ter validade limitada a sete dias, restrição que não atinge cookies de sessão nem cookies de autenticação marcados como Secure e HttpOnly. webkit.org.
• WebKit. Full Third-Party Cookie Blocking and More. 24 de março de 2020. Fonte do bloqueio padrão de cookies para recursos de outros sites no iOS e iPadOS 13.4 e no Safari 13.1 do macOS, e da extensão da limpeza de sete dias a todo o armazenamento gravável por script, incluindo IndexedDB, LocalStorage, chaves de mídia, SessionStorage e registros de Service Worker, depois de sete dias de uso do Safari sem interação do usuário no site. webkit.org.
• Chavez, A. Next steps for Privacy Sandbox and tracking protections in Chrome. Blog do Privacy Sandbox, 22 de abril de 2025. Fonte da decisão de manter a abordagem atual de escolha do usuário sobre cookies de terceiros no Chrome e de não lançar um novo aviso dedicado para cookies de terceiros. privacysandbox.google.com.
• Mozilla. Firefox rolls out Total Cookie Protection by default to more users worldwide. 14 de junho de 2022. Fonte do mecanismo de isolamento: a Total Cookie Protection funciona criando um pote de cookies separado para cada site visitado, e passou a ser distribuída por padrão para mais usuários de Firefox no mundo todo, em Windows, Mac, Linux e Android. blog.mozilla.org.
• Crook, T., Frasca, B., Kohavi, R. e Longbotham, R. Seven Pitfalls to Avoid when Running Controlled Experiments on the Web. KDD 2009. Fonte da orientação de auditoria da coleta: validar a captura do comportamento do usuário, a atribuição às variações e o cálculo das métricas, comparando o dado recebido pelo sistema de experimentação com o sistema de registro existente, registro por registro quando possível, e da observação dos autores de que essas auditorias encontraram problemas sérios até em sistemas de registro consolidados. exp-platform.com.

Leia também: Viés de instrumentação · Divisão desigual de tráfego (SRM) · Unidade de sorteio · Teste A/B no cliente ou no servidor · Dados de primeira parte · Verificador de SRM · Read in English