Atribuyendo Ingresos al Ganador de tu Test A/B
Cómo atribuir ingresos test A/B al ganador correcto: RPV frente a ingresos totales, estacionalidad, outliers de ticket e ingreso incremental anualizado.
📚 Este artículo es parte de la guía GA4 y Test A/B: la Guía Completa de Integración.
Cuando un test A/B termina y el informe muestra la variación B con más ingresos totales que la variación A, la tentación es declarar ganador e implementar de inmediato. El problema es que el ingreso total bruto, por sí solo, no prueba ninguna causalidad: no controla el tamaño de la muestra ni el ticket medio, los dos factores que ya discutimos en detalle en la guía completa de GA4 y test A/B como parte de lo que una herramienta de analítica muestra pero no decide por sí sola. Esta guía se centra solo en la etapa final de ese proceso: cómo atribuir ingresos al ganador correcto de un test A/B, aislando lo que vino de la variación de lo que vino de una muestra desigual, de la estacionalidad y de los outliers de ticket alto.
Por qué “la variación con más ingresos” no prueba nada por sí sola
El ingreso total es la suma de todo lo que una variación generó en un período. Parece la métrica más obvia para decidir un test, porque al final de cuentas es lo que entra en caja. Pero el ingreso total tiene un defecto estructural: crece con el número de visitantes, no solo con la calidad de la variación. Dos variaciones pueden tener la misma tasa de conversión y el mismo ticket medio, y aun así una de ellas mostrar un ingreso total mucho mayor, simplemente porque recibió más tráfico en ese período (asignación desigual, retraso en el inicio de una de las variaciones, o incluso un test que se ejecuta en fases distintas).
La métrica que aísla ese efecto es el ingreso por visitante (RPV): ingreso total dividido por el número de visitantes de esa variación, en el mismo período. Es el mismo denominador de una tasa de conversión, solo que el numerador es dinero en lugar de un conteo de eventos.
Un ejemplo concreto ayuda a fijar por qué esto importa. Supón un test de checkout ejecutándose con una asignación de tráfico desigual entre las dos variaciones (un escenario común cuando el test empieza con un despliegue gradual):
La tabla siguiente muestra los números completos detrás del gráfico:
| Variación | Visitantes | Ingreso total | RPV (ingreso ÷ visitantes) |
|---|---|---|---|
| A (control) | 6.000 | R$ 13.200 | R$ 2,20 |
| B | 9.000 | R$ 17.100 | R$ 1,90 |
| Diferencia | +50% de tráfico en B | +29,5% en B | -13,6% en B |
La variación B se llevó un 50% más de visitantes en el mismo recorte, y eso por sí solo ya explica el ingreso total mayor. Mirando por el ingreso por visitante, el cuadro se invierte: A convierte mejor y/o tiene mejor ticket medio por persona que pasó por la página, aun habiendo recibido menos tráfico. Sin controlar por tamaño de muestra, cualquier lectura de “quién tuvo más ingresos” está comparando manzanas con naranjas.
El RPV como métrica primaria, no el ingreso total bruto
Una vez que el RPV es el denominador correcto, vale la pena entender de dónde viene. El RPV no es una métrica nueva, es el producto de dos que ya conoces:
RPV = tasa de conversión × ticket medio (ingreso medio por pedido)
Esto explica por qué el RPV es la métrica de decisión más honesta para cualquier test que toque ingresos: una variación puede convertir peor y aun así ganar en RPV, si la ganancia de ticket medio compensa la pérdida de volumen, y lo contrario también es cierto. Juzgar solo por la conversión, como ya vimos en otra guía de este blog, ignora la mitad de la ecuación; juzgar solo por el ingreso total ignora la otra mitad (el tamaño de la muestra). El RPV es el único de los tres que responde a la pregunta correcta: “¿cada visitante que pasó por esa variación valió más en dinero?”.
Esto no significa que el RPV sea perfecto. Tiende a tener mayor varianza que una tasa de conversión simple, justamente porque incorpora el valor del pedido, que suele ser bastante más disperso que un evento binario de sí/no. Por eso el RPV nunca debería leerse aislado, sin una prueba de significancia detrás (más adelante en esta guía reproducimos ese cálculo paso a paso). Y, antes de calcular cualquier RPV, hay que garantizar que el número de visitantes contado por variación viene del mismo tipo de evento en las dos puntas, algo que ya cubrimos en detalle en la guía de cómo rastrear eventos de test A/B en GA4: sin un evento de impresión consistente por variación, el denominador del RPV ya nace torcido.
Aislando el efecto del test de la estacionalidad
El RPV resuelve el problema del tamaño de muestra, pero no resuelve un segundo problema, igualmente común: comparar variaciones que se ejecutaron en ventanas de tiempo distintas. Un error frecuente es leer el ingreso de la variación B en el informe del mes actual y compararlo con el ingreso que la variación A tenía antes de ser sustituida, semanas o meses atrás. Esa comparación mezcla dos efectos que después no se pueden separar: el que vino de la variación testada y el que vino del calendario (festivo, día de pago, campaña de medios pagados en paralelo, temporada de ventas del sector).
La regla es simple de enunciar y fácil de olvidar en la práctica: A y B necesitan ejecutarse simultáneamente, en la misma ventana de tiempo, con el tráfico dividido entre las dos al mismo tiempo, nunca en secuencia. Solo así cualquier diferencia de RPV observada puede atribuirse a la variación en sí, y no al momento en que cada una se ejecutó.
| Escenario de comparación | Qué mide en realidad | ¿Válido para atribuir ingresos al test? |
|---|---|---|
| A y B ejecutándose al mismo tiempo, tráfico dividido simultáneamente | Efecto de la variación, aislado del calendario | Sí |
| A el mes pasado, B sustituyendo a A este mes | Efecto de la variación mezclado con el efecto del calendario (estacionalidad, campañas, festivos) | No |
| A y B al mismo tiempo, pero en fuentes de tráfico distintas (A solo orgánico, B solo pagado) | Efecto de la variación mezclado con el efecto del canal de adquisición | No, a menos que la fuente de tráfico también esté controlada |
| A y B al mismo tiempo, misma fuente de tráfico, misma ventana | Efecto de la variación, aislado del calendario y del canal | Sí |
Un detalle que aparece con frecuencia en equipos que hacen una migración gradual de una página antigua a una nueva: si la variación nueva entra en producción sustituyendo a la antigua en lugar de ejecutarse en paralelo con ella, técnicamente ya no existe un test A/B, existe un antes y después. El antes y después puede ser útil como señal direccional, pero no permite atribuir con confianza ninguna diferencia de ingresos al cambio, porque el calendario siempre está junto en el “después” y nunca estuvo junto en el “antes”.
El problema de los outliers de ticket alto
A diferencia de una tasa de conversión, que siempre es 0 o 1 por visitante, el ingreso por pedido puede variar mucho: la mayoría de los pedidos queda cerca del ticket medio, y un pedido aislado de valor muy alto puede por sí solo tirar la media de una variación hacia arriba, sin representar el comportamiento típico de quien pasó por ahí. Según Kohavi, Tang y Xu, en Trustworthy Online Controlled Experiments, las métricas de ingresos suelen tener distribución de cola pesada exactamente por ese motivo, y limitar (winsorizar) el peso de valores extremos es una práctica estándar en experimentación para reducir la varianza sin descartar datos. Un estudio técnico más reciente sobre métricas de monetización en experimentos de ranking (Pokharna y colegas, arXiv 2606.04110, 2026) refuerza el punto: en métricas de ingresos, una fracción muy pequeña de los usuarios de mayor valor puede dominar la varianza del test entero, lo suficiente para distorsionar el cálculo de significancia si no se trata.
Un ejemplo con números reales ilustra el tamaño del problema. Supón 12 pedidos registrados en la variación B durante la ventana del test, siendo 11 de ellos próximos al ticket típico de la tienda y 1 de ellos un pedido corporativo aislado de R$ 5.400:
Los 12 valores usados aquí fueron: R$ 89, R$ 120, R$ 145, R$ 99, R$ 156, R$ 110, R$ 134, R$ 99, R$ 125, R$ 143, R$ 118 y el pedido de R$ 5.400. La media de los 12 valores es R$ 561,50; la mediana es R$ 122,50; y la media recalculada sin el pedido de R$ 5.400 baja a R$ 121,64, casi idéntica a la mediana. Si usaras la media con el outlier para calcular el ticket medio de esa variación y proyectar ingresos, estarías proyectando con base en un número que ningún otro pedido de esa ventana se acerca a reproducir.
La salida práctica, documentada tanto en el libro de Kohavi, Tang y Xu como en el estudio técnico citado arriba, no es descartar el pedido grande (es una venta real, y descartarlo sin criterio se convierte en manipulación de datos): es reportar la mediana junto a la media, o limitar (winsorizar) valores por encima de un percentil alto (el percentil 99 es una referencia común en la literatura de experimentación) antes de calcular el ticket medio que alimenta la proyección de ingresos. Eso preserva el pedido en el conteo de conversiones, pero evita que él solo decida el resultado del test.
Ejemplo trabajado: de la significancia al ingreso anualizado
El camino completo para atribuir ingresos a un ganador de test A/B tiene dos etapas, y las dos necesitan ocurrir en ese orden: primero confirmar que la diferencia de conversión es estadísticamente significativa (no solo ruido de muestra), y solo después proyectar lo que esa diferencia vale en ingresos a lo largo de un año. Saltarse la primera etapa e ir directo a la segunda es como proyectar ingresos de un resultado que quizá ni siquiera sea real.
Supón un test en el checkout de una tienda: la variación A (control) tuvo 8.000 visitantes y 320 conversiones; la variación B tuvo 8.000 visitantes y 376 conversiones, ejecutándose en la misma ventana de tiempo, sin outliers de ticket relevantes en ese recorte.
- Tasa de A: 320 ÷ 8.000 = 4,00%. Tasa de B: 376 ÷ 8.000 = 4,70%.
- Mejora relativa: (0,0470 − 0,0400) ÷ 0,0400 = +17,5%.
- Tasa combinada p̄: (320 + 376) ÷ 16.000 = 4,35%.
- Error estándar: √[0,0435 · 0,9565 · (1÷8.000 + 1÷8.000)] ≈ 0,003225.
- Puntuación z: (0,0470 − 0,0400) ÷ 0,003225 ≈ 2,17.
- Valor p (bilateral) ≈ 0,030.
Con un valor p de 0,030 (por debajo del corte de 0,05) y el intervalo de confianza del 95% de la diferencia variando de aproximadamente +0,07 a +1,33 puntos porcentuales (sin cruzar el cero), el resultado es estadísticamente significativo: la variación B convierte más, y no es solo ruido de una muestra pequeña. Solo ahora, con la significancia confirmada, tiene sentido proyectar lo que esa ganancia vale en ingresos. Comprueba la misma cuenta en la calculadora de abajo, pegando los números de tu propio informe:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
Con la significancia confirmada, el siguiente paso es la calculadora de ROI de tests A/B de este blog, que usa exactamente esta cuenta: multiplicar la ganancia de tasa de conversión por el ticket medio y por el tráfico anual proyectado. Suponiendo que esa página recibe 100.000 visitantes por mes (1.200.000 por año) y el ticket medio de la tienda es R$ 180, el ingreso incremental anualizado de cambiar A por B es:
ingreso incremental = tráfico anual × (tasa objetivo − tasa actual) × ticket medio
ingreso incremental = 1.200.000 × (0,0470 − 0,0400) × 180 = R$ 1.512.000 por año
La tabla resume los dos cálculos, desde la prueba de significancia hasta la proyección de ingresos:
| Etapa | Entrada | Resultado |
|---|---|---|
| Significancia (prueba z de dos proporciones) | 8.000/320 (A) frente a 8.000/376 (B) | z ≈ 2,17 · p ≈ 0,030 · significativo · gana B |
| Intervalo de confianza del 95% de la diferencia | mismos datos de arriba | +0,07 a +1,33 puntos porcentuales |
| Ingreso incremental anualizado | tráfico 1.200.000/año · ticket medio R$ 180 | R$ 1.512.000 por año |
Fíjate en que el ingreso incremental proyectado aquí usa la diferencia de tasa de conversión, no el ingreso total observado durante el test: así es como la proyección queda inmune al tamaño de muestra que el test efectivamente tuvo. El test se ejecutó con 8.000 visitantes por variación para probar que el efecto es real; la proyección de R$ 1.512.000 por año usa ese efecto comprobado aplicado al tráfico real del embudo, no al tráfico pequeño del experimento.
Hazlo automático en Donnu
Todo lo que esta guía describió (separar RPV de ingreso total, garantizar que las dos variaciones se ejecutan en la misma ventana de tiempo, tratar outliers de ticket con sentido común y solo proyectar ingresos después de confirmar la significancia) es trabajo manual que la mayoría de los equipos rehace desde cero en cada test, y es exactamente donde la atribución de ingresos más se equivoca: decide demasiado pronto, con el número equivocado. En Donnu, la división de tráfico entre variaciones ocurre siempre en la misma ventana de tiempo por construcción (no existe “ejecutar A en un mes y B en otro”), y el cálculo de significancia honesto queda disponible en cuanto la muestra lo permite, para que nunca confundas ingreso total con ingreso por visitante, ni celebres una ganancia antes de que sea estadísticamente real.
Empieza una prueba gratis en Donnu y deja la división de tráfico simultánea y el cálculo de significancia a cargo de la herramienta, mientras tú te centras en decidir con el número correcto: RPV, no ingreso total. Para el panorama completo de cómo encajan la analítica y el test A/B, mira la guía completa de GA4 y test A/B.
Referencias
- Optimizely. Revenue per visitor (definición, RPV como producto de conversión y ticket medio, y aviso sobre el ruido de la métrica). optimizely.com/optimization-glossary/revenue-per-visitor.
- Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoyo en experimentguide.com.
- Pokharna, H. et al. Variance Reduction for Heavy-Tailed Monetization Metrics in Ranking Experiments via Post-Stratification. arXiv, 2026. arxiv.org/html/2606.04110.
Lee también: GA4 y test A/B: la guía completa de integración · Cómo rastrear eventos de test A/B en GA4 · Calculadora de ROI de tests A/B
Preguntas frecuentes
- ¿Por qué la variación con más ingresos totales no siempre es la ganadora real de un test A/B?
- Porque el ingreso total bruto no controla dos factores que cambian el resultado por sí solos: el tamaño de la muestra (más visitantes tienden a generar más ingreso bruto incluso con un desempeño por visitante peor) y el ticket medio (un solo pedido grande puede inflar el total sin representar el comportamiento típico de la variación). La métrica que aísla el efecto real es el ingreso por visitante (RPV): ingreso total dividido por los visitantes de esa variación, en el mismo período de tiempo.
- ¿Qué es el RPV (ingreso por visitante) y por qué debería ser la métrica primaria en lugar del ingreso total?
- El RPV es el ingreso total generado dividido por el número de visitantes en el mismo período, y equivale, en la práctica, a la tasa de conversión multiplicada por el ticket medio. Según el glosario de Optimizely, el RPV es la cantidad de dinero generada en cada visita al sitio, y puede subir tanto por la conversión como por el ticket medio. Como el RPV normaliza por el número de visitantes, permite comparar variaciones con volúmenes de tráfico distintos sin que el tamaño de la muestra distorsione la lectura, aunque la propia Optimizely advierte que el RPV puede ser un indicador ruidoso, por lo que debe leerse junto a una prueba de significancia, nunca aislado.
- ¿Un pedido de ticket muy alto en medio del test puede inviabilizar la lectura de ingresos?
- Sí, y es un riesgo real en métricas de ingresos, a diferencia de la tasa de conversión, que siempre es 0 o 1 por visitante. Según Kohavi, Tang y Xu, en Trustworthy Online Controlled Experiments, las métricas de ingresos suelen tener distribución de cola pesada, y limitar (winsorizar) valores extremos es una práctica estándar para reducir la influencia de los outliers sin descartar a los usuarios. Un estudio técnico de 2026 sobre métricas de monetización en experimentos de ranking (Pokharna y colegas, arXiv 2606.04110) muestra que una fracción muy pequeña de usuarios de altísimo valor puede dominar la varianza de ingresos de un test entero. En la práctica: reporta la mediana junto a la media, y considera winsorizar valores por encima de un percentil alto, manteniendo el pedido en el conteo pero limitando cuánto pesa en la comparación.
- ¿Puedo comparar el ingreso de la variación B en un mes con el ingreso de la variación A registrado en otro mes?
- No, esa comparación no aísla el efecto del test. La estacionalidad (fechas señaladas, día de pago, campañas de medios en paralelo, clima) cambia el comportamiento de compra de forma independiente de la variación testada, así que cualquier diferencia de ingresos entre ventanas de tiempo distintas mezcla el efecto del test con el efecto del calendario. La regla es ejecutar A y B en la misma ventana de tiempo, simultáneamente, y solo entonces comparar el RPV entre ellas.