CRO Não É Teste A/B: O Que a Claro Aprendeu Depois de 8 Anos Rodando Experimentos

Índice

1. •Growth, dados, CRO: três nomes para a mesma pessoa sobrecarregada
2. •Por que reduzir CRO a teste A/B é prejudicial para o setor
3. •O teste A/B sozinho não escala, e o mercado finge que não sabe disso
4. •80% dos experimentos falham. Isso não é o problema
5. •As duas métricas que provam o valor de CRO para o negócio
6. •Quem deveria mandar no roadmap: produto ou experimentação?
7. •IA em CRO: onde funciona e onde é só discurso de palco
8. •Bate-bola: o que perguntamos e o que Marcola respondeu sem pensar
9. •Como a Métricas Boss ajuda a estruturar isso
10. •FAQ

1. Growth, dados, CRO: três nomes para a mesma pessoa sobrecarregada

Hoje é raro encontrar uma empresa que admita não ter growth, não ter dados, não ter CRO. O problema aparece quando você cava um pouco mais fundo: não tem nenhum dos três. Tem uma pessoa fazendo um pouco de tudo, rodando testes A/B eventuais só para justificar que "tem alguma coisa acontecendo".

Foi esse o ponto de partida da conversa no episódio 276 do Analytics Talks, gravado durante o Web Summit, com Marco Antônio Cardozo, o Marcola, líder de Growth Digital e responsável pela otimização de jornadas digitais na Claro, além de embaixador da comunidade CRO Brasil. Ele estrutura o framework de experimentação da operadora desde 2018, o que dá ao papo um raro nível de maturidade prática, construída ao longo de oito anos de tentativa e erro em escala nacional.

E o recado central do episódio pode ser resumido assim: CRO não é uma ferramenta que você instala. É uma cultura que você constrói. E a maior parte do mercado ainda está confundindo as duas coisas.

2. Por que reduzir CRO a teste A/B é prejudicial para o setor

Marcola foi direto: chamar CRO de "time de teste A/B" é a mesma redução equivocada que a área de Analytics sofreu anos atrás, quando virou sinônimo de "time que faz relatório". Teste A/B é apenas uma das formas de validar hipótese dentro de CRO. E validar hipótese, na definição que ele defende, é ouvir o cliente de forma estruturada, com dados e fatos, para embasar uma decisão.

Existe uma camada inteira de ferramentas que atua antes, durante e depois do teste A/B, e que o mercado costuma tratar como acessório:

• •Teste de usabilidade e validação de protótipo: falar direto com o cliente, inclusive presencialmente (a Claro já fez isso em loja física e até em estação de metrô).
• •Análise de funil de conversão: cruzando Analytics com gravações de sessão e mapa de calor para achar onde a jornada dispersa.
• •Pesquisa qualitativa ao longo do teste: para entender por que o cliente abandona, não só que ele abandona.

A analogia que resume o argumento: essas ferramentas funcionam como camadas de cebola. Elas entram no Discovery (antes de gerar a hipótese), na validação (durante o teste) e na interpretação (depois do resultado). Tratá-las como opcionais é o motivo pelo qual tanta operação de CRO nasce capenga, só com a ferramenta de teste, sem a camada de investigação que gera hipóteses boas o suficiente para valer o esforço de desenvolvimento.

3. O teste A/B sozinho não escala, e o mercado finge que não sabe disso

Aqui está uma causa técnica que a maioria dos decisores ignora: teste A/B depende de massa de dados para significância estatística, e isso tem prazo. Dependendo do volume de tráfego, um teste pode levar de 30 a 40 dias para produzir um resultado confiável, mesmo abrindo uma amostra generosa, de 50% da audiência.

Marcola contou um caso real de negociação comercial: um cliente reclamou que a proposta de CRO entregava "só dois testes por mês", enquanto ele "já fazia oito". A resposta foi direta: fazer oito testes por mês com volume de tráfego insuficiente é achismo com verniz de dado, disfarçado de método. Sem relevância estatística, o resultado que a ferramenta mostra não passa de opinião com dashboard.

O problema não está no teste A/B em si, mas na ilusão de que rodar mais testes, mais rápido, é sinônimo de mais maturidade. Volume de teste sem rigor estatístico sai mais caro do que não testar nada, porque você paga a ferramenta, paga o time e ainda toma decisão errada.

4. 80% dos experimentos falham. Isso não é o problema

Este é o dado mais afiado do episódio: cerca de 80% dos experimentos de CRO terminam inconclusivos ou sem variante vencedora. A maioria das empresas trata esse número como fracasso de time, mas Marcola trata como o núcleo do trabalho. Isso conecta direto com um vício do mercado: só comemora e só publica case quando existe variante vencedora, e ninguém documenta o que não funcionou, o porquê, e o que aquilo ensinou sobre o comportamento do cliente. Comemorar apenas a vitória e ignorar o aprendizado é otimizar para o ego, não para o negócio.

Um detalhe pouco discutido: teste inconclusivo é diferente de "não aconteceu nada". Ele elimina uma hipótese, revela um viés que estava guiando a priorização, e evita que o time de desenvolvimento suba, no escuro, algo que nunca teria gerado resultado. Isso tem valor, só que é um valor difícil de defender em uma reunião de board, e por isso o mercado prefere não falar sobre ele.

Outro ponto que separa operação amadora de operação madura: reciclagem de teste. Um teste que não funcionou há dois anos pode voltar a funcionar hoje, porque consumidor, concorrência e produto mudam. Se uma jornada está "parada" há dois anos sem novo teste, isso já é sintoma de estagnação.

5. As duas métricas que provam o valor de CRO para o negócio

Para blindar a área contra o corte de orçamento, a Claro reporta resultado de experimentação em duas frentes:

5.1. Potencial incremental

O ganho direto de receita, cadastro, login (ou o que for a meta de negócio) gerado pelas variantes vencedoras. Aqui está um detalhe de maturidade: a Claro não exige 95% de confiança estatística como padrão universal. Em jornadas de menor risco, trabalha com 90%, porque, como coloca Marcola, um teste de e-commerce errado não é um erro médico: ninguém morre, e dá para reverter. O resultado desse tipo de teste já alimenta diretamente o backlog de produto no Jira, priorizando histórias pelo potencial incremental comprovado.

5.2. Economia gerada

A métrica que ninguém cobra, mas que sustenta os outros 80% dos testes (os inconclusivos). É o cálculo de quanto a empresa economizou em horas de desenvolvimento por não subir, às cegas, uma hipótese que o teste provou não gerar impacto, e quanto ela evitou perder caso aquela mudança tivesse ido ao ar sem validação. Somando as duas métricas, CRO deixa de ser custo e vira linha de receita e de mitigação de risco: o argumento que realmente convence um CFO, ao contrário de "a gente testa uns botões por aí".

6. Quem deveria mandar no roadmap: produto ou experimentação?

Pergunta provocada no episódio: hoje, na maioria das empresas, é o time de produto e UX que decide a melhoria e simplesmente sobe no sprint. Marcola defende a inversão: melhoria deveria passar por teste antes de subir ao ar. Exceção óbvia: correção de bug e sustentação técnica não precisam de validação prévia. Mas até decisão de infraestrutura pode virar teste. Comparar duas versões de uma API, por exemplo, para ver qual performa melhor, também é CRO, só que aplicado à camada de tecnologia em vez da de UX.

A realidade, porém, é mais dura: boa parte do mercado opera em "piloto automático", recebendo decisões top-down, sem hábito de questionar. Mudar esse mindset é trabalho político, não técnico. E cansa. O episódio traz um caso real e cru: uma analista júnior, tentando convencer o dono de um e-commerce a testar a jornada em vez de culpar mídia e preço pela queda de conversão, chegou perto de desistir da carreira porque o cliente recusava, com unhas e dentes, a possibilidade de o próprio site ter um problema.

A resistência não é técnica. É de ego. Aceitar que a jornada pode estar errada exige humildade de quem construiu ela, e é exatamente aí que a maioria das operações de CRO trava antes mesmo de rodar o primeiro teste.

Na Claro, a saída para escalar sem depender de bater na porta de cada squad foi trazer um desenvolvedor dedicado ao setup dos experimentos, o que tirou o time de CRO da posição de "pedir 5 minutos de atenção" e deu tração real ao framework.

7. IA em CRO: onde funciona e onde é só discurso de palco

Depois de discutir o tema em eventos internacionais como o London Circus, a visão de Marcola sobre IA aplicada a CRO é pragmática: dificilmente ela substitui o processo inteiro, porque o custo não compensa e a estrutura toda precisaria mudar. O ganho real está em atacar gaps específicos, como geração de hipótese, montagem de protótipo, setup técnico do experimento e documentação pós-análise, e a lente por trás disso é simples: a IA amplifica o processo que já existe, para o bem ou para o mal.

Dois pontos ficam explícitos no episódio:

• •A responsabilidade continua sendo humana. Se um teste sobe mal configurado, ou uma hipótese não tem lastro em dado, ou alguém pausa um teste antes do prazo de significância estatística, a culpa é de quem operou a IA. Tratar a ferramenta como uma "entidade" separada da decisão humana é o erro mais comum.
• •IA depende de tracking correto. Sem dado limpo entrando, a IA "vai cuspir merda". Na Claro, a ferramenta interna de teste A/B puxa dados do Google Analytics e cruza com dados proprietários e mapas de calor para gerar hipóteses baseadas nos pontos reais de maior fricção da jornada. Um processo sólido por trás faz a IA acelerar; um processo furado faz ela entregar o erro mais rápido e em maior volume.

8. Bate-bola: o que perguntamos e o que Marcola respondeu sem pensar

Um adendo importante da rodada rápida: para Marcola, o profissional de UX que se apoia em dado é sempre mais forte do que o que se apoia só em intuição de design. A dupla dados + UX dentro do próprio squad de produto é, na visão dele, o que separa operação que escala de operação que fica no "voo de galinha".

9. Como a Métricas Boss ajuda a estruturar isso

O que o episódio expõe, na prática, é um problema de arquitetura de decisão: empresas testam sem tracking confiável, sem camada de Discovery, sem governança de documentação, e depois se perguntam por que o CRO "não converte". A Métricas Boss atua exatamente nesse ponto anterior ao teste: auditoria de tracking, estruturação de funil de dados e desenho de framework de experimentação com critério estatístico real, para que, quando um teste for declarado vencedor, ele tenha, de fato, significância por trás.

Se a sua operação está travada nos "8 testes por mês sem relevância estatística" ou não sabe como provar o valor dos experimentos inconclusivos, esse é exatamente o tipo de diagnóstico que fazemos todos os dias. Fale com um de nossos especialistas e conheça os serviços de auditoria de tracking e estruturação de CRO da Métricas Boss.

10. FAQ

1. •CRO é a mesma coisa que teste A/B? Não. Teste A/B é uma ferramenta de validação de hipótese dentro de CRO. CRO também inclui teste de usabilidade, pesquisa qualitativa, análise de funil, gravação de sessão e mapa de calor.
2. •Por que a maioria dos testes A/B não dá em variante vencedora? Porque a validação de hipótese é probabilística por natureza. No mercado, cerca de 80% dos experimentos terminam inconclusivos ou sem vencedor, e isso já é esperado dentro do método.
3. •É preciso sempre esperar 95% de confiança estatística para declarar um teste vencedor? Depende do risco da jornada. Em cenários de baixo risco (ninguém "morre" com o erro, e dá para reverter), é possível trabalhar com um patamar menor, como 90%, aceitando conscientemente uma fatia maior de incerteza.
4. •Quanto tempo leva para um teste A/B dar resultado confiável? Varia de poucos dias, em jornadas de altíssimo tráfego, a 30 ou 40 dias em cenários de volume médio ou baixo. É por isso que "rodar muitos testes por mês" sem volume suficiente costuma ser sinal de alerta sobre a metodologia usada.
5. •Um teste que falhou no passado pode ser testado de novo? Sim, e deveria ser. Comportamento do consumidor, produto e concorrência mudam, e reciclar hipóteses antigas com o contexto atualizado é prática comum em operações maduras de CRO.
6. •Quem deve validar um teste depois que ele sobe no ar? O próprio time de CRO, em um processo de "prova real": mesmo depois de vencer estatisticamente, é preciso confirmar, algumas semanas depois, se o resultado incremental esperado realmente se sustentou fora do ambiente controlado do teste.
7. •IA já substitui o analista de CRO na geração de hipóteses? Não substitui. Apoia etapas específicas (geração de hipótese, prototipagem, documentação), mas depende de tracking limpo, e a responsabilidade pela decisão final continua sendo humana.

Baseado no episódio 276 do Analytics Talks, "CRO Além do Teste A/B: A Maturidade que Ninguém Conta", com Marco Antônio Cardozo (Marcola), líder de Growth Digital na Claro e embaixador da comunidade CRO Brasil.

Assista ao episódio na íntegra:

Gustavo Esteves

Gustavo Esteves é fundador e CEO da Métricas Boss, já trabalhou dentro de gigantes como B2W. Autoridade na área de Digital Analytics, com mais de 15 anos de experiência e 3 mil projetos atendidos, incluindo gigantes como PUC, Rede D'Or, Globo, Stanley, Médico Sem Fronteiras, Alura, entre outras.

Publicado em 3 de julho de 2026