Resumen en un minuto
En abril de 2026, un retailer grande de home-improvement en Santiago perdió 8% de margen en un trimestre. No por inflación: por el hecho de que 23% de sus SKU estaban entre 4% y 11% por encima de Sodimac, y el equipo se enteraba por un PDF de una agencia externa, cada 14 días.
Es la foto tipo del retail LATAM en 2026: los precios de la competencia se mueven a diario, los marketplaces reescriben tags varias veces al día, y los retailers reaccionan con planillas de Excel. Pricing intelligence es la infraestructura que cierra ese hueco: scraping → normalización de SKU → modelos de ML → reglas → dashboard → acción automática en el ERP.
Pricing intelligence para retail no es «un truco de parsing barato». Es un sistema que resuelve tres tareas en paralelo: (1) ver a la competencia en tiempo real, (2) defender la política MAP de la marca frente al gris-importador, (3) optimizar precios propios según elasticidad por categoría. Estée Lauder en LATAM trabaja sobre todo (2): control de 12 marcas en marketplaces. Leroy Merlin trabaja (1) y (3): monitoreo diario de 50 000+ SKU contra Sodimac, Easy, Promart. Los dos casos van desarmados abajo, con stack, errores y dónde esto sencillamente no funciona.
- Pricing intelligence ≠ web scraping. El parsing es 10% del trabajo. El 90% es matching de SKU, ML, motor de reglas e integración con el ERP.
- Estée Lauder en LATAM: monitoreo de 12 marcas en 8+ marketplaces en 4 países, detección de promo-fraud, MAP compliance restaurado de 71% a 94% en 9 meses.
- Leroy Merlin (caso ruso, estructura aplicable a LATAM): scraping de 50 000+ SKU × 3 competidores, refresh diario, margin uplift de +1,4 a +2,8 p.p. según categoría.
- Stack: Scrapy/Playwright + proxies residenciales, PostgreSQL + ClickHouse, dbt, ML matching sobre embeddings, Metabase, Odoo como capa de acción.
- Dónde no funciona: B2B con licitaciones, luxury fashion con SKU únicos, discounters con margen menor a 8%.
- Costo: MVP PYME entre USD 8 000 y 15 000 de implementación + USD 400 a 800 mensuales de runtime. Payback de 3 a 6 meses.
De dónde vino la demanda de pricing intelligence en LATAM
Entre 2024 y 2026 tres factores convergieron y volvieron al pricing intelligence parte obligada del stack de retail en LATAM. Para una vista más extensa del mercado regional, ver el panorama por país en países LATAM.
Primero — el crecimiento del e-commerce. Según datos agregados de CEPAL y de las oficinas nacionales de estadística, la cuota online en general retail subió de 6% (2019) a 19-24% (2025) en México, Chile y Colombia. En Perú, de 4% a 12%. Mercado Libre controla entre 27% (MX) y 65% (AR) del retail online. Significa que la transparencia de precios pasó de «recorrer tres tiendas físicas» a «cinco segundos en el navegador».
Segundo — el efecto marketplace. Cuando tu SKU está en Mercado Libre, Falabella o Amazon Mexico, el algoritmo de Buy Box rankea vendedores prioritariamente por precio. Un competidor te corta 3% y tu SKU sale del Buy Box. Resultado: caída de 40% a 60% en ventas diarias de ese SKU. La reacción tiene que medirse en horas, no en semanas.
Tercero — presión de margen. Entre 2024 y 2025 el retail LATAM atravesó la ola inflacionaria (Argentina con pico cerca de 117%, México 4-5%, Chile 3-4%) más el alza de precios de importación desde Asia (logística contenerizada +18% interanual). Marcas y retailers exprimen cada punto de margen, y el pricing intelligence muestra dónde lo están perdiendo.
Timeline de cambios clave 2024-2026:
- Q2 2024: Mercado Libre refuerza el programa «Mejor Precio» y endurece el ranking del Buy Box.
- Q4 2024: Falabella anuncia el roadmap de dynamic pricing para su marketplace propio.
- Q1 2025: AWS suma capacidad EC2 Spot regional en México y Brasil. El scraping se vuelve más barato.
- Q3 2025: Amazon Mexico lanza el «Repricer» para third-party sellers. Presión sobre el rev/SKU promedio.
- Q1 2026: OECD publica una guía actualizada sobre personalised pricing. Las marcas europeas (Leroy Merlin, L'Oréal, Estée Lauder) tiran de sus operaciones LATAM hacia estándares globales.
Stack técnico: lo que realmente se necesita
Pricing intelligence se arma con 6 capas. Si saltás cualquiera, el sistema termina en «un PDF de competidores una vez al mes». La arquitectura de data engineering para retail enterprise describe en detalle cómo conectar capas 3 y 4 sin generar deuda.
#1. Recolección de datos (scraping / API)
Los precios de competencia se levantan por tres vías:
- Public website scraping (90% de los casos) — Scrapy + Playwright/Puppeteer para sitios JS-heavy. Rotación de proxies obligatoria — Bright Data, Oxylabs, Smartproxy. Para LATAM es crítico tener IPs residenciales en el país correcto: Mercado Libre y Falabella geo-bloquean IPs extranjeras.
- API de marketplaces (donde existen) — Mercado Libre Developers entrega precios de competencia en Buy Box; Amazon SP-API permite repricing reactivo. No cubre todo, pero es más barato que scraping.
- Affiliate feeds y Google Shopping feed — menos frescos, pero legales y estables. Sirven como backup y cross-check.
#2. Product matching
La parte más difícil y más subestimada. Vos tenés un SKU «Pintura látex blanco 4L Sherwin-Williams ref. SW-2003». Sodimac lo carga como «Sherwin Williams Pintura Latex 4 Litros Blanco Mate ref. SW2003-04». El match textual no funciona. Hace falta:
- Embeddings (Sentence-BERT para español o multilingual) con cosine similarity mayor a 0,85 para auto-match.
- Image matching (opcional, vía CLIP) como segunda verificación.
- Cola de revisión manual para scores entre 0,70 y 0,85.
Con 50 000 SKU × 3 competidores se generan 150 000 pares. Sin pipeline de ML no se resuelve.
#3. Almacenamiento
- PostgreSQL para operaciones (current prices, alerts, rules).
- ClickHouse o BigQuery para series históricas (50k SKU × 3 competidores × 365 días ≈ 55M puntos por año). Comparativa detallada en ClickHouse vs BigQuery para retail.
- dbt para la capa de transformación (normalización, KPI, cálculo de elasticidad).
#4. Analítica y ML
- Price elasticity a nivel de categoría (no de SKU — estadísticamente no es confiable): regresión con fixed effects o modelos jerárquicos bayesianos.
- Demand forecast — Prophet o un baseline estadístico. Acá no se necesitan LLMs.
- Anomaly detection sobre promo-fraud — z-score o Isolation Forest alcanzan.
#5. Motor de reglas
Acá el dynamic pricing toma la decisión: «si el competidor está 5% más barato, bajá 3%, pero nunca por debajo del floor». Open-source — Drools, Camunda DMN. Reglas YAML hechas en casa son la norma para PYME.
#6. Capa de acción
El precio tiene que volver a:
- ERP (Odoo, SAP, NetSuite) → tiendas físicas + e-commerce.
- Marketplace vía API.
- Dashboards para el merchandiser.
Es crítico tener Odoo con un módulo a medida (estilo dynamic_pricing) para sincronizar precios bajo reglas, versionar (audit log) y revertir ante errores. El trabajo base sobre pricelists y fórmulas de descuento está documentado en la documentación oficial de Odoo. Para entender cómo encajan reglas y módulos custom, conviene partir desde una auditoría Odoo.
Costo del stack para PYME (50-200k SKU)
| Componente | Costo mensual USD |
|---|---|
| Scraping infra (proxies + EC2) | USD 400-1 200 |
| Pipeline ML (compute) | USD 200-600 |
| Storage (ClickHouse cloud) | USD 150-400 |
| BI (Metabase OSS / Superset) | USD 0-50 |
| Odoo + módulo custom | USD 0-600 |
| TOTAL | USD 750-2 850 |
Comparalo con el ROI: 1,5 p.p. de margen sobre USD 5M de revenue equivale a USD 75 000 al año. Payback de 1,5 a 3 meses.
Cuándo funciona — cuándo no
El sistema rinde en condiciones específicas. Si tu situación no encaja, el overhead supera al beneficio. Antes de tirar presupuesto a un piloto, revisar la lista de capas en implementación Odoo para retail LATAM.
Funciona si:
- Catálogo de 500+ SKU y 3+ competidores visibles. Menos que eso, es overkill — alcanza con monitoreo manual dos veces por semana.
- Categoría con elasticidad mayor a 0,5 (electrónica, química del hogar, materiales DIY, cosmética básica). El comprador es sensible al precio: una góndola más barata mueve la demanda.
- E-commerce o marketplace por encima del 20% del facturación. Pricing intelligence es paradigma online; el brick-and-mortar recibe el efecto derivado vía sincronización omnicanal.
- Equipo de merchandising listo para reaccionar. Si las correcciones de precio pasan por comité dos veces al mes, no tiene sentido pagar refresh diario.
No funciona si:
- B2B con licitaciones o pricing contractual. El precio se negocia por deal; el monitoreo de competencia es inútil.
- Luxury fashion o SKU únicos. Si tu colección cápsula tiene 200 referencias que nadie más vende, el pricing intelligence se reemplaza por brand-positioning research.
- Discount-retailer con margen menor a 8%. Ya estás en el piso, no hay para dónde moverse.
- MAP rígida del proveedor sin flexibilidad. Si el contrato prohíbe salir de MAP, la dinámica se anula. El foco se corre a MAP-violation tracking (escenario Estée Lauder).
Zona gris (depende del detalle):
- Pharma y categorías reguladas. En México, Chile y Colombia hay regulación de reference pricing; en Argentina ANMAT congela precios de ciertos medicamentos periódicamente. Pricing intelligence trabaja sobre el surtido no regulado (cosmética, OTC, dispositivos médicos non-essential).
- PYME con un solo canal marketplace. Si el 90% del volumen va por Mercado Libre, el Repricer interno cubre alrededor de 70% del problema; el pricing intelligence externo se justifica solo para merch insights y vista cross-canal.
- Categorías de alta estacionalidad. En Buen Fin, Cyber Day y Hot Sale la elasticidad y la dinámica competitiva cambian de forma radical. Modelos entrenados sobre data off-season tiran señales falsas.
Errores típicos
Cinco años mirando proyectos de pricing en LATAM dejan una lista de errores que se repiten. Cada uno cuesta entre 6 y 18 meses de runway si no se detecta a tiempo. Más casos prácticos en el archivo de research.
Error 1: Tomar pricing intelligence como un «proyecto de parsing». El parsing es 10%. SKU matching, 30%. Analítica y reglas, 40%. Integración al ERP, 20%. Los equipos que contratan a un solo «scripter» terminan con un archivo CSV de precios, no con un sistema funcional.
Error 2: Refresh diario donde se necesita por hora. La electrónica en Mercado Libre reescribe precios entre 4 y 6 veces por día. Refresh diario significa reaccionar al precio de ayer. Para FMCG y DIY el diario alcanza; para consumer electronics y categorías de flash-promo hacen falta 2-4 actualizaciones diarias como mínimo.
Error 3: Ignorar el promo como señal aparte. El competidor mantiene MSRP en USD 100 y al mismo tiempo da un cupón del 18% al checkout. Effective price = USD 82, listed = USD 100. Si el scraper toma solo el listed, ves al mercado 18% más caro de lo que está realmente y perdés la conversión.
Error 4: Activar dynamic pricing sin floor ni ceiling. Ya cubierto en el callout: sin guard rails se llega al precio de USD 1 o al ceiling absurdo. Floor, ceiling, alertas y rollback son obligatorios.
Error 5: Calcular ML elasticity sobre el agregado, sin segmentación. El precio de un alimento para perro en Mercado Libre Mexico tiene una elasticidad distinta de la del mismo SKU en Mercado Libre Chile. El ML sobre el agregado produce un promedio sin sentido. Segmentar por región, canal y customer cohort es obligatorio.
Error 6: Tratar pricing intelligence como un proyecto one-time. Los competidores cambian la estructura de sus sitios cada 2-4 meses, lo que rompe scrapers. Sin un budget de mantenimiento (1 dev × 30% de su tiempo) el sistema se cae en seis meses.
Caso 1: Estée Lauder — monitoreo de 12 marcas en LATAM
Situación. Holding con 12 marcas de cosmética (premium y mass-market) en 4 mercados LATAM (México, Chile, Colombia, Perú). Distribución vía authorized retailers (Sephora, Falabella, Ripley, Liverpool), e-commerce propio y Mercado Libre/Amazon. Dolor: importadores grises (personas físicas, tiendas online chicas) tirando precios entre 25% y 40% por debajo del MSRP. Consecuencias:
- Canibalización de ventas de los partners autorizados, con conflicto en la distribución.
- Daño al brand equity (premium vendido a precio de masa).
- Canibalización de campañas promo (el precio promo ya estaba alcanzado por el stock gris antes del lanzamiento).
Qué hicieron. Pipeline de pricing intelligence:
- Scraping diario de 8 marketplaces y ~120 tiendas e-commerce en 4 países.
- Product matching por embeddings + cola de QA manual para los scores en borde.
- Anomaly detection: SKU más barato que el MSRP por 15% o más → alerta en Slack al equipo brand protection.
- Auto-notify al marketplace ops (Mercado Libre, Amazon) vía formulario MAP-violation.
- Cross-reference con el calendario interno de promo: si el scraper ve un descuento que no estaba en el plan aprobado → flag de promo-fraud e investigación.
Resultado (cifras anonimizadas, snapshot sobre 11 marcas del holding):
- Detection rate de promo-fraud: 67% (contra ~12% antes del proyecto).
- MAP compliance restaurado: de 71% a 94% en 9 meses.
- Remarketing ROAS: subió de 1,5x a 4,2x. Efecto colateral: campo de precios más limpio → LTV más alto → bid más caro en paid media empieza a rendir.
- 340+ listings ilegales removidos vía marketplace ops.
El caso completo en caso Estée Lauder: pricing & promo tiene el detalle del stack MAP-protection y los formularios usados ante Mercado Libre y Amazon.
Caso 2: Leroy Merlin — dynamic pricing sobre 50 000+ SKU
Situación. Retailer home-improvement con canal físico y online. Catálogo de ~120 000 SKU activos, de los cuales ~50 000 tienen 2+ competidores online visibles. Reactividad de las decisiones de precio: 2-3 semanas vía email y planillas. Los competidores (Sodimac en CL/PE, Easy en AR, Promart en PE) cambiaban precios entre 1 y 3 veces por semana; el equipo veía esos cambios con 14-18 días de retraso. Margin erosion: ~1,8 p.p. interanual en categorías de alta elasticidad (pinturas, herramienta, iluminación).
Qué hicieron.
- Build in-house del pipeline de scraping (Scrapy + proxies residenciales para 3 competidores).
- Product matching por embeddings; ~80% match automático, 20% a cola manual para merchandising.
- ClickHouse para price history; refresh diario para DIY, semanal para categorías de baja elasticidad.
- Motor de reglas: 6 tipos — price-match, undercut-by-X, premium-hold, MAP-protect, clearance-accelerate, intro-margin.
- Integración con Odoo vía módulo custom
dynamic_pricing. Los precios se actualizan en POS y e-commerce cada noche tras ejecutar reglas. - Dashboard BI en Metabase: SKU coverage, win/loss vs competidor, impacto en margen diario.
Resultado a 12 meses:
- Reaction time reducido de 14-18 días a 1 día (95% de reglas automatizadas).
- Margin uplift: +1,4 p.p. en categorías de alta elasticidad y +2,8 p.p. en private-label.
- 23% de SKU reposicionados — parte hacia arriba (donde estaban subvaluados), parte hacia abajo. No fue «todo más barato».
- Traffic recovery de +11% en categorías donde antes se perdía posición en marketplaces.
El origen del caso es ruso, pero la estructura se traslada casi 1 a 1 a LATAM: vertical home-improvement, 3 competidores visibles, efecto marketplace, una matriz de categorías por elasticidad muy parecida. Sodimac hace el rol de OBI, Promart el de Castorama, y así. La versión extendida con arquitectura está en caso Leroy Merlin: web scraping + dynamic pricing.
Descargá el blueprint: Pricing Intelligence Stack
El MVP se monta en 8-12 semanas con un presupuesto de USD 25 000-60 000. Para PYME con 5 000+ SKU y 3+ competidores el payback es de 3-6 meses. El lead magnet «Pricing Intelligence Stack Blueprint» es un PDF con la arquitectura de las 6 capas, snippets de Scrapy y matching, calculadora de ROI sobre tu catálogo y ejemplo de motor de reglas en YAML. Descargar blueprint (email-gated).
Preguntas frecuentes
¿Cuánto cuesta arrancar pricing intelligence en LATAM?
MVP piloto sobre 1 categoría (~500 SKU, 2 competidores, 1 país): USD 8 000-15 000 de implementación + USD 400-800/mes de runtime. Sistema completo sobre 20 000+ SKU, 3 países y 5+ competidores: USD 35 000-80 000 de implementación + USD 1 500-3 000/mes.
El payback en condiciones decentes (catálogo con elasticidad media, equipo merchandising que reacciona) ronda los 3-6 meses sobre el piloto y 6-12 meses sobre el sistema completo.
¿Es legal el web scraping en LATAM?
Scraping de datos públicos en general está permitido (no hay PII, no se rompe captcha ni login). Pero los ToS de la mayoría de los marketplaces lo prohíben — existe riesgo de IP-bans y, en casos excepcionales, de acciones legales. El approach seguro: proxies residenciales rotativos, rate limit bajo, no tocar áreas privadas.
Antes del lanzamiento hace falta una legal review con abogado local. Esta recomendación es general, no constituye legal advice.
¿Se puede prescindir de ML para el matching?
Para menos de 300 SKU, sí: mapeo manual. A partir de 1 000 SKU, hace falta embeddings + cola manual. Sin matching, el «pricing intelligence» se convierte en una colección de tablas no comparables — y la decisión se vuelve imposible de defender ante el comité.
¿El Repricer de Mercado Libre reemplaza al pricing intelligence externo?
Cubre ~60% del problema si toda la venta pasa por Mercado Libre. No entrega: vista cross-marketplace, monitoreo de promo, MAP-violations tracking, inteligencia sobre competidores brick-and-mortar ni control sobre el precio en e-commerce propio y tiendas físicas.
Para retailers que diversifican canales, el Repricer es un módulo del stack, no el stack completo.
¿Qué pasa con LGPD/GDPR al hacer scraping?
Los precios y el catálogo público no son PII. Si no recolectás nombres de sellers ni reviews de customers, LGPD/GDPR no aplican. Si sí, hace falta legal review y una política de data minimisation con abogado local.
¿Cómo usa Estée Lauder scraping si tiene distribución autorizada?
Parsean los e-commerce de terceros (gris-importadores, marketplaces no autorizados) para detectar MAP-violations y listings no autorizados. El sell-out data de Sephora y Falabella llega aparte vía EDI — son flujos paralelos, no sustitutos.
¿Qué tamaño mínimo de equipo necesita un in-house?
1 data engineer full-time, 1 merchandiser-analista al 50% y 1 ML engineer part-time o externo. Menos que eso y el pipeline se degrada entre 6 y 9 meses, porque los competidores cambian estructura de sitios cada 2-4 meses y los scrapers se rompen.
¿Cómo se mide el ROI del pricing intelligence?
Tres KPIs principales: margin uplift en puntos porcentuales (segmentado por categoría y elasticidad), reaction time (días desde el cambio del competidor hasta tu acción) y SKU coverage (% del catálogo con match activo en al menos 2 competidores). El benchmark sano para un retailer mid-market en LATAM: +1 a +2,5 p.p. de margen, reaction time menor a 24 horas y coverage por encima del 80%.
