Dados First-Party e Teste A/B num Mundo Pós-Cookie
Teste A/B com dados first-party: o que os limites de armazenamento e o consentimento custam, como a perda de identidade infla o prazo e por onde começar.
📚 Este artigo faz parte do guia GA4 e Teste A/B: o Guia Completo de Integração.
Teste A/B nunca dependeu de cookie de terceiro, então a virada de privacidade não quebrou o método; ela quebrou a contabilidade em volta dele. A divisão acontece no seu próprio domínio, com os seus próprios visitantes, medida contra as suas próprias conversões, o que é first-party por construção. O que se degradou foi a durabilidade da identidade que leva a alocação de uma visita para a seguinte, e a completude da analítica que descreve quem foi alocado. Este artigo é filho do guia completo de GA4 e teste A/B e responde uma pergunta prática: o que um programa de testes precisa mudar quando uma fatia relevante dos visitantes não pode ser medida, ou não pode ser reconhecida na segunda visita.
A versão curta: a sua amostra necessária não se move, o seu denominador semanal se move, e quase todo problema prático daí para baixo vem de time que não refez essa segunda conta.
O que mudou, com precisão
Três coisas diferentes costumam ser embrulhadas juntas sob o rótulo de “apocalipse dos cookies”, e elas têm consequências bem diferentes para um experimento.
| Mudança | O que afeta | Efeito no teste A/B |
|---|---|---|
| Cookie de terceiro bloqueado por padrão no Safari e no Firefox | Rastreamento entre sites e medição de anúncio | Quase nenhum: a divisão e a conversão são no mesmo site |
| Armazenamento first-party do lado do cliente com vida útil limitada | Quanto tempo a alocação sobrevive | Real: quem volta é realocado, diluindo o efeito medido |
| Consentimento exigido antes de as tags de medição dispararem | Quem aparece na analítica | Real: a população medida vira um subconjunto autosselecionado |
A primeira linha é a que ganha manchete e a que menos importa aqui. O Google anunciou em abril de 2025 que o Chrome não lançaria um aviso dedicado sobre cookies de terceiros e manteria a escolha já existente do usuário, enquanto Safari e Firefox os bloqueiam por padrão há anos. De um jeito ou de outro, nada disso toca um experimento no mesmo site.
A segunda linha é onde mora o estrago. O Intelligent Tracking Prevention da Apple limita a vida útil dos cookies escritos por JavaScript no cliente, documentado pela equipe do WebKit desde o ITP 2.1, em 2019, com limite adicional para armazenamento gravável por script depois de navegação entre sites com decoração de link. Um teste cuja alocação está guardada desse jeito perde visitantes recorrentes num calendário definido pelo navegador, não por você.
A terceira linha é uma decisão de projeto que você controla, e a mais frequentemente aplicada de forma inconsistente.
Perda de identidade dilui o efeito, não enviesa
Vale ser preciso nessa distinção, porque os dois modos de falha pedem respostas diferentes.
Quando quem volta é sorteado de novo, mais ou menos metade das vezes cai do mesmo lado e nada acontece, e mais ou menos metade das vezes atravessa. As travessias não favorecem sistematicamente nenhuma variação, então não criam um vencedor falso; elas misturam as duas populações e puxam a diferença observada em direção ao zero. Uma melhora real de 10% é medida como algo menor, e um teste dimensionado para 10% agora tem poder insuficiente para o que consegue de fato detectar.
O viés, ao contrário, vem de qualquer coisa que trate os dois braços de forma diferente: um fluxo de consentimento que trava um lado e não o outro, uma tag que dispara antes da renderização em um dos braços, um bloqueador de script que pega a requisição extra da variação e não a do controle. Isso produz resposta errada, não resposta fraca.
A aritmética: mesma amostra, calendário maior
Aqui está a parte que os times erram. A amostra necessária por variação é uma propriedade da estatística, não do seu rastreamento, então ela não muda quando a visibilidade cai. O que muda é a velocidade com que você a acumula.
Pegue uma taxa base de 4% e o alvo de detectar 10% de melhora relativa (de 4,0% para 4,4%), a 95% de confiança e 80% de poder. A conta devolve 39.475 visitantes por variação. Agora varie só o tráfego mensurável por semana:
| Visitantes mensuráveis por semana | O que isso representa | Dias para preencher as duas variações |
|---|---|---|
| 25.000 | Todo mundo mensurável | cerca de 23 dias |
| 17.500 | 30% dos visitantes não mensuráveis | cerca de 32 dias |
| 12.500 | Metade não mensurável | cerca de 45 dias |
Rode a sua taxa base e o seu tráfego antes de se comprometer com uma data:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
A versão perigosa desse erro não é o calendário maior, é manter o original. Um time que planejou 23 dias, perdeu 30% do tráfego mensurável e parou no dia 23 mesmo assim termina com aproximadamente 28.750 por variação em vez de 39.475. Nessa amostra, o poder de detectar o mesmo efeito de 10% relativo cai para cerca de 67%, ou seja, se a melhora for real, o teste a perde uma vez em cada três. O resultado não é um achado negativo, é ausência de achado reportada como se fosse um.
Onde a alocação deve morar
Quatro lugares, em ordem crescente de durabilidade e de custo.
- Cookie ou armazenamento local escrito por JavaScript. O mais simples e mais comum, e o mais afetado pelos limites de vida útil do armazenamento do lado do cliente. Serve para experimento curto em tráfego de alta frequência, é fraco para qualquer coisa que dependa de reconhecer um visitante semanas depois.
- Cookie first-party colocado pelo seu próprio servidor, com a marca HttpOnly. Não é escrito por script, então não está sujeito aos limites de armazenamento por script, e não é legível nem removível por bloqueador no nível da página. Esta é a mudança isolada de maior valor para a maioria dos times.
- Alocação amarrada a uma conta logada. A identidade mais estável que existe, e a única que sobrevive a uma troca de aparelho. Cobre só a parte logada do funil, então testes que começam antes do login ainda precisam de uma das opções acima.
- Alocação calculada na borda ou no servidor a cada requisição. Elimina quase por completo a questão do armazenamento, ao custo de esforço de engenharia e de uma estratégia de cache, já que uma página em cache não varia por visitante sem uma chave de cache que inclua a variação. A comparação entre client-side e server-side cobre essa troca inteira.
Um cuidado sobre a segunda opção, porque ela costuma ser vendida além do que entrega: um cookie first-party HttpOnly torna a alocação durável, não a torna consentida. Se você pode colocá-lo antes do consentimento depende de como a sua política e a sua assessoria jurídica classificam um cookie que existe para rodar um experimento, e não para entregar o serviço. Decida isso com quem é dono do tema jurídico, registre a decisão e aplique-a de forma idêntica aos dois braços.
Consentimento, aplicado com simetria ou não aplicado
A regra que mantém honesto um experimento com consentimento é a simetria. O que quer que o banner faça, ele precisa fazer com os dois braços exatamente no mesmo ponto do fluxo. Se o controle renderiza na hora enquanto a variação espera uma resposta de consentimento, você não está mais comparando dois desenhos de página, está comparando uma página contra uma página mais um atraso, e o atraso normalmente vale mais pontos de conversão do que a mudança de desenho que você queria testar.
Duas consequências que valem estar escritas no plano de teste em vez de descobertas depois:
- Declare a população. Se a medição começa depois do aceite, o achado se aplica a visitantes que consentiram. Essa é uma população legítima e uma frase honesta no relatório. Apresentar isso como “os nossos visitantes” é onde vira algo enganoso.
- Não compare atravessando uma mudança de consentimento. Um teste que rodou antes de um redesenho de banner e outro que rodou depois estão medindo populações diferentes. Trate a mudança de banner como a fronteira de uma era de medição, do mesmo jeito que trataria uma migração de rastreamento.
No Brasil, a base legal e a finalidade do tratamento vêm da LGPD, e a Autoridade Nacional de Proteção de Dados publicou um guia orientativo sobre cookies e proteção de dados pessoais que trata da distinção entre cookies necessários e os demais, e da informação que precisa ser dada ao titular. O ponto prático para quem roda teste é que a classificação do cookie de alocação (necessário ao serviço ou não) é uma decisão que precisa ser tomada e documentada, e não herdada do que a ferramenta faz por padrão.
O que dados first-party de fato compram no teste A/B
O enquadramento até aqui foi defensivo, o que subestima a oportunidade. Uma identidade first-party que você controla, especialmente uma logada, permite leituras que o rastreamento de terceiro nunca sustentou bem.
- Janelas de resultado mais longas. Uma identidade durável permite atribuir uma conversão que acontece três semanas depois da exposição, o que importa em qualquer produto de compra pensada. Armazenamento de vida curta força a medir o resultado rápido e raso em vez daquele que interessa.
- Segmentação que sobrevive. Novo contra recorrente, faixa de plano, estágio de ciclo de vida: tudo isso é seu, não depende de terceiro, e permite conferir se o resultado agregado se mantém dentro dos segmentos que importam, que é a defesa prática contra o paradoxo de Simpson.
- Métricas de guarda mais adiante no funil. Com identidade que persiste, dá para observar se um ganho em cadastro aparece como ganho em ativação ou é absorvido por uma retenção pior. Sem ela, você otimiza o primeiro passo e torce.
Exemplo trabalhado: lendo um teste com visibilidade reduzida
Uma página de preços converte a 4,00% entre os visitantes mensuráveis. O time roda o teste até 20.000 visitantes por variação e fecha com 800 conversões no controle e 880 na variação (4,40%). Passando esses quatro números pela mesma matemática de duas proporções usada em todo este blog: z = 1,99, valor-p de aproximadamente 0,046, ganho relativo observado de +10,0% e intervalo de confiança de 95% da diferença de +0,007 a +0,793 ponto percentual.
Significativo, e por pouco. O limite inferior do intervalo está sete milésimos de ponto percentual acima do zero, que é outra forma de dizer que um pouco mais de ruído teria virado o veredito. Essa é exatamente a posição em que um programa com identidade degradada vive se encontrando: a diluição encolhe a distância observada, a distância cai perto do limiar, e a decisão fica dependendo dos últimos poucos visitantes. Cole os seus números abaixo para ver onde o seu teste está:
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.
A resposta certa não é anunciar a vitória mais alto. É registrar que a estimativa é compatível com qualquer coisa entre um ganho desprezível e um ganho sólido, e decidir se a mudança é barata o suficiente para subir com um positivo fraco ou importante o suficiente para merecer uma rodada de confirmação com identidade mais persistente.
O que não fazer
- Fingerprinting para substituir cookie. Risco de conformidade e identidade instável ao mesmo tempo, já que a impressão digital muda com atualização de navegador e de aparelho, o que pode mover a mesma pessoa entre variações no meio do experimento.
- Costurar identidades entre sites que não são seus. Seja qual for o nome que o fornecedor dá, isso é justamente o que a virada de privacidade existe para impedir, e não é necessário para um experimento no mesmo site.
- Culpar a privacidade por um resultado plano. Diluição enfraquece efeitos; não apaga efeitos reais. Antes de concluir que a medição é a culpada, confira as explicações chatas primeiro: a mudança estava mesmo visível, a amostra foi mesmo atingida, a divisão ficou mesmo equilibrada.
- Reconstruir um grafo de identidade entre dispositivos para testar um botão. A identidade de que você precisa deve ser do tamanho da pergunta. A maioria dos testes não precisa reconhecer o mesmo ser humano em três aparelhos.
Faça isso automático na Donnu
O modo de falha descrito neste artigo raramente é um recurso que falta; é um passo de aritmética que ninguém refez. A visibilidade do tráfego caiu, a exigência de amostra ficou igual, a data de parada não se moveu, e um teste que nunca teve poder para responder a pergunta foi reportado como resposta.
A Donnu cuida da metade web e client-side disso: um snippet first-party servido do seu próprio domínio, dimensionamento de amostra calculado a partir da sua taxa base real em vez de um padrão, e estatística honesta que mostra o intervalo de confiança ao lado do veredito em vez de um único número verde. Ela não constrói para você um grafo de identidade entre dispositivos e não finge que constrói; o que ela faz é se recusar a chamar de vencedor um resultado diluído e sem poder. Comece um teste grátis de 14 dias e veja o intervalo, não só a seta.
Referências
- The Privacy Sandbox. A new path for Privacy Sandbox on the web. Anúncio de abril de 2025 de que o Chrome manteria a escolha já existente do usuário sobre cookies de terceiros em vez de lançar um aviso dedicado. privacysandbox.com/news/privacy-sandbox-next-steps.
- WebKit. Intelligent Tracking Prevention 2.1. Limite de vida útil dos cookies escritos por script no lado do cliente. webkit.org/blog/8613/intelligent-tracking-prevention-2-1.
- WebKit. Intelligent Tracking Prevention 2.3. Limites adicionais ao armazenamento gravável por script depois de navegação entre sites com decoração de link. webkit.org/blog/9521/intelligent-tracking-prevention-2-3.
- Mozilla. Enhanced Tracking Protection. Cookies de rastreamento de terceiros bloqueados por padrão no Firefox. support.mozilla.org/kb/enhanced-tracking-protection-firefox-desktop.
- Ajuda do Google Analytics. Modo de consentimento. Como o comportamento das tags muda antes e depois do consentimento. support.google.com/analytics/answer/9976101.
- MDN Web Docs. Set-Cookie: o atributo HttpOnly. Por que um cookie colocado pelo servidor não é alcançável por scripts da página. developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie.
- ANPD. Guia orientativo: cookies e proteção de dados pessoais. gov.br/anpd.
- Brasil. Lei nº 13.709/2018 (Lei Geral de Proteção de Dados Pessoais). planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
Leia também:
- GA4 e Teste A/B: o guia completo de integração
- Teste A/B Client-Side x Server-Side: a comparação completa
- CRO para Sites de Baixo Tráfego: como testar assim mesmo
- Erros Comuns em Testes A/B
Read in English: First-Party Data and A/B Testing in a Post-Cookie World
Perguntas frequentes
- O fim do cookie de terceiro quebrou o teste A/B?
- Não, e vale desfazer a confusão. Teste A/B sempre foi uma atividade first-party: você divide os seus próprios visitantes no seu próprio domínio e mede as suas próprias conversões, então nenhum cookie de terceiro jamais foi necessário para a divisão em si. O que a virada de privacidade mudou foi a confiabilidade da identidade que carrega a alocação e a completude da analítica que reporta sobre ela. O experimento continua funcionando; a contabilidade em volta dele fica mais ruidosa.
- O que realmente quebra quando o armazenamento do navegador é restringido?
- A persistência da alocação, não o sorteio. Quando o navegador expira ou limpa a chave que guarda "este visitante está na variação B", quem volta é tratado como novo e é sorteado de novo, o que pode colocar a mesma pessoa dos dois lados do teste ao longo das visitas. Isso dilui a diferença medida em direção ao zero e, no pior caso, quebra a proporção da divisão. A estatística continua válida; o que se degrada é a premissa de que um visitante equivale a uma exposição consistente.
- O banner de consentimento invalida o meu teste A/B?
- Ele torna o teste parcial, o que é diferente de inválido. Se a medição só começa depois do consentimento, você está rodando o experimento no subconjunto de quem aceita, e esse subconjunto não é uma amostra aleatória do seu tráfego. O resultado continua válido para aquela população, e isso deve ser dito no relatório. O que é genuinamente inválido é aplicar o consentimento de forma assimétrica, por exemplo deixando a variação rodar antes do banner enquanto o controle espera, porque aí o próprio banner passa a fazer parte do que está sendo medido.
- Devo migrar meus testes para server-side por causa da privacidade?
- Só se a restrição que está te travando for a persistência da identidade, e só com clareza sobre o custo. Uma alocação feita no servidor e gravada num cookie first-party com a marca HttpOnly sobrevive melhor às restrições de armazenamento do lado do cliente do que uma chave escrita por JavaScript, e não pode ser removida por bloqueador de script. Em troca, você abre mão da iteração rápida do snippet, precisa de engenharia para cada mudança e passa a ser dono do problema de cache, já que uma página em cache não varia por visitante sem trabalho extra na borda.
- Quanta amostra a mais a perda de identidade custa?
- Não é amostra a mais, é tempo a mais, e essa é a armadilha. A amostra necessária por variação não muda: com taxa base de 4% e alvo de detectar 10% de melhora relativa a 95% de confiança e 80% de poder, são 39.475 por variação, dando ou não para medir todo mundo. O que muda é o denominador semanal que preenche isso. A 25.000 visitantes mensuráveis por semana o teste leva cerca de 23 dias; se 30% deles deixam de ser mensuráveis, o mesmo teste leva cerca de 32 dias; pela metade, cerca de 45 dias. Quem não refaz essa conta acaba parando na data original com uma fração da amostra planejada.
- Fingerprinting é um substituto legítimo do cookie em teste?
- Não, por dois motivos independentes. Juridicamente, identificar um dispositivo sem consentimento é tratamento de dado pessoal sob a LGPD e sob o GDPR, e fazer isso especificamente para driblar uma restrição de armazenamento é difícil de sustentar como legítimo interesse. Tecnicamente, é instável exatamente onde importa aqui, porque a impressão digital muda com atualização de navegador, mudança de tela e condição de rede, então a mesma pessoa pode migrar de variação no meio do experimento. Identidade frágil que também é risco de conformidade é um péssimo negócio para um experimento.