Multi-Armed Bandits para Tests de Precio (2026)

Un test de precios es el único lugar donde el “costo de mostrar la variación perdedora” deja de ser una abstracción: cada visitante que ve el precio equivocado es una venta potencialmente perdida o margen perdido, ahora mismo, no un dato que interpretarás más tarde. Ese único hecho es la razón por la que los multi-armed bandits, y el muestreo de Thompson en particular, aparecen en conversaciones de precios mucho más seguido que en un test de titular o de color de botón. Esta guía cubre por qué el ingreso por visitante, no la tasa de conversión, tiene que ser la señal de recompensa en un test de precios, recorre un ejemplo numérico resuelto con el mismo motor estadístico que corre las calculadoras de este blog, y es honesta sobre la única cosa que un bandit todavía no puede darte: un veredicto estadístico formal y defendible.

Por qué los tests de precios sangran diferente que un test de copy

Todo test A/B que corre con una división fija paga un costo de oportunidad mientras está corriendo: la mitad del tráfico sigue viendo la variación que, eventualmente, resulta ser la más débil, durante todo el tiempo que el test tarda en alcanzar el tamaño de muestra planeado. Para un titular o un color de CTA, ese costo suele ser pequeño y recuperable, unos pocos puntos porcentuales de conversión en una métrica que se reinicia con el próximo test.

Un test de precios es un animal distinto. La “pérdida” por mostrar el precio equivocado no es una señal suave, es dinero: un visitante al que se le muestra un precio demasiado alto para convertir simplemente se va, y un visitante al que se le muestra un precio demasiado bajo convierte a una tasa que subestima lo que el negocio podría haber cobrado de esa misma persona. Ambas direcciones del error se acumulan linealmente con cada visitante que pasa por el test mientras la división fija se mantiene, y a diferencia de un test de titular, normalmente no puedes “recuperarlo después”: un visitante que se va después de una mala experiencia de precio no suele volver a intentar una mejor.

Este es el mismo trade-off que la guía de multi-armed bandits vs test A/B de este blog enmarca en términos generales: un bandit reduce el costo de oportunidad de una división fija desplazando tráfico hacia el brazo con mejor desempeño mientras el test todavía está corriendo, al costo de no producir un veredicto estadístico clásico al final. Los precios son simplemente el caso donde ese costo de oportunidad es más literal y más caro, que es exactamente por qué es el ejemplo más nítido de cuándo vale la pena asumir el trade-off.

La señal de recompensa que realmente importa: ingreso por visitante

Esta es la trampa en la que cae un test de precios ingenuo: si optimizas puramente por tasa de conversión, el precio más barato que pruebes va a ganar, casi por construcción. Bajar un precio casi siempre aumenta la proporción de visitantes que compran. Eso no significa que aumente el ingreso.

La métrica que realmente responde “cuál precio es mejor para el negocio” es el ingreso por visitante (RPV, revenue per visitor): la tasa de conversión multiplicada por el precio cobrado a cada visitante que convierte. Un precio que convierte a menos visitantes todavía puede ser la mejor opción si los convierte a un valor lo bastante alto como para compensar de sobra la tasa de conversión más baja. Este es precisamente el caso de métrica numérica que la documentación de los proveedores sobre bandits trata de forma distinta a una métrica de conversión simple: la propia documentación de soporte de Optimizely describe correr un bandit Epsilon-Greedy para métricas numéricas como el ingreso, usando estimadores estadísticos robustos de la media, la varianza y la asimetría de la distribución de la métrica para construir los límites de confianza que el algoritmo necesita, en vez de la matemática más simple que permite una métrica de conversión binaria.

Los números detrás de esa figura se desarrollan paso a paso más adelante en esta guía, pero la dirección del punto se sostiene en general: elegir la métrica de recompensa no es una formalidad en un test de precios, decide qué precio terminas lanzando.

Cómo un bandit protege el margen mientras el test todavía está corriendo

Un bandit, en el caso general, reasigna el tráfico hacia el brazo que en ese momento tiene mejor desempeño en la métrica de recompensa elegida, en vez de mantener una división fija hasta que se alcanza un tamaño de muestra predeterminado, como hace un test A/B clásico. El muestreo de Thompson, ya cubierto en profundidad en la guía de muestreo de Thompson de este blog, es el algoritmo más usado en sistemas bayesianos de producción: mantiene una distribución de creencia sobre la recompensa real de cada precio, sortea un valor aleatorio de cada distribución para cada visitante nuevo, y dirige a ese visitante hacia el precio que sorteó el valor más alto. Los precios con poco dato tienen distribuciones anchas e inciertas y aun así se muestrean seguido; los precios con mucho dato y una recompensa claramente débil tienen distribuciones estrechas y bajas y se sortean cada vez menos, sin llegar nunca a cortarse por completo.

Aplicado a un test de precios, ese comportamiento se traduce directamente en el punto de dolor: conforme se acumula evidencia de que un precio produce más ingreso por visitante, el bandit le manda más tráfico, lo que significa que menos visitantes ven el precio más débil durante el resto del test. Un test A/B clásico 50/50, por el contrario, mantiene la división plana desde el primer visitante hasta el último, a propósito, porque mover la división a mitad del test es exactamente lo que comprometería el veredicto formal que está construido para producir.

El bandit y el test A/B bayesiano comparten la misma matemática de fondo, la diferencia está puramente en qué haces con ella: decidir el tráfico en tiempo real como un bandit, o reportar una probabilidad y un veredicto una sola vez, al final, como hace un test A/B bayesiano o frecuentista clásico.

Un ejemplo numérico resuelto: el mismo test de precios, de tres formas

Para ir más allá del concepto, aquí hay un escenario concreto, calculado con la misma función significance del motor stats.ts de este blog que corre la calculadora más abajo en esta página.

El escenario: una página de upgrade de trial a pago de un SaaS recibe 10.000 visitantes en una semana. El precio A es el precio actual, $29 por mes, que convierte al 8,0% (400 de 5.000 visitantes a los que se les mostró ese precio). El precio B es un precio más alto que se está probando, $39 por mes, que convierte a un 6,4% más bajo (320 de 5.000 visitantes). Este tamaño de efecto exacto, una línea base del 8% que cae a 6,4%, una caída relativa del 20%, necesita cerca de 4.921 visitantes por variante para un poder del 80% con 95% de confianza, usando la fórmula congelada sampleSizePerVariant de este blog; los 5.000 visitantes por brazo de este escenario quedan justo por encima de esa barra, así que este es un test correctamente dimensionado, aunque sin margen de sobra, no una muestra pequeña con suerte.

Precio	Visitantes	Conversiones	Tasa de conversión	Ingreso por visitante
A ($29)	5.000	400	8,0%	$2,32
B ($39)	5.000	320	6,4%	$2,50

Qué dice el veredicto A/B clásico

Corre estos números exactos, 5.000 visitantes y 400 conversiones para A, 5.000 visitantes y 320 conversiones para B, en la calculadora de abajo (usa el mismo test z de dos proporciones que el ejemplo trabajado) para ver el veredicto tú mismo:

Control (A)

VisitantesConversiones

Variación (B)

VisitantesConversiones

Confianza90%95%99%

Control (A) · Tasa-

Variación (B) · Tasa-

Mejora relativa-

valor-p-

IC 95% de la diferencia-

Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.

Trabajando los mismos números a mano: la tasa combinada (pooled) es 7,2%, el error estándar da aproximadamente 0,00517, y el z-score es aproximadamente -3,10, lo que da un valor p bilateral de aproximadamente 0,002, bien por debajo del umbral habitual de 0,05. Leído solo por tasa de conversión, este es un resultado estadísticamente significativo, y A es declarado ganador, ya que convierte a una tasa más alta con un intervalo de confianza del 95% sobre la diferencia de aproximadamente -2,6 a -0,6 puntos porcentuales, un rango que excluye el cero.

Ese veredicto es significativo, y también es la respuesta de negocio equivocada, si la pregunta real era cuál precio genera más dinero. El ingreso por visitante de A es 8,0% por $29, o sea $2,32. El ingreso por visitante de B es 6,4% por $39, o sea $2,50, una mejora relativa de aproximadamente +7,6% a favor de B. Un test de precios que solo reporta el veredicto de tasa de conversión de arriba lanzaría con confianza el precio de menor margen. Esta es exactamente la razón por la que la señal de recompensa tiene que ser el ingreso por visitante desde el principio, no la tasa de conversión con una nota mental de “revisar el ingreso también” después; para cuando un test A/B fijo declara un ganador por tasa de conversión, el precio equivocado ya puede parecer validado.

El mismo tráfico total, corrido como bandit en su lugar

Ahora toma los mismos 10.000 visitantes idénticos y la misma ventana de una semana idéntica, pero deja que un bandit reasigne el tráfico hacia B (el precio de mayor ingreso) conforme se acumula evidencia, ilustrado aquí en tres fases en vez de continuamente, para mantener la aritmética auditable:

Fase	Días	Visitantes (aprox.)	Asignación para B (mayor ingreso)	Asignación para A
1: todavía incierto	1 a 2	~2.857	50%	50%
2: la evidencia se acumula	3 a 5	~4.286	70%	30%
3: evidencia fuerte	6 a 7	~2.857	85%	15%

Sumando a lo largo de las tres fases, A recibe cerca de 3.143 visitantes y B cerca de 6.857. El ingreso esperado da:

• A: 3.143 x $2,32 ≈ $7.292.
• B: 6.857 x $2,496 ≈ $17.115.
• Ingreso total ilustrativo con bandit: ≈ $24.407.

Compara eso contra el diseño fijo 50/50 y el techo teórico de enviar a todos los visitantes a B desde el primer día:

La ventaja del bandit aquí, cerca de $327, o aproximadamente 1,4% más de ingreso que el diseño fijo durante esta única semana, se ve modesta a esta escala. No es el número principal que vale la pena recordar. El número que vale la pena recordar es que esta ganancia se acumula durante todo el tiempo que el precio siga activo y el tráfico siga fluyendo, lo que para una decisión de precio, a diferencia de un test de titular único, suele medirse en meses o años, no en una semana. Una ventaja porcentual pequeña y estructural sobre el ingreso continuo es algo materialmente distinto de la misma ventaja porcentual en un test que corre una vez y termina.

Nota también lo que este ejemplo trabajado deliberadamente no hace: no corre el helper incrementalRevenue de stats.ts, porque esa función multiplica una diferencia de tasa por un único valor promedio de pedido compartido, lo cual encaja en un escenario de mismo precio, como un test de flujo de checkout, no en un escenario donde el precio mismo difiere por brazo. Reutilizarlo aquí aplicaría mal la fórmula a un caso para el que no fue construida; el enfoque honesto, mostrado arriba, es calcular el ingreso por visitante directamente para cada precio y comparar los totales.

Bandits contextuales para precios basados en segmento

Un bandit simple busca un único precio campeón para todo el mundo. Un bandit contextual va un paso más allá: elige el precio que se muestra a cada visitante según atributos como el nivel de plan, el tamaño de la empresa, la geografía o el historial de uso, en vez de asumir que un precio le sienta igual de bien a todos los visitantes. La documentación de Optimizely sobre bandits contextuales describe exactamente este patrón, personalizando una decisión usando atributos como dispositivo, ubicación o señales de comportamiento en vez de servir la misma variación a todo el mundo.

Para precios, esto se traduce en una situación real y común: el precio que un registro individual self-serve va a tolerar rara vez es el precio que un comprador enterprise con una línea de presupuesto dedicada va a tolerar, y un test de precio único te obliga a promediar entre ambos, lo cual puede esconder una respuesta genuina por segmento. Un bandit contextual puede, en principio, aprender un precio efectivo distinto por segmento de forma continua, en vez de requerir un test A/B fijo separado para cada segmento que te importe.

Vale la pena señalar aquí una restricción específica y verificable, en vez de una general: la propia documentación de Optimizely sobre bandits contextuales afirma que el ingreso no debería usarse directamente como métrica de optimización principal para ese modo, porque puede perjudicar la efectividad del modelo, una advertencia que no aplica a un bandit estándar no contextual. Ese es exactamente el tipo de detalle que cambia entre lanzamientos de proveedores, así que trátalo como una razón para revisar la documentación vigente antes de configurar un bandit contextual alrededor de una métrica de ingreso, no como una regla permanente.

La personalización adicional también multiplica la cuestión de equidad que se cubre a continuación: un bandit contextual que converge silenciosamente en “el segmento X paga menos que el segmento Y” está haciendo exactamente lo que se le indicó, optimizar la métrica de recompensa, y esa es precisamente la razón por la que la decisión de qué atributos son aceptables para fijar precio no puede dejarse en manos del algoritmo.

El lado legal y de equidad de probar precios

Esta sección es una señal de alerta, no asesoría legal; consulta con un abogado antes de lanzar cualquier personalización de precios, y esto cambia según la jurisdicción y se mueve rápido. Dicho esto, hay tres cosas que vale la pena saber antes de optimizar un precio por segmento:

• La discriminación y personalización de precios son, como categoría, generalmente legales, pero muy escrutadas. Una revisión de 2019 en el Journal of Business Ethics enmarca la personalización algorítmica de precios como una práctica cuya legalidad rara vez es la restricción vinculante; su eticidad y la percepción de equidad por parte de las personas que pagan precios distintos por lo mismo suele importar más en la práctica.
• Los reguladores están vigilando activamente esta práctica específica. Según una alerta a clientes de WilmerHale sobre precios personalizados, la Comisión Federal de Comercio de EE. UU. (FTC) ha estudiado la llamada “fijación de precios por vigilancia” (surveillance pricing), y la Ley de Divulgación de Precios Algorítmicos de Nueva York, vigente desde noviembre de 2025, exige que las empresas que fijan un precio usando datos personales de un visitante divulguen ese hecho en la página. Varios otros estados de EE. UU. han presentado proyectos de ley similares. Trata cualquier cifra o ley específica aquí como una fotografía del momento, y confirma la regla vigente en tu jurisdicción antes de confiar en ella.
• Las preguntas técnica y legal son separadas, y ambas aplican. Un bandit o bandit contextual que decide mostrar un precio más alto a un segmento es una decisión de negocio y legal disfrazada de pregunta estadística. El algoritmo va a optimizar cualquier métrica y cualquier atributo que le des; decidir qué atributos son aceptables para fijar precio es una decisión humana y documentada, no algo que se infiere de en qué convergió el modelo.

Nada de esto es una razón para evitar experimentos de precios. Es una razón para mantener una decisión humana y documentada sobre qué atributos están dentro de los límites permitidos, separada del algoritmo que optimiza dentro de esos límites.

Cuándo un test A/B clásico sigue siendo la mejor opción

Un bandit se gana su lugar para el ajuste continuo de un precio dentro de un rango ya aprobado, por ejemplo, subiendo o bajando un porcentaje de descuento o una duración de trial conforme se acumula evidencia, donde el costo de una conjetura equivocada es continuo y la decisión no necesita defenderse ante nadie más allá del equipo que la corre.

Un test A/B clásico de división fija sigue siendo la herramienta correcta cuando:

• La decisión necesita un veredicto defendible. Una decisión de precios a nivel de consejo, como si subir el precio de portada de un plan principal, generalmente necesita un número con un nivel de confianza asociado, un valor p y un intervalo de confianza, no “el ingreso mejoró sobre una división igualitaria.” Esa es exactamente la frase que la guía de significancia estadística de este blog recorre con un ejemplo trabajado comparable.
• El precio nuevo necesita analizarse por segmento o canal después. Una división estable y conocida hace posible preguntar, después de los hechos, si el precio nuevo se desempeñó de forma distinta por canal de adquisición o por cohorte. La asignación de un bandit, al haber cambiado por sí sola durante el test, dificulta ese tipo de segmentación limpia posterior.
• El cambio está cerca de ser irreversible o caro de deshacer. Reprecificar toda una línea de producto, o eliminar un precio heredado (grandfathered) legado, es el tipo de decisión que quieres tomar una sola vez, con una respuesta formal, en vez de ajustar continuamente.

Muchos equipos, con razón, usan los dos en secuencia: un test A/B clásico para decidir si un precio nuevo está validado siquiera, y un bandit después para seguir ajustando dentro del rango que ese test ya aprobó.

Hazlo Automático con Donnu

La tensión central de esta guía es específica de los precios: cada visitante al que se le muestra el precio perdedor durante un test de división fija es un golpe directo al margen o una venta perdida, no una señal suave que puedas ignorar hasta que el test termine. Donnu ya corre sobre un motor bayesiano nativo, la misma base estadística que necesita un bandit como el muestreo de Thompson, y te dice honestamente cuando un test de precios todavía no tiene suficiente dato para confiar en su veredicto, en vez de dejarte leer un “ganador” prematuro en el ruido y quemar margen lanzándolo. La optimización continua de precios estilo bandit es el siguiente paso natural para ese mismo motor, y es la dirección hacia la que apunta la hoja de ruta para los equipos que necesitan seguir ajustando un precio después de que el test inicial ya lo validó.

Lee también en este blog: la guía completa de multi-armed bandits vs test A/B, muestreo de Thompson explicado en profundidad, y la guía de significancia estadística para el lado del test clásico de esta decisión.

Léelo en inglés: Multi-Armed Bandits for Pricing Tests.

Empieza una prueba gratis de 14 días y corre tu próximo test de precios sobre una base estadística construida para decirte la verdad al respecto, no solo el número que esperabas.

Referencias

• Optimizely. Maximize lift with multi-armed bandit optimizations (los bandits no generan significancia estadística; Epsilon-Greedy para métricas numéricas). support.optimizely.com.
• Optimizely. Stats accelerator overview (estimadores robustos de media, varianza y asimetría usados para construir límites de confianza para métricas numéricas como el ingreso). support.optimizely.com.
• Optimizely. Contextual bandits (personalización basada en segmentos, la advertencia sobre el ingreso como métrica principal). support.optimizely.com.
• Wilmerhale. Personalized Pricing: What Business Lawyers Need to Know (estudio de la FTC sobre surveillance pricing, Ley de Divulgación de Precios Algorítmicos de Nueva York). wilmerhale.com.
• Mapping the Ethicality of Algorithmic Pricing: A Review of Dynamic and Personalized Pricing. Journal of Business Ethics, Springer Nature. link.springer.com.
• den Boer, A. Multi-armed bandits in dynamic pricing. Lancaster University STOR-i. lancaster.ac.uk.
• Bouneffouf, D. & Rish, I. A Survey on Practical Applications of Multi-Armed and Contextual Bandits. arXiv, 2019. arxiv.org/abs/1904.10040.