Cómo Conseguir Apoyo Ejecutivo para un Programa de Tests A/B
Cómo conseguir apoyo ejecutivo para tests A/B: las tres objeciones reales, el modelo de ROI con su techo honesto y el piloto que zanja la discusión.
📚 Este artículo es parte de la guía Cómo Construir una Cultura de Experimentación (2026).
El apoyo ejecutivo para tests A/B rara vez se pierde por los méritos de la experimentación, y casi siempre se pierde por la forma de la petición. “Queremos empezar a testear” se lee como una solicitud de presupuesto y paciencia sin retorno definido. “Lanzar cambios sin testear en este flujo nos cuesta una cantidad estimada por año, y aquí hay un piloto de duración fija que nos dirá si esa estimación es correcta” se lee como gestión de riesgo, que es un idioma que los ejecutivos ya hablan. Este artículo cubre las tres objeciones que realmente vas a enfrentar, un modelo de ROI con su techo honesto dicho en voz alta, el argumento de las pérdidas evitadas que la mayoría de los business cases omite, y cómo dimensionar un piloto que pueda tener éxito en su propio calendario. Forma parte de la guía sobre cómo construir una cultura de experimentación.
Apoyo ejecutivo para tests A/B: las tres objeciones que vas a escuchar
Las conversaciones de aprobación parecen variadas y no lo son. Casi todo rechazo se reduce a una de tres preocupaciones, y cada una tiene una respuesta específica.
| Objeción | Lo que suele significar | La respuesta que funciona |
|---|---|---|
| “Esto nos va a frenar” | Miedo a que cada lanzamiento espere semanas por un veredicto | Testea los cambios donde equivocarse sale caro; lanza el resto. El test es un filtro sobre cambios de alto riesgo, no una barrera sobre todo el trabajo |
| “Ya sabemos lo que funciona” | La experiencia pasada se está tratando como evidencia | Da la razón y propón testear la propia creencia. Si la creencia es correcta, el test cuesta dos semanas y produce un hecho documentado |
| “La herramienta cuesta demasiado” | El costo es visible y el retorno no | Pon los dos en la misma línea: ingresos anuales del flujo junto al costo del programa. La herramienta suele ser un error de redondeo frente al flujo que protege |
La segunda objeción es la que más vale la pena tomar en serio, porque muchas veces es parcialmente cierta. La gente con experiencia suele saber mucho del negocio. El replanteo productivo no es “estás equivocado”, es “el desacuerdo que hay en esta sala es exactamente lo que un test resuelve a bajo costo”. Un test que confirma la intuición del liderazgo es un buen resultado para el programa: convierte una opinión en un hecho documentado, y la siguiente discusión arranca desde un lugar más alto.
Pon el programa en dinero
El modelo es lo bastante simple como para defenderlo en una pizarra. Ingresos anuales del flujo testeado por el aumento relativo total esperado en un año, menos el costo anual del programa. El aumento relativo total es tests por año, por tasa de victoria, por el aumento medio de un test ganador.
Córrelo con tus propios números antes de citar nada:
Modelo: cada ganador suma su uplift a la conversión; el 1er año realiza cerca de la mitad del régimen (rampa). Ajusta los campos y mira el impacto en vivo.
Ejemplo trabajado
Una operación de ecommerce SaaS con 90.000 visitantes mensuales en el flujo testeado, una tasa de conversión de 2,2% y $180 de valor medio por conversión. El equipo puede correr 1,3 tests por mes, asume una tasa de victoria de un tercio en línea con los datos publicados de Microsoft, y espera un aumento medio de 4% relativo por ganador. El programa cuesta $4.000 por mes entre herramienta y horas.
- Ingresos mensuales base del flujo: 90.000 por 2,2% por $180, es decir $356.400.
- Ingresos anuales base: $4.276.800.
- Tests por año: 1,3 por 12, es decir 15,6.
- Ganadores por año: 15,6 por 0,33, es decir 5,15.
- Aumento relativo total en un año: 5,15 por 4%, es decir 20,6%.
- Ingreso incremental en régimen: $4.276.800 por 20,6%, es decir $880.679 por año.
- Realizado en el año uno (cerca de la mitad, porque las victorias entran a lo largo del año): $440.339.
- Costo anual del programa: $48.000.
- Ganancia neta del primer año: $392.339, un ROI de primer año de cerca de 817%.
Por qué ese número es un techo y no un pronóstico
Presentar el número de arriba sin el párrafo siguiente es como los programas de experimentación pierden credibilidad en su segundo año. El modelo suma aumentos de forma lineal, y la realidad no coopera por tres motivos distintos.
La maldición del ganador. Un cambio solo se lanza cuando el efecto observado supera un umbral, así que los ganadores lanzados son sistemáticamente los que además atraparon un sorteo aleatorio favorable. El aumento medido está por lo tanto sesgado hacia arriba, y el sesgo es mayor justo donde más duele: en tests con poco poder, donde solo un sorteo inusualmente afortunado podría haber cruzado la línea. Esta es una de las razones por las que testear con poco poder sale caro incluso cuando produce ganadores, un punto tratado en errores comunes en tests A/B y amenazas a la validez.
Los aumentos se solapan. Dos victorias en el mismo embudo con frecuencia capturan parte de la misma ganancia. Mejorar la página de producto y mejorar el carrito recuperan a algunos de los mismos usuarios que abandonan, así que lanzar ambas rara vez entrega la suma de los dos efectos medidos.
Algunos efectos decaen. Las ganancias impulsadas por la novedad se desvanecen cuando los usuarios recurrentes se acostumbran al cambio, y los efectos estacionales no se repiten de forma pareja durante el año.
La manera honesta de presentar esto son dos escenarios en la misma diapositiva. Manteniendo todas las demás entradas idénticas y realizando el 60% del aumento medido en lugar del 100%, el ingreso incremental en régimen es de $528.407, el ingreso realizado en el primer año es de $264.204 y la ganancia neta del primer año es de $216.204, un ROI de cerca de 450%.
El argumento que casi nadie hace: las pérdidas evitadas
Todo el business case anterior cuenta solo el tercio ganador. El argumento más fuerte para un programa de testeo vive en el tercio perdedor, y normalmente queda fuera por completo.
Según datos publicados por Ronny Kohavi sobre experimentos en Microsoft, aproximadamente un tercio de las ideas testeadas mejora la métrica objetivo, un tercio no cambia nada y un tercio la empeora (Kohavi, Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years, KDD 2015). Lee ese tercer punto despacio: son cambios que un equipo competente diseñó, en los que creyó y que construyó. Sin test, se lanzan. Con test, se atrapan con una fracción del tráfico y se revierten.
Con los mismos 15,6 tests por año, eso son unos cinco cambios al año que habrían degradado el flujo y no lo hicieron, porque fueron detectados mientras estaban expuestos a la mitad del tráfico durante dos semanas en lugar de a todo el tráfico de forma indefinida. Eso no se puede contabilizar como ingreso, y no hay que intentarlo. Lo que sí se puede decir con precisión es esto: en un flujo por el que pasan 4,3 millones de dólares al año, un programa que frena unos cinco cambios dañinos al año está comprando un seguro cuya prima es de $48.000.
Hay un corolario que conviene decir en la misma reunión, porque desarma para siempre la objeción de “esto nos frena”: sin programa de testeo, esos cinco cambios ocurren igual. Solo que se descubren más tarde, a través de una caída de métrica que nadie puede atribuir, normalmente después de que también cambiaron varias otras cosas.
Diseña un piloto que pueda salir bien
La forma más común en que muere un programa bien argumentado es un piloto prometido en un calendario que el tráfico no sostiene. Dimensiónalo antes de comprometer una fecha.
Toma el mismo flujo: 90.000 visitantes mensuales, una base de 2,2% y la ambición de detectar un aumento de 15% relativo con 95% de confianza y 80% de poder.
- Muestra por variación: 33.284 visitantes.
- Muestra total (2 variaciones): 66.568 visitantes.
- Tráfico diario: 3.000 visitantes.
- Duración: 66.568 dividido por 3.000 da 22,2, redondeado hacia arriba en días enteros de recolección, es decir 23 días por test.
Calcúlalo para tu propio flujo antes de nombrar una fecha:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Ese único número reconfigura la propuesta. Un piloto de tres tests son aproximadamente 10 semanas de tiempo corriendo, sin contar el tiempo de construcción entre tests, así que la petición honesta es un trimestre. Prometer “resultados en 30 días” en este flujo garantiza o una parada temprana (que produce una respuesta poco confiable y destruye la credibilidad del programa en su primer resultado) o un plazo incumplido.
Cuatro compromisos hacen defendible un piloto antes de empezar:
| Compromiso | Por qué protege al programa |
|---|---|
| Un solo flujo, elegido por tráfico | Un piloto en una página de poco tráfico no puede producir veredicto en ningún calendario |
| Duración fijada antes del lanzamiento | Elimina la tentación de parar en la primera lectura favorable |
| Regla de decisión escrita | “Lanzamos si el intervalo excluye el cero y las métricas de guardia se sostienen” se acuerda cuando nadie conoce el resultado |
| Las derrotas se reportan igual que las victorias | La primera derrota es la prueba de credibilidad de todo el programa |
El tercer compromiso es el que más rinde, porque se acuerda en el único momento en que todos son imparciales: antes de que existan los datos. Registrar la regla de decisión de antemano también elimina el modo de falla más común de los primeros programas, que es parar el test en cuanto el panel se ve bien. La mecánica y el costo real de ese hábito están tratados en el problema del peeking en tests A/B.
El informe de una página que los ejecutivos sí leen
Los hábitos de reporte deciden si se financia el segundo trimestre. Tres reglas lo cubren:
- Empieza por la decisión, no por la estadística. Lanzado, revertido o no concluyente, en la primera línea.
- Reporta el intervalo, no el punto. “+4,1% relativo, intervalo de +0,5% a +7,7%” fija una expectativa que los datos reales pueden cumplir. “+4,1%” fija una promesa que normalmente no pueden.
- Traduce los dos extremos del intervalo a ingresos anuales. Los ejecutivos piensan en rangos cuando se les ofrece el rango, y en números únicos cuando no.
Vale la pena adoptar un cuarto hábito una vez que el programa está corriendo: reportar resultados acumulados del programa cada trimestre, incluyendo empates y derrotas, con el escenario de ROI deflactado junto al techo original. Este es el artefacto que convierte un piloto en una línea permanente del presupuesto, porque muestra al programa corrigiendo sus propias estimaciones en lugar de defenderlas.
Errores comunes al presentar el programa
| Error | Por qué sale mal | Mejor movimiento |
|---|---|---|
| Citar la tasa de victoria de un competidor como pronóstico propio | Su tráfico, su equipo y su base no son los tuyos | Modela con los números de tu propio flujo y declara los supuestos |
| Prometer un aumento de conversión específico | El aumento es exactamente lo que no se sabe | Promete la calidad de la decisión, no el resultado |
| Presentar solo el techo | Los datos reales del año dos parecerán un fracaso | Muestra el techo y el escenario deflactado juntos |
| Pilotar en una página de poco tráfico | Ningún veredicto es posible en la ventana del piloto | Elige el flujo por tráfico y después por valor de negocio |
| Esconder la primera derrota | Las derrotas son el producto; esconderlas señala lo contrario | Reporta la primera derrota en voz alta y explica qué evitó |
| Pedir una herramienta en lugar de un programa | Las herramientas no producen decisiones, los procesos sí | Pide un trimestre, un flujo, una regla de decisión y un informe |
Hazlo automático con Donnu
Los dos números que deciden esta discusión son la duración estimada antes de comprometer una fecha, y el intervalo de confianza que reportas en lugar de una estimación puntual. Donnu produce los dos por defecto: dimensiona cada test contra tu tráfico real y muestra la duración esperada antes de empezar, y todo resultado viene con su intervalo y sus lecturas de guardia, así que el informe que llevas a la reunión es el informe que la herramienta ya generó. Nadie tiene que reconstruir el business case desde un panel.
Empieza una prueba gratis de 14 días y corre el piloto con la duración nombrada desde el principio. Para planificar la cola que necesitará un programa financiado, mira la plantilla de roadmap de experimentación.
Referencias
- Kohavi, R. Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years. Keynote, ACM SIGKDD 2015. exp-platform.com/Documents/2015-08OnlineControlledExperimentsKDDKeynoteNR.pdf.
- Thomke, S. Building a Culture of Experimentation. Harvard Business Review, marzo-abril 2020. hbr.org/2020/03/building-a-culture-of-experimentation.
- 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.
- Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020 (extracto). cambridge.org.
- Kohavi, R. ExP Platform: accelerating innovation through trustworthy experimentation. exp-platform.com.
Lee también:
- Cómo Construir una Cultura de Experimentación: un framework práctico
- ¿Cuántos Tests A/B Deberías Hacer por Mes?
- Documentación de Experimentos: un repositorio que nadie ignora
Read in English: Getting Executive Buy-In for an A/B Testing Program
Preguntas frecuentes
- ¿Cómo se consigue apoyo ejecutivo para un programa de tests A/B?
- Deja de pedir permiso para testear y empieza a poner precio a la decisión. Los ejecutivos aprueban programas que reducen el costo de equivocarse, así que el pitch que funciona tiene tres partes: los ingresos anuales que pasan por el flujo que quieres testear, la proporción de cambios que históricamente empeoran las métricas cuando se lanzan sin test, y un piloto con duración fija y una regla de decisión registrada de antemano. Pedir presupuesto de herramienta sin ninguna de esas tres partes es pedir un acto de fe.
- ¿Cuál es el argumento más fuerte para un programa de experimentación?
- Las pérdidas evitadas, no las victorias. Según datos publicados por Ronny Kohavi sobre experimentos en Microsoft, aproximadamente un tercio de las ideas testeadas empeora la métrica objetivo. Son cambios en los que el equipo creyó lo suficiente como para construirlos, y el test es lo que impidió que llegaran a todos los usuarios. La mayoría de los business cases cuenta solo el tercio ganador, lo que subestima el programa casi a la mitad y lo hace parecer mucho más especulativo de lo que es.
- ¿Cómo se calcula el ROI de un programa de tests A/B?
- Multiplica los ingresos anuales del flujo testeado por el aumento relativo total esperado en un año, donde el aumento total es igual a tests por año por tasa de victoria por aumento medio de un ganador. Resta el costo anual del programa (herramienta más horas). Trata el resultado como un techo y no como un pronóstico: este modelo suma aumentos de forma lineal, y los aumentos reales se solapan, decaen y están inflados por la maldición del ganador.
- ¿Por qué los modelos de ROI sobreestiman el retorno de la experimentación?
- Se acumulan tres razones. Los aumentos medidos están sesgados hacia arriba, porque un test solo se lanza cuando el efecto observado cruza un umbral, así que los ganadores tienden a ser los que tuvieron un sorteo favorable. Los aumentos no se suman: dos victorias en el mismo embudo suelen capturar parte de la misma ganancia dos veces. Y algunos efectos decaen después del lanzamiento, sobre todo los impulsados por la novedad. Un business case defendible muestra el techo y un escenario deflactado lado a lado.
- ¿Cuánto debe durar un programa piloto de experimentación?
- Lo suficiente para producir una respuesta estadísticamente válida en un flujo con tráfico suficiente, lo que normalmente es un trimestre y no un mes. Calcula la muestra por variación del flujo que elegiste antes de comprometer una fecha: si el flujo necesita 23 días por test, un piloto de tres tests es un compromiso de 10 semanas, y prometer resultados en 30 días deja al programa condenado a fallar en su propio calendario.
- ¿Qué debe tener el informe que un ejecutivo realmente lee?
- Una página por test: la decisión tomada, el efecto observado con su intervalo de confianza, la implicación en ingresos anuales de los dos extremos de ese intervalo, y las métricas de guardia. Reportar solo la estimación puntual invita a una promesa que los datos no sostienen. Reportar el intervalo fija una expectativa que los resultados pueden sobrevivir.