Seguimiento de precios de la competencia en Magento: guía práctica

Seguimiento de la competencia en Magento, no del precio de Magento

Una aclaración antes de nada: esta guía trata de vigilar lo que cobran otras tiendas, no de lo que cuesta usar Magento. Busca "precios de Magento" o "cuánto cuesta Adobe Commerce" y casi todos los resultados hablan de licencias: Open Source es gratuito y Adobe Commerce es un contrato anual a presupuesto. Esa es otra pregunta. Si vendes con Magento y quieres saber cuánto cobran tus rivales por los productos que ambos tenéis, esta es la página correcta.

Segundo, un anclaje de versión. Todo lo técnico que viene a continuación se aplica a Magento Open Source y Adobe Commerce 2.4.x sobre un escaparate derivado de Luma. La versión 2.4.9 se publicó en mayo de 2026 y el soporte para la 2.4.6 terminó en agosto de 2026 (Adobe, consultado en agosto de 2026). Arrastra una salvedad transversal: Adobe Commerce as a Cloud Service, los escaparates headless y de Edge Delivery, y los temas de terceros como Hyva, Porto o BSS no emiten necesariamente el marcado de Luma, así que un competidor sobre alguno de ellos puede no exponer nada reconociblemente Magento.

El panorama comercial no es el que pintan casi todos los artículos: Magento encoge en número de tiendas mientras las que quedan crecen. StoreLeads cuenta 104.546 tiendas Magento activas, un 14 % menos interanual y alrededor de un 35 % por debajo del pico de 161.970 del cuarto trimestre de 2021 (StoreLeads, julio de 2026). Las que se fueron eran en su mayoría pequeñas, expulsadas primero por el fin del soporte de Magento 1 en junio de 2020 (Help Net Security, junio de 2020) y después por el coste de una licencia de Adobe Commerce. W3Techs, que mide el uso de plataformas en los sitios que analiza y no la cuota de ventas online, sitúa a Magento en el 1,5 % de todos los sistemas de comercio electrónico (W3Techs, agosto de 2026). Cuota pequeña, tiendas grandes: tus competidores en Magento son menos y mayores que hace tres años, así que cada movimiento de precios suyo pesa más.

El resto de esta guía desarrolla una idea y sus consecuencias. El número que aparece en una página de producto de Magento es el resultado de una fórmula, no un campo de una base de datos. Para el mismo trabajo en otras plataformas, consulta las guías de Shopify y WooCommerce.

La fórmula del precio final de Adobe es todo el problema

Empieza por la fórmula, porque de ella se derivan todos los modos de fallo que siguen. Adobe la enuncia directamente:

Final Price = Min(Regular(Base) Price, Group(Tier) Price, Special Price, Catalog Price Rule) + Sum(Min Price per each required custom option)

Procede de la documentación de Adobe sobre precios especiales (Adobe, consultado en agosto de 2026), y es el párrafo más útil de toda la documentación de Magento para quien construya un histórico de precios.

Fíjate en lo que implica. Cuatro mecanismos compiten por producir el número que ve un comprador, gana el más bajo, y solo el primero es el precio que un comerciante considera el precio. Los otros tres están acotados por condiciones que un visitante anónimo no puede controlar y, en un caso, ni siquiera puede ver.

Mecanismo	Qué le hace al precio de la PDP	Visible para un visitante anónimo	Acotado por
Precio base (regular)	El valor por defecto, y el perdedor siempre que cualquier otro sea más bajo	Sí	Website
Precio por tramos (tier) o por grupo	Un descuento por cantidad se muestra como «Compra 6 por 5,95 $ cada uno y ahorra un 15 %»; un precio de grupo se aplica «cuando el comprador ha iniciado sesión en su cuenta»	En parte. Los tramos del grupo invitado se muestran, los precios restringidos por grupo no	Website y grupo de clientes, más la cantidad en los precios por tramos
Precio especial	Sustituye al precio regular durante una ventana programada	Sí	Website y una ventana de fechas
Regla de precio de catálogo	Los descuentos «entran en vigor antes de que el producto se añada al carrito», así que cambia el precio mostrado en la PDP	Sí, si la regla apunta al grupo invitado	Website, grupo de clientes y una ventana de fechas

Conviene fijar dos detalles. Un precio especial corre «inmediatamente después de la medianoche al comienzo de la fecha de inicio (00:01) y continúa hasta justo antes de la medianoche (23:59) del día anterior a la fecha de fin», así que la fecha de fin es exclusiva y una promoción que esperas ver el último día ya se ha ido. Y el selector de grupo de clientes de Adobe ofrece tanto «ALL GROUPS» como «NOT LOGGED IN». Tu monitorización vive permanentemente en el segundo.

Modo de fallo 1: el precio destacado es un mínimo derivado

Magento tiene cuatro tipos de producto y solo uno se comporta como da por hecho un monitor de precios. Un producto simple tiene un precio y un SKU. Un producto configurable no: Adobe es explícito al decir que «el precio del producto configurable se deriva de sus productos hijo In Stock» (Adobe, consultado en agosto de 2026). Los productos grouped (agrupados) heredan el mismo comportamiento, y los bundle (paquetes) con precio dinámico muestran un rango en lugar de un precio.

La consecuencia arruina los históricos de precios. Cuando la variante más barata con stock se agota, el precio mostrado salta a la siguiente más barata. Nadie cambió ningún precio. Tu serie registra una subida, salta tu alerta y respondes a una rotura de stock como si fuera una decisión de repricing. Si has visto oscilar el precio de un competidor con un ritmo de dos días y sin lógica comercial detrás, esta suele ser la razón.

Así que monitoriza la variante, no el padre: lee los precios por variante dentro de la página en lugar del destacado que se renderiza. En la API de GraphQL, Adobe te da una pista limpia (Adobe, consultado en agosto de 2026): «Si eliges consultar un producto que no es un producto compuesto, los precios mínimo y máximo son iguales». Por tanto, un minimum_price distinto de maximum_price es una bandera legible por máquina que significa esto es el extremo de un rango, no lances una alerta con ello.

Modo de fallo 2: el precio real puede estar restringido

Puedes monitorizar a un competidor a precio de tarifa durante meses mientras sus clientes pagan un 20 % menos, y nada en tus datos parecerá incorrecto.

El mecanismo es el precio por grupo: el descuento se aplica, en palabras de Adobe, «cuando el comprador ha iniciado sesión en su cuenta». Adobe Commerce ensancha la brecha, porque la edición con licencia añade Customer Segments y catálogos compartidos B2B por encima de los grupos de clientes normales, y el precio de un catálogo compartido tiene prioridad sobre las tarifas de grupo estándar. Magento Open Source no tiene ninguno de los dos. En un competidor B2B sobre Adobe Commerce, el precio realmente transaccionado puede vivir en un catálogo compartido que ninguna petición anónima devolverá jamás, y el precio público es un techo, no un precio de mercado.

Tres pistas de que hay precios restringidos en juego: una llamada a la acción del tipo «inicia sesión para ver el precio» o «inicia sesión para ver precios profesionales», una tabla de tramos que solo aparece tras iniciar sesión, y un botón «Solicitar presupuesto» donde debería estar Añadir al carrito. Registra esas lecturas como precio de tarifa con el precio real restringido, no como puntos de datos limpios.

Y por decir lo obvio: crear cuentas falsas para llegar a los precios restringidos es un problema de condiciones de servicio, no un problema técnico. No construyas tu monitorización sobre eso.

Modo de fallo 3: un precio, tres representaciones

Este es desagradable porque nunca parece que haya nada roto. Cada lectura es coherente consigo misma.

Magento separa websites, stores y store views, y el precio se ancla a un nivel distinto que la moneda. La documentación de Adobe sobre el ámbito de precios del catálogo afirma que «Commerce no permite fijar un precio de producto para cada store. Pero sí puedes cambiar el precio por website» (Adobe, consultado en agosto de 2026). El precio varía por website, nunca por store view. La moneda base se fija en el ámbito de website, la moneda de visualización se fija por store view, y la visualización de impuestos puede mostrar los precios sin impuestos, con impuestos o ambos a la vez.

Combina esas tres cosas y un mismo SKU con un único precio de website se representa de tres maneras. Las cifras siguientes son ilustrativas, no medidas.

Store view	Lo que muestra la página
US, sin impuestos, USD	99,00
DE, con impuestos, EUR	120,79
UK profesional, ambos mostrados	99,00 (120,79 con impuestos)

El store view se selecciona por la ruta de la URL o mediante una cookie o un parámetro de consulta store, así que un reintento que aterriza en otra vista, o una redirección geográfica que tu fetcher sigue en silencio, mueve el precio que registras exactamente el tipo de IVA o le cambia la moneda. Un tracker que no fija el store view está midiendo una serie de store views, no una serie de precios.

Las mitigaciones no tienen glamour. Conserva la URL exacta del store view, detecta las redirecciones geográficas en lugar de seguirlas a ciegas, envía la cabecera Store en GraphQL y guarda el código de moneda con cada punto de precio, tratando un cambio de moneda como un incidente de integridad de datos y no como un cambio de precio.

Modo de fallo 4: MAP esconde el precio detrás de un gesto

Las políticas de precio mínimo anunciado (MAP) son una funcionalidad nativa de Magento, y rompen el scraping ingenuo en la dirección más cara.

La funcionalidad MAP de Adobe tiene un ajuste «Display Actual Price» con tres valores: In Cart, Before Order Confirmation y On Gesture, este último esconde el precio tras un popup de «Click for Price». En los tres casos el número que hay en el marcado es el MSRP, por construcción la cifra más alta plausible. Un scraper lo registra, concluye que estás por debajo del competidor, y acabas manteniendo un precio que nunca necesitaste mantener. Es habitual en electrónica de consumo, instrumentos musicales, óptica, herramientas eléctricas y electrodomésticos.

MAP no se aplica de manera uniforme. En los productos grouped, los precios de los productos simple asociados aparecen solo según el ajuste Display Actual Price. Y MAP se aplica únicamente a los bundle de precio fijo: «no está disponible para productos bundle con precio dinámico» (Adobe, consultado en agosto de 2026), así que un comerciante que pasa un bundle a precio dinámico desactiva la supresión sin darse cuenta.

Detecta MAP en lugar de intentar interpretarlo. Registra el producto como precio bajo consulta y exclúyelo de los cálculos de posición de precio en vez de escribir un MSRP en tu histórico. Si tú mismo aplicas suelos de precio, la monitorización de MAP es la disciplina relacionada.

Modo de fallo 5: para esto no necesitas un navegador headless

Casi todos los artículos sobre scraping de Magento te dicen que renderices la página en un navegador headless. Para extraer precios ese consejo suele estar equivocado, y la propia documentación de frontend de Adobe explica por qué.

Magento inicializa los widgets de JavaScript mediante una etiqueta <script type="text/x-magento-init"> cuyas claves de primer nivel son selectores CSS, donde "*" significa que no está vinculado a ningún elemento. Adobe describe lo que hace el mecanismo: «prepara toda la configuración en el backend y la vuelca al código fuente de la página usando herramientas estándar» (Adobe, consultado en agosto de 2026). La configuración de los widgets, precios incluidos, se serializa en el servidor y viaja dentro del HTML. No hay ninguna XHR que esperar ni ningún cálculo de precio en el cliente que reproducir. Renderizar la página añade coste y latencia, y no devuelve nada nuevo.

En un producto configurable, el payload que quieres es el objeto de configuración que lee el widget de producto configurable de Magento, Magento_ConfigurableProduct/js/configurable. Por convención se guarda bajo la clave spConfig. Adobe documenta x-magento-init en sí, pero no documenta este objeto por su nombre, así que trata la forma que sigue como una convención observada y no como un contrato:

{
  "attributes": {
    "93": {
      "code": "color",
      "options": [{ "id": "50", "label": "Blue", "products": ["1234"] }]
    }
  },
  "optionPrices": {
    "1234": { "finalPrice": { "amount": 79 }, "oldPrice": { "amount": 99 } }
  },
  "salable": { "93": { "50": ["SKU-BLUE-M"] } },
  "currencyCode": "USD"
}

Tres cosas de ahí se ganan el sueldo. optionPrices.<childId>.finalPrice.amount es el precio real por variante, y oldPrice frente a finalPrice te da el par tachado. salable es el mapa honesto de stock: una opción que falta en su eje, o que apunta a una lista vacía, no se puede comprar aunque siga teniendo su entrada en optionPrices. Y el precio que se muestra antes de cualquier selección es el mínimo derivado del padre, que no pertenece a ningún SKU.

Espera tres formas de emisión. Luma sin modificar usa el bloque x-magento-init con claves de selector. Muchos temas de terceros emiten una llamada en línea a initConfigurableOptions() cuyo tercer argumento opcional lleva un stock_message por hijo que dice literalmente "In Stock" u "Out of Stock", autoritativo cuando está presente. Los temas de la familia BSS colocan la misma matriz bajo un componente con otro nombre.

Cuatro sitios, cuatro respuestas

La página suele contener varios precios que no coinciden, y el más fácil de alcanzar es el menos fiable.

Capa	Fiabilidad
spConfig.optionPrices.<childId>.finalPrice.amount	Autoritativo por variante
DOM del priceBox, data-price-amount en la caja finalPrice	Autoritativo para la selección actual, y sigue presente en páginas sin stock
JSON-LD Product.offers.price	A menudo ausente, y a menudo anidado dentro del mainEntity de un nodo WebPage en vez de en el nivel superior
Meta og:price:amount o product:price:amount	Frecuentemente desactualizado

Léelos en ese orden, y recorre recursivamente mainEntity antes de concluir que el JSON-LD no lleva ofertas. Un extractor que va primero a OpenGraph, que es lo más fácil de escribir, registrará tan contento el precio del mes pasado.

Tus competidores no están todos en Magento

A tus compradores les da igual qué plataforma use nadie. Comparan tu producto con quien sea que lo venda, lo que incluye tiendas Shopify, sitios WooCommerce, fichas de marketplace y grandes minoristas sobre desarrollos a medida.

Una buena monitorización lee las páginas de producto públicas independientemente de la plataforma, así que construye tu lista de vigilancia en torno a quién compite por el comprador y no a quién comparte tu stack. La misma mecánica con otros modos de fallo se aplica a una tienda Shopify y a una tienda WooCommerce.

Fijar la frecuencia de revisión

Cada revisión cuesta algo, así que organiza la lista por niveles en lugar de tratar todos los productos igual.

• Productos estrella: cada una o pocas horas, ya que un movimiento de la competencia aquí cambia tus ventas de esta semana.
• Productos de nivel medio: a diario, con una banda de tolerancia más amplia y una respuesta semanal salvo que algo sea drástico.
• Productos de larga cola: semanalmente, protegiendo el margen en vez de perseguir igualar precios.

Magento añade un matiz. Como los padres configurables se mueven con el stock y no con decisiones de pricing, subir la frecuencia en uno genera movimiento fantasma, no señal, salvo que leas los precios a nivel de variante. Arregla primero la extracción. Para el marco general, consulta con qué frecuencia deberías revisar los precios de la competencia.

Qué lee Respot en una página de Magento

Respot no tiene integración con Magento ni extensión que instalar. Lee URL de producto públicas, que es la arquitectura correcta aquí, porque el precio de un competidor no vive dentro de tu tienda.

Lo que sí tiene es una extracción construida para los modos de fallo anteriores. Analiza el objeto de configuración de variantes de Magento, recurre al atributo data-price-amount del priceBox y recorre el JSON-LD de forma recursiva para no perderse una oferta anidada en mainEntity, todo ello sin navegador headless. El seguimiento es por variación, así que el agotamiento del color más barato de un competidor se registra como una rotura de stock y no como una subida de precio.

El plan gratuito cubre 5 trackers sin tarjeta de crédito y 7 días de historial de precios, suficiente para comprobar si tus páginas más disputadas se analizan sin problemas. Los planes de pago escalan a 100, 400 o 2.000 trackers con 30, 90 o ilimitados días de historial.

Por dónde empezar

Elige tus diez productos más disputados, encuentra las URL de la competencia y haz una cosa antes de añadir ninguna a un monitor: abre cada página y decide qué modo de fallo se aplica. ¿El precio destacado es el mínimo de un configurable? ¿Hay una barrera de inicio de sesión para ver el precio? ¿La URL fija un store view, y la moneda es la que esperas? ¿Hay un gesto de «Click for Price» ocupando el lugar de un número?

Esa auditoría lleva una tarde y decide si los próximos seis meses de histórico de precios significan algo. Un tracker apuntado a un producto padre de Magento con el precio suprimido por MAP y un store view sin fijar produce un gráfico pulcro de números que no describen nada.

Haz bien la extracción y Magento se convierte en una de las plataformas más fáciles de monitorizar, porque Adobe pone los datos en el código fuente de la página a propósito. Empieza a monitorizar a tus competidores cuando sepas qué te está contando cada página.