Tamanho de Equipe de CRO: benchmarks por porte
O que os dados publicados realmente dizem sobre tamanho de equipe de CRO, por que não existe benchmark de headcount por porte e como dimensionar pelo tráfego.
📚 Este artigo faz parte do guia Como Construir uma Cultura de Experimentação (2026).
Não existe benchmark confiável e publicado de tamanho de equipe de CRO por porte de empresa, e os que circulam em apresentação de venda raramente citam fonte. O que existe no registro público é mais útil do que uma tabela de headcount de qualquer forma: dado sobre se os programas têm um dono dedicado, sobre quantos testes profissionais de verdade concluem por mês, e a aritmética de tráfego que limita o que qualquer time consegue medir. Este artigo cobre o que o dado publicado realmente sustenta, por que um headcount copiado de outra empresa é o insumo errado, e um método transparente para dimensionar a sua equipe pela vazão. Faz parte do guia de como construir uma cultura de experimentação.
O que o dado publicado realmente sustenta
Três fontes carregam quase tudo que dá para dizer com honestidade sobre alocação de pessoas em experimentação hoje. Nenhuma delas publica um headcount médio por porte de empresa, e essa ausência é, em si, o achado.
| Fonte | Amostra e método | O que ela sustenta |
|---|---|---|
| Speero, State of Experimentation Programs 2023 | 119 respondentes que completaram a auditoria de maturidade entre outubro de 2021 e dezembro de 2022, recrutados pelos canais próprios da empresa | Se os programas têm um dono dedicado, e como isso se correlaciona com maturidade |
| Convert, CRO Agency and Vendor Ecosystem Report (publicado em julho de 2025, atualizado em abril de 2026) | 237 agências identificadas no mundo, 40 entrevistas de uma hora e mais de 200 respostas de pesquisa com líderes de agência | Distribuição de headcount do lado das agências e vazão de testes por profissional |
| VWO, Experimentation Maturity Benchmark Report 2025-2026 | Pesquisa com programas de experimentação; o tamanho da amostra não é informado na página pública | Onde os programas relatam estar travados, no nível de volume de execução |
O número mais citável sobre alocação de pessoas vem da Speero: apenas 59% dos respondentes concordaram totalmente ou em parte que tinham uma pessoa dedicada e responsável pela experimentação. Quebrado por nível de maturidade, na leitura mais estrita (concorda totalmente), a diferença é gritante: 17% no nível menos maduro (“aspiring”), contra 92% entre os programas mais maduros (“transformative”). Dois achados relacionados fecham o quadro: cerca de 91% dos respondentes sem time dedicado não tinham base de conhecimento para guardar aprendizados de teste, e 57% dos times descentralizados também relataram não usar uma.
O lado das agências acrescenta uma dose de realidade por outro ângulo. A pesquisa da Convert identificou 237 agências de CRO no mundo e encontrou que só 7% tinham mais de 30 funcionários, e que 60% dos profissionais de agência rodam dois testes ou menos por mês. Agências não são times internos, e uma pessoa de agência se divide entre vários clientes, então o número de cabeças não transfere. O número de vazão viaja melhor: dois testes por mês é a realidade de trabalho da maior parte do mercado profissional, não um caso isolado de baixo desempenho.
A página do relatório da VWO enquadra a mesma restrição pelo lado do comprador, afirmando que 56% dos programas de experimentação estão presos num gargalo de execução e que mais da metade das organizações pesquisadas está travada num volume mensal baixo de testes. A página pública não informa o tamanho da amostra, então esse número entra na coluna “direcional”, não na coluna de evidência.
Por que um headcount copiado de outra empresa é o insumo errado
Duas empresas com a mesma receita, o mesmo setor e o mesmo número de funcionários podem ter tamanhos de time sensatos completamente diferentes, porque a restrição que aperta num programa de CRO não é orçamento. É quantos testes o site consegue efetivamente concluir, e esse número é definido pelo tráfego e pelo efeito que o time quer detectar.
Um time de seis pessoas num site que só conclui dois testes por mês não é um programa forte, são cinco pessoas esperando. Uma pessoa sozinha num site com milhões de sessões por mês não é um programa enxuto, é um gargalo deixando receita mensurável sem medição. Nenhuma dessas duas situações aparece num benchmark de headcount, que é exatamente por que copiar um produz plano de contratação ruim nas duas direções.
Dimensione pela vazão, não pelo porte
O método honesto tem três passos: calcular quantos testes o seu tráfego consegue concluir por mês, traduzir isso no trabalho que cada teste realmente exige, e só então decidir de quantas pessoas essa carga precisa.
Passo 1: o que o seu tráfego consegue concluir
Todo teste consome visitantes, e quantos depende da taxa base de conversão e do menor efeito que vale detectar. Com 95% de confiança e 80% de poder, bicaudal, num teste de duas variações sobre uma página convertendo a 3%:
Cálculo por aproximação normal de duas proporções, 2 variações (50/50). Mexa nos campos e veja o impacto ao vivo.
| Menor efeito que você quer detectar | Amostra por variação | Visitantes por teste | Testes por mês com 150 mil visitantes |
|---|---|---|---|
| +30% relativos | 6.455 | 12.910 | 11,6 |
| +20% relativos | 13.914 | 27.828 | 5,4 |
| +15% relativos | 24.193 | 48.386 | 3,1 |
| +10% relativos | 53.211 | 106.422 | 1,4 |
A taxa base mexe na mesma aritmética com a mesma força. Mantendo o alvo em 20% de melhora relativa, uma página convertendo a 5% precisa de 8.158 por variação, uma a 3% precisa de 13.914, e uma a 2% precisa de 21.109. Sobre 150 mil visitantes por mês, isso dá 9,2, 5,4 e 3,6 testes por mês respectivamente, para a mesmíssima ambição.
Espalhe isso por níveis de tráfego e o formato do programa cai de maduro sozinho:
| Visitantes por mês nas páginas testadas | Testes por mês (base 3%, alvo de 20% relativos) | O que essa carga implica na prática |
|---|---|---|
| 50.000 | 1,8 | Um dono, pegando tempo emprestado de design e engenharia |
| 150.000 | 5,4 | Um dono dedicado mais apoio agendado e recorrente de design e implementação |
| 500.000 | 18,0 | Um pequeno grupo dedicado, com capacidade de implementação e QA que já não cabe em tempo emprestado |
| 2.000.000 | 71,9 | Vários squads em paralelo, mais trabalho de plataforma para os testes não colidirem entre si |
Use a calculadora de duração para converter o seu tráfego em calendário, que costuma ser o momento em que um plano de contratação fica realista:
Aproximação normal de duas proporções, divisão igual entre as variações. A data usa o seu fuso e recalcula ao vivo.
Passo 2: quanto trabalho um teste realmente custa
Cinco trabalhos acontecem em todo experimento, não importa quem os faça:
| Trabalho | O que produz | Onde costuma morar primeiro |
|---|---|---|
| Pesquisa e hipótese | Uma hipótese escrita com métrica primária e guardrails, decidida antes de o teste rodar | O dono do programa |
| Desenho da variação | A mudança em si, com qualidade de produção | Emprestado do time de design |
| Implementação e QA | A variação no ar, testada em vários dispositivos, com rastreamento conferido | Emprestado da engenharia, e o gargalo mais comum |
| Análise | Um veredito com o intervalo, lido na data planejada de encerramento | O dono do programa, ou um analista quando o volume cresce |
| Documentação | O resultado num repositório, incluindo empates e derrotas | O trabalho mais pulado, e o que mais compõe juros ao longo do tempo |
O achado da Speero sobre base de conhecimento merece ser lido junto dessa última linha: programas sem time dedicado quase nunca têm repositório, e times descentralizados também costumam não ter. Documentação não é a etapa que se corta quando o time é pequeno, é a etapa que impede um time pequeno de refazer trabalho que já fez.
Passo 3: converta a carga em pessoas, e confira contra a capacidade
A conferência que importa é simples: se o tráfego sustenta cerca de 5 testes por mês, e cada teste precisa de hipótese, desenho, implementação, análise e registro escrito, essa é uma carga que um dono dedicado carrega com apoio confiável e agendado de design e engenharia. Não é uma carga que exija três especialistas. Já a partir de 18 testes por mês, implementação e QA deixa de ser tempo emprestado e vira fila, que é exatamente o “gargalo de execução” que o relatório da VWO descreve.
A conta que decide a segunda contratação
Vale inverter a tabela do passo 1, porque é assim que ela vira argumento de orçamento. Mantendo os mesmos parâmetros (base de 3%, alvo de 20% relativos, 27.828 visitantes por teste), este é o tráfego mensal que cada nível de vazão exige:
| Vazão desejada | Tráfego mensal necessário nas páginas testadas |
|---|---|
| 2 testes por mês | cerca de 55.700 visitantes |
| 5 testes por mês | cerca de 139.100 visitantes |
| 10 testes por mês | cerca de 278.300 visitantes |
| 18 testes por mês | cerca de 500.900 visitantes |
A leitura prática: abaixo de algo em torno de 280 mil visitantes por mês nas páginas testadas, a segunda contratação dedicada dificilmente se paga em vazão, porque o tráfego não sustenta o volume de testes que justificaria a pessoa. O que costuma se pagar antes disso não é uma segunda cabeça em CRO, é destravar a etapa de implementação (uma janela fixa de engenharia por sprint, por exemplo), que aumenta a vazão sem aumentar o time. Esta é uma derivação da aritmética acima, não um benchmark de mercado: troque a taxa base e o efeito-alvo pelos seus e o limiar se move.
Centralizado, embarcado ou centro de excelência
Estrutura importa tanto quanto tamanho, e cada modelo falha de um jeito.
| Modelo | Onde a experimentação mora | Modo de falhar típico |
|---|---|---|
| Time centralizado | Um time é dono de estratégia, execução e análise | Vira fila, e os times de produto param de propor teste porque a espera é longa |
| Embarcado nos squads de produto | Cada squad roda os próprios experimentos | O método se dispersa, e vale o achado da Speero: 57% dos times descentralizados relataram não ter base de conhecimento comum, então o trabalho se repete |
| Centro de excelência | Um grupo central pequeno é dono de método, estatística e repositório; os squads executam | Só funciona se o centro tiver autoridade real sobre como o resultado é lido, senão vira decoração consultiva |
O padrão que atravessa os três: qualquer que seja o formato, alguém precisa ser dono do método e da memória. Uma estrutura em que ninguém é dono da leitura estatística é como um programa termina com taxa de vitória alta e nenhuma receita atrás, o padrão de falha coberto em quantos testes A/B rodar por mês.
Erros comuns ao dimensionar uma equipe de CRO
| Erro | Por que custa caro |
|---|---|
| Copiar headcount de uma empresa com tráfego diferente | O tamanho do time é limitado pelos testes mensuráveis, e quem define esse teto é o tráfego, não a receita nem o setor |
| Contratar especialista antes de existir um dono | A diferença de maturidade da Speero é sobre propriedade dedicada; um especialista sem ninguém responsável herda a mesma fragmentação |
| Dimensionar para um volume de teste que o tráfego não sustenta | Cria pressão para rodar teste subdimensionado, o que infla a taxa de vitória e desinfla o efeito realizado |
| Tratar a etapa de implementação como tempo emprestado grátis | É a etapa com mais chance de virar gargalo assim que o volume passa de meia dúzia de testes por mês |
| Cortar documentação para andar mais rápido | Programas sem repositório repetem trabalho, e o dado mostra que isso é a regra, não a exceção |
| Contar headcount de agência como benchmark | Pessoal de agência se divide entre muitos clientes; só o dado de vazão transfere |
Faça isso automático na Donnu
Dois dos cinco trabalhos da tabela acima são custo puro de operação que uma ferramenta deveria absorver: dimensionar o teste corretamente antes de começar e ler o resultado com honestidade no fim. A Donnu A/B faz os dois por padrão, calculando a amostra que o seu tráfego realmente sustenta antes de o teste rodar, reportando o intervalo ao lado do efeito em vez de um número de confiança solitário, e mantendo cada experimento registrado com os números congelados como foram lidos. Isso não substitui uma pessoa dona do programa, e nem pretende: tira as duas etapas em que um time pequeno mais perde tempo ou credibilidade.
Se o seu programa tem uma pessoa de profundidade e você quer essa pessoa gastando a semana com hipótese em vez de planilha, comece um teste grátis de 14 dias e dimensione o próximo teste contra o seu tráfego real primeiro.
Referências
- Speero. The State of Experimentation Programs 2023. Pesquisa com 119 respondentes da auditoria de maturidade da Speero, fonte dos números de propriedade dedicada e de base de conhecimento. speero.com/post/the-state-of-experimentation-programs-2023.
- Convert. CRO Agency Stats e o CRO Agency and Vendor Ecosystem Report. 237 agências identificadas, 40 entrevistas e mais de 200 respostas de pesquisa; fonte dos 7% acima de 30 funcionários e dos 60% que rodam dois testes ou menos por mês. convert.com/blog/optimization/cro-agency-stats.
- VWO. Experimentation Maturity Benchmark Report 2025-2026. Fonte dos 56% presos em gargalo de execução; tamanho da amostra não informado na página pública. vwo.com/ebooks/experimentation-maturity-benchmark-report.
- Kohavi, R. e Thomke, S. The Surprising Power of Online Experiments. Harvard Business Review, 2017. hbr.org/2017/09/the-surprising-power-of-online-experiments.
- Thomke, S. Building a Culture of Experimentation. Harvard Business Review, março-abril de 2020. hbr.org/2020/03/building-a-culture-of-experimentation.
Leia também: Como construir uma cultura de experimentação · Quantos testes A/B rodar por mês · Template de roadmap de experimentação · Repositório de documentação de experimentos · CRO para sites de baixo tráfego
Perguntas frequentes
- Qual é o tamanho médio de uma equipe de CRO?
- Não existe média publicada e confiável por porte de empresa, e quem citar uma deveria ser cobrado pela fonte. O que o dado público mostra é outra coisa: a Speero encontrou que apenas 59% dos programas pesquisados concordavam totalmente ou em parte que tinham uma pessoa dedicada e responsável pela experimentação, e que na leitura mais estrita (concorda totalmente) a fatia sobe de 17% no nível menos maduro para 92% entre os programas mais maduros. Ou seja, o benchmark honesto não é um número de cabeças, é se alguém é dono do programa.
- Quantas pessoas são necessárias para rodar um programa de CRO?
- Comece pela vazão, não pelo headcount. O número de testes que o seu site consegue concluir por mês é limitado pelo tráfego e pelo efeito que você quer detectar: uma página convertendo a 3%, testada para 20% de melhora relativa com 95% de confiança e 80% de poder, consome cerca de 27.828 visitantes por teste de duas variações. Com 150 mil visitantes por mês nas páginas testadas, isso dá cerca de 5 testes por mês, e 5 testes por mês é uma carga que uma pessoa dedicada com apoio parcial de design e engenharia sustenta de verdade. Contratar além do que o tráfego consegue medir compra capacidade ociosa.
- Quais papéis uma equipe de CRO realmente precisa?
- Em qualquer tamanho, cinco trabalhos precisam acontecer: pesquisa e hipótese, desenho da variação, implementação e QA, análise estatística e documentação do resultado. Num programa de uma pessoa, os cinco ficam com a mesma pessoa, que pega tempo emprestado de design e engenharia. Conforme a vazão passa de cerca de dez testes por mês, implementação e QA costuma ser o primeiro a justificar capacidade dedicada, porque é a etapa que trava tudo que vem depois quando atrasa.
- CRO deve ser centralizado ou dentro dos times de produto?
- Os dois modelos funcionam, e o modo de falhar é diferente em cada um. O dado da Speero aponta um risco concreto no caso descentralizado: 57% dos times descentralizados relataram não usar uma base de conhecimento para documentar experimentos e aprendizados, que é como o mesmo teste acaba rodando duas vezes em dois squads. Um time centralizado concentra método e memória, mas pode virar uma fila que todo mundo espera. O meio-termo prático é propriedade central do método, da estatística e do repositório, com a execução distribuída.
- O tamanho das agências de CRO diz algo sobre times internos?
- Pouco, e vale saber o que transfere e o que não transfere. A pesquisa da Convert identificou 237 agências de CRO no mundo e encontrou que só 7% tinham mais de 30 funcionários, além de relatar que 60% dos profissionais de agência rodam dois testes ou menos por mês. O número de cabeças não transfere, porque uma pessoa de agência se divide entre vários clientes enquanto um time interno se concentra num site só, com um teto de tráfego só. Já o dado de vazão viaja bem: dois testes por mês é a realidade da maior parte do mercado profissional, não uma exceção fraca.
- Qual é a primeira contratação de um programa de experimentação?
- Um dono, antes de qualquer especialista. O dado da Speero sobre maturidade mostra a propriedade dedicada separando programas maduros dos aspirantes com muito mais nitidez do que qualquer outra variável de recurso, e a falha mais comum num programa jovem não é a falta de um estatístico, é a experimentação ser responsabilidade secundária de todo mundo e, portanto, prioridade de ninguém. A segunda contratação deve ser decidida pelo gargalo que os primeiros seis meses expuseram, que costuma ser capacidade de implementação ou análise, não os dois.