Tamaño de Equipo de CRO: benchmarks por porte
Qué dicen los datos publicados sobre el tamaño de equipo de CRO, por qué no existe benchmark de headcount por porte y cómo dimensionar por el tráfico.
📚 Este artículo es parte de la guía Cómo Construir una Cultura de Experimentación (2026).
No existe un benchmark confiable y publicado de tamaño de equipo de CRO por porte de empresa, y los que circulan en presentaciones de venta rara vez citan fuente. Lo que sí existe en el registro público es más útil que una tabla de headcount de todos modos: datos sobre si los programas tienen un dueño dedicado, sobre cuántos tests concluyen de verdad por mes los profesionales, y la aritmética de tráfico que limita lo que cualquier equipo consigue medir. Este artículo cubre qué sostiene realmente el dato publicado, por qué un headcount copiado de otra empresa es el insumo equivocado, y un método transparente para dimensionar tu equipo por el caudal. Forma parte de la guía de cómo construir una cultura de experimentación.
Qué sostiene realmente el dato publicado
Tres fuentes cargan con casi todo lo que se puede decir con honestidad sobre asignación de personas en experimentación hoy. Ninguna de ellas publica un headcount promedio por porte de empresa, y esa ausencia es, en sí misma, el hallazgo.
| Fuente | Muestra y método | Qué sostiene |
|---|---|---|
| Speero, State of Experimentation Programs 2023 | 119 encuestados que completaron la auditoría de madurez entre octubre de 2021 y diciembre de 2022, reclutados por los canales propios de la empresa | Si los programas tienen un dueño dedicado, y cómo eso se correlaciona con la madurez |
| Convert, CRO Agency and Vendor Ecosystem Report (publicado en julio de 2025, actualizado en abril de 2026) | 237 agencias identificadas en el mundo, 40 entrevistas de una hora y más de 200 respuestas de encuesta con líderes de agencia | Distribución de headcount del lado de las agencias y caudal de tests por profesional |
| VWO, Experimentation Maturity Benchmark Report 2025-2026 | Encuesta con programas de experimentación; el tamaño de la muestra no se informa en la página pública | Dónde reportan estar trabados los programas, a nivel de volumen de ejecución |
El número más citable sobre asignación de personas viene de Speero: solo el 59% de los encuestados estuvo totalmente o parcialmente de acuerdo con tener una persona dedicada y responsable de la experimentación. Desglosado por nivel de madurez, en la lectura más estricta (totalmente de acuerdo), la diferencia es abismal: 17% en el nivel menos maduro (“aspiring”), contra 92% entre los programas más maduros (“transformative”). Dos hallazgos relacionados cierran el cuadro: cerca del 91% de los encuestados sin equipo dedicado no tenía base de conocimiento para guardar aprendizajes de test, y el 57% de los equipos descentralizados también reportó no usar una.
El lado de las agencias agrega una dosis de realidad desde otro ángulo. La investigación de Convert identificó 237 agencias de CRO en el mundo y encontró que solo el 7% tenía más de 30 empleados, y que el 60% de los profesionales de agencia corre dos tests o menos por mes. Las agencias no son equipos internos, y una persona de agencia se reparte entre varios clientes, así que el número de cabezas no transfiere. El número de caudal viaja mejor: dos tests por mes es la realidad de trabajo de la mayor parte del mercado profesional, no un caso aislado de bajo desempeño.
La página del reporte de VWO encuadra la misma restricción desde el lado del comprador, afirmando que el 56% de los programas de experimentación está atrapado en un cuello de botella de ejecución y que más de la mitad de las organizaciones encuestadas está trabada en un volumen mensual bajo de tests. La página pública no informa el tamaño de la muestra, así que ese número entra en la columna “direccional”, no en la columna de evidencia.
Por qué un headcount copiado de otra empresa es el insumo equivocado
Dos empresas con la misma facturación, el mismo sector y el mismo número de empleados pueden tener tamaños de equipo sensatos completamente distintos, porque la restricción que aprieta en un programa de CRO no es el presupuesto. Es cuántos tests consigue concluir efectivamente el sitio, y ese número lo definen el tráfico y el efecto que el equipo quiere detectar.
Un equipo de seis personas en un sitio que solo concluye dos tests por mes no es un programa fuerte, son cinco personas esperando. Una persona sola en un sitio con millones de sesiones al mes no es un programa austero, es un cuello de botella dejando facturación medible sin medir. Ninguna de esas dos situaciones aparece en un benchmark de headcount, que es exactamente por qué copiar uno produce un mal plan de contratación en las dos direcciones.
Dimensiona por el caudal, no por el porte
El método honesto tiene tres pasos: calcular cuántos tests consigue concluir tu tráfico por mes, traducir eso al trabajo que cada test realmente exige, y solo entonces decidir cuántas personas necesita esa carga.
Paso 1: qué consigue concluir tu tráfico
Todo test consume visitantes, y cuántos depende de la tasa base de conversión y del menor efecto que vale la pena detectar. Con 95% de confianza y 80% de poder, bilateral, en un test de dos variaciones sobre una página convirtiendo al 3%:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
| Menor efecto que quieres detectar | Muestra por variación | Visitantes por test | Tests por mes con 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 |
La tasa base mueve la misma aritmética con la misma fuerza. Manteniendo el objetivo en 20% de mejora relativa, una página convirtiendo al 5% necesita 8.158 por variación, una al 3% necesita 13.914, y una al 2% necesita 21.109. Sobre 150 mil visitantes al mes, eso da 9,2, 5,4 y 3,6 tests por mes respectivamente, para exactamente la misma ambición.
Reparte esto por niveles de tráfico y la forma del programa se cae de madura sola:
| Visitantes por mes en las páginas testeadas | Tests por mes (base 3%, objetivo de 20% relativos) | Qué implica esa carga en la práctica |
|---|---|---|
| 50.000 | 1,8 | Un dueño, tomando tiempo prestado de diseño e ingeniería |
| 150.000 | 5,4 | Un dueño dedicado más apoyo agendado y recurrente de diseño e implementación |
| 500.000 | 18,0 | Un grupo pequeño dedicado, con capacidad de implementación y QA que ya no cabe en tiempo prestado |
| 2.000.000 | 71,9 | Varios squads en paralelo, más trabajo de plataforma para que los tests no choquen entre sí |
Usa la calculadora de duración para convertir tu tráfico en calendario, que suele ser el momento en que un plan de contratación se vuelve realista:
Aproximación normal de dos proporciones, división igual entre las variaciones. La fecha usa tu zona horaria y recalcula en vivo.
Paso 2: cuánto trabajo cuesta realmente un test
Cinco trabajos ocurren en todo experimento, no importa quién los haga:
| Trabajo | Qué produce | Dónde suele vivir primero |
|---|---|---|
| Investigación e hipótesis | Una hipótesis escrita con métrica primaria y guardrails, decidida antes de que el test corra | El dueño del programa |
| Diseño de la variación | El cambio en sí, con calidad de producción | Prestado del equipo de diseño |
| Implementación y QA | La variación en el aire, testeada en varios dispositivos, con el tracking verificado | Prestado de ingeniería, y el cuello de botella más común |
| Análisis | Un veredicto con el intervalo, leído en la fecha planificada de cierre | El dueño del programa, o un analista cuando el volumen crece |
| Documentación | El resultado en un repositorio, incluidos empates y derrotas | El trabajo que más se saltea, y el que más compone intereses con el tiempo |
El hallazgo de Speero sobre base de conocimiento merece leerse junto a esa última fila: los programas sin equipo dedicado casi nunca tienen repositorio, y los equipos descentralizados también suelen no tenerlo. La documentación no es la etapa que se corta cuando el equipo es pequeño, es la etapa que impide que un equipo pequeño rehaga trabajo que ya hizo.
Paso 3: convierte la carga en personas, y verifica contra la capacidad
La verificación que importa es simple: si el tráfico sostiene cerca de 5 tests por mes, y cada test necesita hipótesis, diseño, implementación, análisis y registro escrito, esa es una carga que un dueño dedicado carga con apoyo confiable y agendado de diseño e ingeniería. No es una carga que exija tres especialistas. En cambio, a partir de 18 tests por mes, implementación y QA deja de ser tiempo prestado y se vuelve fila, que es exactamente el “cuello de botella de ejecución” que describe el reporte de VWO.
La cuenta que decide la segunda contratación
Vale invertir la tabla del paso 1, porque así es como se vuelve argumento de presupuesto. Manteniendo los mismos parámetros (base de 3%, objetivo de 20% relativos, 27.828 visitantes por test), este es el tráfico mensual que exige cada nivel de caudal:
| Caudal deseado | Tráfico mensual necesario en las páginas testeadas |
|---|---|
| 2 tests por mes | cerca de 55.700 visitantes |
| 5 tests por mes | cerca de 139.100 visitantes |
| 10 tests por mes | cerca de 278.300 visitantes |
| 18 tests por mes | cerca de 500.900 visitantes |
La lectura práctica: por debajo de algo en torno a 280 mil visitantes al mes en las páginas testeadas, la segunda contratación dedicada difícilmente se paga en caudal, porque el tráfico no sostiene el volumen de tests que justificaría a la persona. Lo que suele pagarse antes de eso no es una segunda cabeza en CRO, es destrabar la etapa de implementación (una ventana fija de ingeniería por sprint, por ejemplo), que aumenta el caudal sin aumentar el equipo. Esta es una derivación de la aritmética de arriba, no un benchmark de mercado: cambia la tasa base y el efecto objetivo por los tuyos y el umbral se mueve.
Centralizado, embebido o centro de excelencia
La estructura importa tanto como el tamaño, y cada modelo falla de una manera.
| Modelo | Dónde vive la experimentación | Forma de fallar típica |
|---|---|---|
| Equipo centralizado | Un equipo es dueño de estrategia, ejecución y análisis | Se vuelve fila, y los equipos de producto dejan de proponer tests porque la espera es larga |
| Embebido en los squads de producto | Cada squad corre sus propios experimentos | El método se dispersa, y vale el hallazgo de Speero: el 57% de los equipos descentralizados reportó no tener base de conocimiento común, así que el trabajo se repite |
| Centro de excelencia | Un grupo central pequeño es dueño del método, la estadística y el repositorio; los squads ejecutan | Solo funciona si el centro tiene autoridad real sobre cómo se lee el resultado, si no se vuelve decoración consultiva |
El patrón que atraviesa los tres: sea cual sea la forma, alguien tiene que ser dueño del método y de la memoria. Una estructura donde nadie es dueño de la lectura estadística es como un programa termina con tasa de victoria alta y ninguna facturación detrás, el patrón de falla cubierto en cuántos tests A/B correr por mes.
Errores comunes al dimensionar un equipo de CRO
| Error | Por qué cuesta caro |
|---|---|
| Copiar headcount de una empresa con tráfico distinto | El tamaño del equipo está limitado por los tests medibles, y ese techo lo define el tráfico, no la facturación ni el sector |
| Contratar un especialista antes de que exista un dueño | La diferencia de madurez de Speero es sobre propiedad dedicada; un especialista sin nadie responsable hereda la misma fragmentación |
| Dimensionar para un volumen de tests que el tráfico no sostiene | Crea presión para correr tests subdimensionados, lo que infla la tasa de victoria y desinfla el efecto realizado |
| Tratar la etapa de implementación como tiempo prestado gratis | Es la etapa con más chance de volverse cuello de botella apenas el volumen pasa de media docena de tests por mes |
| Cortar documentación para ir más rápido | Los programas sin repositorio repiten trabajo, y el dato muestra que eso es la regla, no la excepción |
| Contar headcount de agencia como benchmark | El personal de agencia se reparte entre muchos clientes; solo el dato de caudal transfiere |
Haz esto automático con Donnu
Dos de los cinco trabajos de la tabla de arriba son costo puro de operación que una herramienta debería absorber: dimensionar el test correctamente antes de empezar y leer el resultado con honestidad al final. Donnu A/B hace los dos por defecto, calculando la muestra que tu tráfico realmente sostiene antes de que el test corra, reportando el intervalo al lado del efecto en lugar de un número de confianza solitario, y manteniendo cada experimento registrado con los números congelados tal como se leyeron. Eso no reemplaza a una persona dueña del programa, ni pretende hacerlo: quita las dos etapas donde un equipo pequeño más pierde tiempo o credibilidad.
Si tu programa tiene una persona de profundidad y quieres que esa persona gaste la semana en hipótesis en lugar de en planillas, empieza una prueba gratis de 14 días y dimensiona el próximo test contra tu tráfico real primero.
Referencias
- Speero. The State of Experimentation Programs 2023. Encuesta con 119 respondentes de la auditoría de madurez de Speero, fuente de los números de propiedad dedicada y de base de conocimiento. speero.com/post/the-state-of-experimentation-programs-2023.
- Convert. CRO Agency Stats y el CRO Agency and Vendor Ecosystem Report. 237 agencias identificadas, 40 entrevistas y más de 200 respuestas de encuesta; fuente del 7% por encima de 30 empleados y del 60% que corre dos tests o menos por mes. convert.com/blog/optimization/cro-agency-stats.
- VWO. Experimentation Maturity Benchmark Report 2025-2026. Fuente del 56% atrapado en cuello de botella de ejecución; el tamaño de la muestra no se informa en la página pública. vwo.com/ebooks/experimentation-maturity-benchmark-report.
- Kohavi, R. y 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, marzo-abril de 2020. hbr.org/2020/03/building-a-culture-of-experimentation.
Lee también: Cómo construir una cultura de experimentación · Cuántos tests A/B correr por mes · Plantilla de roadmap de experimentación · Repositorio de documentación de experimentos · CRO para sitios de bajo tráfico
Preguntas frecuentes
- ¿Cuál es el tamaño promedio de un equipo de CRO?
- No existe un promedio publicado y confiable por porte de empresa, y a quien cite uno habría que pedirle la fuente. Lo que muestra el dato público es otra cosa: Speero encontró que solo el 59% de los programas encuestados estaba totalmente o parcialmente de acuerdo con tener una persona dedicada y responsable de la experimentación, y que en la lectura más estricta (totalmente de acuerdo) la porción sube del 17% en el nivel menos maduro al 92% entre los programas más maduros. O sea, el benchmark honesto no es un número de cabezas, es si alguien es dueño del programa.
- ¿Cuántas personas hacen falta para correr un programa de CRO?
- Empieza por el caudal, no por el headcount. La cantidad de tests que tu sitio consigue concluir por mes está limitada por el tráfico y por el efecto que quieres detectar: una página convirtiendo al 3%, testeada para 20% de mejora relativa con 95% de confianza y 80% de poder, consume cerca de 27.828 visitantes por test de dos variaciones. Con 150 mil visitantes al mes en las páginas testeadas, eso da cerca de 5 tests por mes, y 5 tests por mes es una carga que una persona dedicada con apoyo parcial de diseño e ingeniería sostiene de verdad. Contratar más allá de lo que el tráfico consigue medir compra capacidad ociosa.
- ¿Qué roles necesita realmente un equipo de CRO?
- En cualquier tamaño, cinco trabajos tienen que ocurrir: investigación e hipótesis, diseño de la variación, implementación y QA, análisis estadístico y documentación del resultado. En un programa de una persona, los cinco quedan en la misma persona, que toma tiempo prestado de diseño e ingeniería. Conforme el caudal pasa de unos diez tests por mes, implementación y QA suele ser el primero en justificar capacidad dedicada, porque es la etapa que traba todo lo que viene después cuando se atrasa.
- ¿CRO debe ser centralizado o vivir dentro de los equipos de producto?
- Los dos modelos funcionan, y la forma de fallar es distinta en cada uno. El dato de Speero apunta un riesgo concreto en el caso descentralizado: el 57% de los equipos descentralizados reportó no usar una base de conocimiento para documentar experimentos y aprendizajes, que es como el mismo test termina corriendo dos veces en dos squads. Un equipo centralizado concentra método y memoria, pero puede volverse una fila que todos esperan. El punto medio práctico es propiedad central del método, de la estadística y del repositorio, con la ejecución distribuida.
- ¿El tamaño de las agencias de CRO dice algo sobre equipos internos?
- Poco, y conviene saber qué transfiere y qué no. La investigación de Convert identificó 237 agencias de CRO en el mundo y encontró que solo el 7% tenía más de 30 empleados, además de reportar que el 60% de los profesionales de agencia corre dos tests o menos por mes. El número de cabezas no transfiere, porque una persona de agencia se reparte entre varios clientes mientras un equipo interno se concentra en un solo sitio, con un solo techo de tráfico. En cambio el dato de caudal viaja bien: dos tests por mes es la realidad de la mayor parte del mercado profesional, no una excepción floja.
- ¿Cuál es la primera contratación de un programa de experimentación?
- Un dueño, antes que cualquier especialista. El dato de Speero sobre madurez muestra la propiedad dedicada separando programas maduros de aspirantes con mucha más nitidez que cualquier otra variable de recurso, y la falla más común en un programa joven no es la falta de un estadístico, es que la experimentación sea responsabilidad secundaria de todos y, por lo tanto, prioridad de nadie. La segunda contratación debe decidirse por el cuello de botella que expusieron los primeros seis meses, que suele ser capacidad de implementación o de análisis, no las dos.