Diagnostique uma discrepância na proporção da amostra em cinco ramos antes de descartar o teste.

Cerca de 6% dos experimentos na Microsoft mostram uma incompatibilidade na proporção de amostras, o que, em um produto que executa 10,000 experimentos por ano, equivale a aproximadamente uma detecção por dia (Fabijan e outros, KDD 2019Equipes que executam um número muito menor de testes raramente veem esse número, porque a verificação que sua plataforma realiza não consegue atingir significância estatística com o volume de tráfego que possuem. O teste parece limpo, relata um aumento de 4% e, mesmo assim, está errado.

Este guia destina-se à pessoa que analisa os resultados do experimento e precisa decidir se o produto deve ser enviado para análise. Ao final, você será capaz de determinar se o seu teste é suficientemente amplo para que a verificação de incompatibilidade seja relevante, executar cinco ramificações de diagnóstico na ordem que identifica a causa mais rapidamente e diferenciar um desequilíbrio que invalida os resultados de um desequilíbrio que pode ser segmentado e mantido.

O que um alarme SRM realmente indica

Uma discrepância na proporção da amostra ocorre quando há uma diferença entre a divisão configurada e a divisão observada: por exemplo, você definiu 50/50 e obteve 50.8/49.2. A verificação padrão é o teste de qui-quadrado de Pearson para aderência aos dados de exposição, com um grau de liberdade para um teste de dois braços.

Isso é importante porque o mecanismo que causa a perda de usuários quase nunca é neutro em relação à sua métrica. Se um redirecionamento descarta conexões lentas da variante, os sobreviventes são aqueles com conexões melhores, e eles convertem melhor. O aumento é real nos dados, mas inexistente na prática.

Eis o primeiro erro que a maioria das equipes comete: não existe um limite mínimo de qualidade na indústria. As plataformas divergem em mais de uma ordem de grandeza.

Duas consequências. Um teste sinalizado em uma plataforma passa em outra com dados idênticos, então "nossa ferramenta não nos alertou" não é evidência de uma divisão clara. E um limite de 0.01 sinaliza um em cada cem testes saudáveis. Se você observar o valor p diariamente ao longo de um teste de três semanas, o limite de erro ingênuo para um falso alarme é de 19%; o valor real é menor porque os dias consecutivos são fortemente correlacionados, mas não é 1%. É por isso que o AB Tasty executa um procedimento sequencial. Se sua plataforma executa um teste qui-quadrado de horizonte fixo, observe apenas uma vez, no final, as contagens cumulativas.

Verifique se o seu teste consegue detectar algum desequilíbrio.

Para uma divisão de 50/50, a estatística qui-quadrado se simplifica para 4n(p̂−0.5)², onde n é o total de exposições. Invertendo-a, obtém-se o menor desequilíbrio que sua verificação pode detectar:

Leia isso como um limite, não como uma licença. Com 10,000 exposições, qualquer desequilíbrio menor que 1.3 ponto percentual é invisível para a verificação, e um efeito de seleção de 1.3 ponto percentual é mais do que suficiente para gerar um pequeno aumento na conversão. Esse é o problema estrutural em grande parte da região. A Turquia registrou cerca de 6 bilhões de transações de comércio eletrônico em aproximadamente 634,000 empresas em 2025 (Ministério do Comércio, 12 de maio de 2026), uma média de cerca de 9,500 por ano cada, e essa média é fortemente influenciada por um pequeno número de marketplaces. Uma loja de médio porte que testa uma etapa de finalização de compra trabalha com dezenas de milhares de exposições, não milhões, portanto, sua verificação de SRM detecta falhas grosseiras e nada mais sutil.

Nesse volume, não confie no alarme. Extraia você mesmo as contagens brutas de exposição por dia e por segmento e considere suspeita qualquer deriva persistente na mesma direção, mesmo que o valor p seja insignificante. Se você não tiver certeza de onde sua plataforma expõe essas contagens, Documentação do verificador SRM mapeia-os por ferramenta.

Os cinco ramos, na ordem em que encontram a causa mais rapidamente.

A taxonomia KDD classifica as causas de SRM por estágio do ciclo de vida: atribuição, execução, processamento de logs, análise e interferência. Diagnostique-as em uma ordem diferente, priorizando as mais baratas e mais comuns.

1. Análise e ativação. Sintoma: a divisão é clara no registro de exposição bruto, mas apresenta problemas no scorecard. Verificação: recalcule a proporção sem a sua condição de gatilho, filtro de data e junções em nível de métrica. Isso confirma se a proporção retorna ao esperado. Correção: avalie o gatilho de forma idêntica em ambos os braços, antes que qualquer comportamento específico da variante possa alterar a elegibilidade. Alarme falso mais comum; dez minutos para descartar.
2. Processamento de logs. Sintoma: a contagem de exposições difere entre dois pipelines, ou a discrepância aparece após a etapa de ETL. Verificação: compare a contagem do lado do SDK, a contagem do data warehouse e a contagem de relatórios para a mesma janela e, em seguida, compare as taxas de exclusão do filtro de bots por braço. Isso confirma se os braços são iguais a montante e desiguais a jusante. Correção: filtre de forma determinística e idêntica. O tráfego automatizado atingiu 53% do tráfego da web em 2026, um aumento em relação aos 51% em 2024 (Relatório de bots maliciosos da Imperva, 29 de abril de 2026), portanto, um filtro heurístico baseado no tempo de carregamento ou no comportamento do agente do usuário pode excluir em taxas diferentes por variante. A perda orientada pelo consentimento também se aplica aqui: quando ad_storage Se o pedido for negado, a plataforma de tags do Google para de definir cookies de publicidade (Documentação de consentimento da plataforma de tags do Google), portanto, se as taxas de rejeição variarem entre as regiões geográficas em um teste, qualquer atribuição que dependa desses identificadores resultará em perda de usuários de forma desigual.
3. Execução. Sintoma: o desequilíbrio aumenta com o peso da página, piora em dispositivos móveis ou começa após a implantação. Verificação: divida a proporção por dispositivo, navegador, tipo de conexão e dia; compare o tempo de exposição entre os grupos. Isso confirma se o déficit se concentra em segmentos lentos ou em um navegador específico. Solução: é aqui que os testes de redirecionamento falham. Um redirecionamento adiciona uma navegação completa a apenas um dos grupos, e todos que abandonam a página durante o redirecionamento representam uma perda seletiva. Renderize ambas as variantes no servidor em um único URL ou aceite que os grupos não são comparáveis.
4. Cessão. Sintoma: a proporção está incorreta desde a primeira hora e permanece assim por um fator constante. Verificação: execute um teste A/A na mesma alocação e verifique se o sal de hash não foi reutilizado de um experimento anterior com essa população. Isso confirma se o teste A/A também mostrar o desequilíbrio. Solução: reatribua com um novo sal e reinicie. A transferência de um teste anterior é a versão silenciosa desse problema, e somente o teste A/A a expõe.
5. Interferência. Sintoma: o desequilíbrio está concentrado em um pequeno número de identificadores de alta atividade ou em intervalos de IP internos. Verifique: a distribuição da contagem de exposições por usuário e o 1% dos identificadores com maior volume de eventos. Confirme se a remoção deles restaura a proporção. Solução: exclua o tráfego interno e automatizado por meio de uma regra documentada, e não manualmente, para que a exclusão seja idêntica na próxima vez.

Um passo a passo detalhado

Os números abaixo são ilustrativos e não representam dados reais de clientes. Um teste de finalização de compra relata 61,480 exposições ao controle e 58,520 à variante: 51.2/48.8 em 120,000 usuários, com um valor de p do teste qui-quadrado inferior a 0.001. Ramo 1: remover a condição de ativação resulta em 60,020/59,980, portanto, a atribuição está correta e a perda ocorre após a exposição. Ramo 2: as contagens do pipeline concordam, com exclusões de bots em 0.9% em ambos os ramos. Ramo 3: a versão desktop apresenta 50.1/49.9, a versão mobile 52.4/47.6, e o tempo médio de exposição da variante é 900 ms maior em dispositivos móveis. Diagnóstico: a variante envia uma solicitação extra que bloqueia a renderização; usuários de dispositivos móveis abandonam a página durante esse processo, enquanto os que permanecem na página têm conexões melhores. O resultado é inválido. A correção visa melhorar o desempenho e o teste é executado novamente, sem reinterpretação.

O que você pode aproveitar e o que não pode.

• Anule a leitura. Quando o mecanismo de perda puder plausivelmente se correlacionar com a métrica. Toda causa de execução e atribuição se qualifica por padrão.
• Recuperação por segmento Somente quando o desequilíbrio estiver confinado a um segmento que você possa excluir com clareza, esse segmento tiver sido definido antes de você analisar a métrica e o restante passar na sua própria verificação SRM. Dois de três não é suficiente.
• Guarde o teste Quando a causa estava puramente na análise e o scorecard corrigido é aprovado. Você está relendo os mesmos dados com um filtro fixo, não tentando encontrar nada.
• Registre de qualquer forma. Registre a categoria da causa no experimento. A taxonomia compensa cumulativamente: se três dos seus últimos dez testes falharam na ramificação 3, seu problema não é experimentação, mas sim entrega do front-end. [DADOS INTERNOS NECESSÁRIOS: porcentagem de experimentos executados pela Switas nos últimos 24 meses que falharam em uma verificação SRM, dividida por ramificação da taxonomia, para substituir o benchmark de 6% da Microsoft por um valor deste mercado]

Onde isso falha

Esta árvore pressupõe um teste com dois braços, alocação fixa e conhecida e randomização em nível de usuário. Ela não abrange testes com múltiplos braços, que exigem o qui-quadrado completo em todos os braços, além de uma investigação para determinar qual par está desbalanceado, ou alocações variáveis, onde a proporção esperada se altera durante o teste e um qui-quadrado cumulativo é um teste inadequado. Ela também não se aplica a delineamentos randomizados por cluster ou geograficamente, onde a unidade não é o usuário e o desequilíbrio relevante reside nas características do cluster. Além disso, ela não indica se a definição da sua métrica está correta. E não é útil quando as exposições não são registradas e você está inferindo a atribuição a partir de um evento métrico, o que não é uma verificação de divisão, mas sim uma suposição.

Perguntas frequentes

Uma divisão de 51/49 é sempre um problema? Depende inteiramente de n. Com 5,000 exposições, é ruído comum; com 500,000, é um defeito quase certo. Avalie a proporção com base na tabela de detectabilidade, e não em uma regra prática de porcentagem fixa.

Posso simplesmente reavaliar os pesos dos grupos estatisticamente em vez de executar o teste novamente? Não. A reponderação corrige as contagens e mantém a seleção intacta. Os usuários que você perdeu não estão mais presentes e não eram uma amostra aleatória do grupo.

Com que frequência devo verificar o valor p do SRM? Uma vez, no final, em contagens cumulativas, a menos que sua plataforma execute um procedimento sequencial. Observar diariamente um teste qui-quadrado de horizonte fixo aumenta substancialmente os falsos alarmes.

O SRM também invalida as métricas de proteção? Sim, pelo mesmo motivo. Se os braços representam populações diferentes, uma grade de proteção plana não é mais confiável do que uma métrica primária móvel.

E se um teste A/A também mostrar uma incompatibilidade? Então o problema está na atribuição ou no pipeline de registro, não no seu tratamento. Corrija isso antes de executar qualquer outra coisa, porque está contaminando todos os testes nessa plataforma.

Os testes de redirecionamento sempre causam SRM? Nem sempre, mas elas apresentam um risco estrutural que nenhum outro projeto possui, porque a navegação adicional existe em apenas um dos braços. Se você precisar usar uma, verifique a proporção de acordo com a velocidade de conexão e o dispositivo antes de analisar qualquer métrica.

Meu tráfego é muito baixo para que a verificação signifique alguma coisa. O que fazer então? Monitore as contagens diárias de exposição bruta em busca de desvios persistentes, execute uma verificação de atribuição periódica na camada de atribuição e pré-registre uma lista mais extensa de verificações de consistência. Você está substituindo o poder estatístico pelo processo.

A filtragem de bots deve ocorrer antes ou depois da atribuição? Após o registro da exposição, antes da análise, usando regras determinísticas aplicadas de forma idêntica a ambos os braços. A filtragem heurística dentro do SDK é como o próprio filtro se torna a incompatibilidade.

Execute a verificação em seu próprio programa de experimento.

Se você deseja uma segunda opinião sobre a integridade dos testes que está executando atualmente, ou uma revisão da camada de atribuição e registro da qual todos eles dependem, é exatamente isso que nossa equipe pode oferecer. CRO e serviço de experimentação faz.

Fontes

• Fabijan, Gupchup, Gupta, Omhover, Vermeer, Dmitriev, "Diagnóstico de discrepância na proporção de amostras em experimentos controlados online: uma taxonomia e regras práticas para profissionais", KDD 2019
• Documentação do AB Tasty, Incompatibilidade na proporção de amostras (S-SRM sequencial, limite de 0.01)
• Statsig, "Um guia rápido para incompatibilidade de proporção de amostra", 31 de agosto de 2023 (qui-quadrado, limite de 0.01)
• Documentação do GrowthBook, Experimentando (qui-quadrado, aviso abaixo de 0.001)
• Imperva, "Relatório de Bots Maliciosos 2026: Bots na Era dos Agentes", 29 de abril de 2026
• Ministério do Comércio da República da Turquia, dados de comércio eletrônico de 2025, 12 de maio de 2026
• Plataforma de tags do Google, modo de consentimento e comportamento de armazenamento
• Documentação e perguntas frequentes do SRM Checker, por Lukas Vermeer