Pricing dinámico en retail: por qué tu repricer te está dejando margen sobre la mesa

La trampa del repricer: optimizar posición competitiva no es optimizar margen

Amazon ajusta precios aproximadamente 2,5 millones de veces al día. Tu competencia probablemente ajusta los suyos cada hora copiando a quien tiene al lado. Y ninguno de los dos sabe cuánto está dejando de ganar. Esa es la primera idea que conviene desmontar antes de seguir.

El mercado de herramientas de pricing dinámico en retail para mid-market está dominado por una sola idea: scrapeo lo que hace la competencia, aplico reglas, ajusto mi precio en consecuencia. Prisync, Boardfy, Repricer, Omnia en su modo básico, todos comparten esta arquitectura mental. Funciona en el sentido de que automatiza algo que antes hacía un becario con un Excel. Pero el modelo subyacente es defectuoso: estás reaccionando, no decidiendo.

Cuando todos los actores de un mercado aplican la misma regla — "no estar más de un 2% por encima del competidor más barato" — el resultado matemático es inevitable. Todos los precios bajan hasta el suelo de margen. Es una carrera al abismo orquestada por bots. Y lo más grave es que ocurre sin que nadie lo decida explícitamente; emerge del comportamiento agregado de los algoritmos.

No es necesario llegar al nivel de Amazon para hacer algo mejor que un repricer. Pero sí hay que entender que el problema real no es "qué precio tiene mi competidor", sino una pregunta distinta y mucho más útil.

Lo que el repricer no ve: elasticidad real vs. reacción al competidor

La pregunta que un sistema de pricing dinámico bien diseñado debe responder es: cuánto cae mi demanda si subo el precio un 5%. Y la simétrica: cuánto sube si lo bajo un 5%. Esa relación se llama elasticidad-precio de la demanda, y es la diferencia entre entender tu negocio y limitarte a copiar el de al lado.

Aquí aparece el problema técnico real, el que hace que la mayoría de implementaciones caseras fallen. Si miras tu histórico de ventas y haces una regresión simple entre precio y unidades vendidas, vas a obtener un número que parece elasticidad pero no lo es. Es ruido confundido con señal. La razón es lo que en econometría se llama confounding: las veces que bajaste el precio en el pasado, normalmente lo hiciste porque ya sabías que la demanda iba a caer. Liquidación de stock, fin de temporada, producto descatalogándose. La correlación que ves no mide cómo reacciona el cliente al precio; mide cómo reaccionas tú al stock.

Una forma intuitiva de verlo: imagina un retailer de ropa que el último día de rebajas reduce el precio de un abrigo un 60% y vende cinco unidades. Si dos meses atrás, en plena temporada, ese mismo abrigo estaba a precio completo y vendía treinta unidades semanales, la correlación cruda diría que el precio bajo causa menos ventas. Absurdo, pero matemáticamente correcto si solo miras precio y cantidad sin controlar nada más.

# Lo que casi todo el mundo hace y miente
from sklearn.linear_model import LinearRegression
modelo = LinearRegression().fit(X[["precio"]], y)
elasticidad_aparente = modelo.coef_[0]  # sesgada por confounding

# Lo que sí funciona: Double Machine Learning
from doubleml import DoubleMLPLR
dml = DoubleMLPLR(data, ml_l=rf_outcome, ml_m=rf_treatment)
dml.fit()  # aísla el efecto causal del precio

Double Machine Learning, formalizado por Chernozhukov y otros en 2018, resuelve el confounding usando dos modelos auxiliares: uno predice el outcome (ventas), otro predice el tratamiento (precio), y la elasticidad se estima a partir de los residuos. Es técnica madura, hay librerías de producción, y es lo que diferencia un sistema serio de uno que solo sigue al competidor. No hace falta implementarla a mano, pero sí entender qué problema resuelve antes de pagar por una herramienta que dice hacerlo.

La arquitectura: tres flujos, un único punto de decisión

Un sistema de pricing dinámico que merezca el nombre se construye sobre tres flujos de datos que confluyen en un motor de decisión. La gracia está en que ninguno de los tres es opcional, y sin embargo la mayoría de implementaciones caseras se quedan en uno o dos.

El primer flujo, señales de mercado, es lo que ya hacen los repricers: scraping de competidores, pulls de APIs de marketplaces, monitorización de precios públicos. Es necesario pero insuficiente. El segundo, señales propias, es el que más se descuida y el que más valor tiene: tu propio histórico de ventas, niveles de stock, eventos de carrito abandonado, clickstream del site. Sin esto no hay forma de estimar elasticidad porque no tienes la variable dependiente. El tercero, contexto, es el que distingue una buena implementación de una mediocre: calendario laboral, festivos locales, eventos deportivos si vendes merchandising, clima si vendes ropa o helados, lanzamientos de productos relacionados.

Los tres flujos confluyen en un warehouse — BigQuery, Snowflake o Redshift, da igual cuál — donde dbt actúa como capa de transformación. Encima de las tablas crudas se construyen las features que el modelo va a consumir: elasticidad estimada por categoría, índice competitivo, demanda esperada, ventana de estacionalidad. El motor de decisión es un servicio que consume esas features y devuelve un precio recomendado por SKU. Y antes de que ese precio llegue al site, pasa por una capa de guardrails que decide si se publica o se descarta.

Por qué dbt es el secreto poco glamuroso

Cuando se habla de pricing dinámico en círculos técnicos enterprise, la conversación deriva rápidamente hacia Kafka, Flink, feature stores en Redis, arquitecturas Kappa. Todo eso es correcto para Uber, Booking o Amazon, donde el volumen de eventos justifica la infraestructura. Para una scale-up que mueve entre miles y cientos de miles de transacciones al día, es overengineering. Y peor: es deuda técnica disfrazada de modernidad.

El equivalente accesible y mantenible es radicalmente más simple. Los datos llegan al warehouse cada quince minutos vía Airbyte o Fivetran. Las features se construyen como modelos dbt versionados en git. El motor de decisión es un job de Cloud Run o Cloud Functions que se ejecuta cada hora, lee del warehouse, calcula precios y los escribe en una tabla de salida. Un trigger publica los cambios en el e-commerce vía API. Toda la lógica de negocio vive en SQL versionado, no en un notebook que solo entiende el data scientist que lo escribió.

El componente que casi nadie incluye: guardrails y explicabilidad

Aquí está la diferencia entre un sistema que funciona y uno que termina en titular de prensa. Los guardrails no son un parche opcional sobre el modelo; son parte de la arquitectura. Hay tres tipos, y los tres son obligatorios.

Los guardrails de negocio son los más obvios: precio mínimo para no destruir margen, precio máximo para no superar un percentil razonable del competidor, suavizado temporal para que un mismo SKU no cambie de precio más de un 8% en veinticuatro horas. Un sistema sin estos guardrails es un sistema que tarde o temprano va a publicar un televisor de mil quinientos euros a doce euros porque el modelo se confundió con un outlier de scraping. Ha pasado, y los retailers afectados aprendieron por las malas que el coste de no tener guardrails de negocio es honrar los pedidos a precio absurdo.

Los guardrails de fairness son los que la mayoría todavía no considera, y los que van a separar a los sistemas viables de los demandados en los próximos dos años. La regla operativa es clara: ningún feature del modelo de decisión puede depender de datos personales del cliente individual. Geolocalización fina, historial de búsqueda específico, dispositivo, frecuencia de visita — fuera. Personalizar precio por segmento agregado (por ejemplo, geografía a nivel de país) es defendible. Personalizar precio por individuo es surveillance pricing, y entra de lleno en el radar regulatorio.

Los guardrails de auditabilidad cierran el triángulo. Cada decisión de precio publicada debe poder reconstruirse después: qué features alimentaron el modelo, qué versión del modelo se usó, qué reglas se aplicaron, por qué se aprobó o se rechazó. No es un capricho de gobernanza. El artículo 22 del GDPR ya obliga a explicabilidad para decisiones automatizadas con efecto significativo sobre las personas, y un precio personalizado entra de lleno en esa categoría. Si un cliente o un regulador te pregunta por qué cobraste lo que cobraste, la respuesta "porque el modelo lo dijo" no es legalmente válida.

Técnicamente, esto se traduce en una tabla de log que guarda, por cada precio publicado, el snapshot de features de entrada, el output del modelo, las reglas aplicadas y el precio final. Si esa tabla existe y es queryable, tienes auditabilidad. Si no existe, tienes un problema en cuanto el primer cliente pregunte algo.

Cómo lo despliegas sin destruir tu marca

El caso canónico de fracaso reciente no fue técnico, fue comunicacional. En febrero de 2024, Wendy's anunció en una earnings call que estaba invirtiendo veinte millones de dólares en menús digitales para "explorar dynamic pricing". La asociación inmediata en redes sociales y prensa fue con el surge pricing de Uber, y el hashtag #BoycottWendys se volvió viral en horas. Burger King lanzó una campaña titulada "No urge to surge". Wendy's terminó haciendo un comunicado en menos de una semana aclarando que solo bajaría precios en horas valle, nunca subiría en horas pico. El daño reputacional ya estaba hecho.

Lo interesante es que Wendy's tenía razón técnicamente. Los menús digitales permiten flexibilidad de precios y la mayoría de retailers serios la usan. El error no fue el sistema; fue llamarlo por su nombre delante del consumidor final. Hay tres principios de despliegue que se derivan directamente de este tipo de fracasos.

Resultados realistas: qué esperar y en qué orden

Cualquier vendor te va a prometer un 30% de uplift en margen si compras su licencia. Esa cifra es marketing. Los resultados que aparecen en literatura académica revisada y en implementaciones documentadas son notablemente más modestos, pero suficientes para justificar el proyecto si la base es razonable.

El orden de implementación importa tanto como los componentes. La tentación habitual es empezar por lo más vistoso — el modelo de elasticidad — y descubrir tres meses después que no se puede entrenar porque los datos están dispersos y mal etiquetados. La secuencia correcta es la inversa.

La fase uno parece la menos sexy pero es la que separa a los que llegan a fase tres de los que se atascan en fase dos durante años. Sin un warehouse limpio con dbt encima, todo lo que viene después es ingeniería sobre arena.

Cuándo no construyas esto

Un sistema de pricing dinámico no es para todos los retailers, y reconocerlo a tiempo es parte del trabajo de arquitectura. Hay tres situaciones en las que el ROI no compensa el esfuerzo de construcción ni el riesgo de implementación.

Si tu catálogo tiene menos de 200 SKUs activos con rotación significativa, el coste fijo de construir el sistema supera el valor incremental que puede capturar. Una hoja de cálculo bien mantenida, revisada semanalmente por una persona con criterio, va a hacer un trabajo comparable. La automatización solo paga cuando la escala te impide hacerlo a mano.

Si vendes commodities puros donde el precio de mercado está dictado externamente — combustibles, productos agrícolas a granel, materias primas — el espacio de decisión es tan estrecho que el modelo no tiene dónde aportar valor. Tu precio está cerca del precio de referencia, punto. La optimización vive en otros ejes: coste de adquisición, logística, financiación.

Y si tu marca es premium con posicionamiento de prestigio, donde el precio es señal de exclusividad, cualquier variabilidad de precio destruye el valor que el cliente está comprando. Un reloj de gama alta no se vende dinámicamente. Un hotel cinco estrellas puede hacer revenue management sobre habitaciones, pero su tarifa base es una declaración de identidad, no una variable de optimización.

El cambio de paradigma que estamos atravesando

Durante décadas, fijar precio fue una decisión humana periódica: el comité de pricing se reunía cada mes, revisaba márgenes y competidores, y emitía una lista. Ese mundo está terminando, no porque la decisión se vaya a automatizar por completo — la sigue tomando alguien, igual que el piloto sigue volando el avión aunque haya autopiloto — sino porque la frecuencia y granularidad están escapando de la escala humana. Lo que antes se decidía mensualmente sobre cien categorías ahora se decide cada hora sobre diez mil SKUs.

La pregunta de arquitectura no es si vas a llegar ahí. Vas a llegar, o el mercado te va a empujar fuera. La pregunta es qué cimientos construyes ahora para que cuando llegues, el sistema sea defendible: ante tus clientes cuando pregunten por qué pagan lo que pagan, ante tus reguladores cuando pidan auditoría, y ante ti mismo cuando un modelo se equivoque y necesites entender por qué.

¿En cuántos puntos de tu pipeline actual podrías explicar, con datos sobre la mesa, exactamente por qué estás cobrando lo que estás cobrando por cada SKU que vendes hoy?