La lógica de precios y promociones es la capa de reglas comerciales que determina cuánto debe pagar un cliente, por qué se aplica ese importe y cómo debe explicarlo la tienda. Un producto puede tener precio base, precio de oferta, precio específico por variante, precio por nivel de cliente, descuento por cantidad, descuento de catálogo, cupón, incentivo de envío gratuito, ajuste de suscripción, recompensa de fidelización y una condición fiscal o regional. La tienda puede mostrar un único importe final, pero ese importe puede proceder de varios objetos de datos y reglas de cálculo.
En una plataforma de comercio electrónico, los datos de precios no se limitan a un campo de precio del producto. Pueden distribuirse entre registros de producto, variantes, listas de precios, grupos de clientes, catalog rules, regla del carritos, tablas de cupones, configuraciones fiscales, reglas de envío, configuración de moneda, sistemas de suscripción, aplicaciones de fidelización, motores enterprise de precios, integraciones ERP o datos personalizados de extensiones. La lógica de promociones depende todavía más de estructuras relacionadas porque un descuento suele necesitar condiciones de elegibilidad, exclusiones, periodos de vigencia, límites de uso, prioridad, reglas de combinación y una secuencia de cálculo.
Por ello, una revisión técnica debe examinar dónde se almacena la regla comercial, de qué datos depende, cómo la calcula la plataforma y cómo aparece el resultado en carrito, proceso de compra, Orders, informes, refunds y comunicaciones con clientes.
Qué representa la lógica de precios y promociones
Representa el sistema de decisión comercial de la tienda. Responde al mismo tiempo a varias preguntas: cuál es el precio normal, si un cliente califica para otro precio, si el carrito cumple una promoción, qué productos están excluidos, si se modifica el envío, si los impuestos se calculan antes o después del descuento y si varios incentivos pueden combinarse.
Una misma tienda puede utilizar distintas capas con objetivos diferentes:
| Capa de precio o promoción | Qué representa | Funcionamiento afectado |
|---|---|---|
| Precio base | Precio normal de venta de un producto o variante | Página de producto, importe de línea, fuentes de datos, informes y totales de Orders |
| Precio de oferta o compare-at | Diferencia temporal o de merchandising | distintivos, precios tachados, páginas de campaña y mensajes de conversión |
| Precio por variante | Precios distintos por talla, color, material, cantidad o configuración | Selección de opciones, totales del carrito y expectativas de procesamiento de pedidos |
| Precio por grupo de clientes | Precio reservado para mayorista, retail, VIP, B2B, empleados o memberships | Precios según login, cuentas, segmentación y venta contractual |
| Precio escalonado o por cantidad | Precio que cambia según la cantidad | Compras por volumen, mayorista, tablas de precios y cálculo del carrito |
| Catalog rule | Descuento aplicado antes de llegar al carrito | Merchandising de categorías, listados de productos y visibilidad de ofertas |
| regla del carrito | Descuento aplicado según condiciones del carrito | Cupones, totales, incentivos en proceso de compra y ofertas por umbral |
| Incentivo de envío | Envío gratuito o reducido bajo condiciones | Conversión, ofertas regionales y cálculo de margen |
| Regla de fidelización | Crédito, puntos, descuento de membership o beneficio acumulado | Retención, cuentas y economía de repetición de compra |
| Precio de suscripción o recurrente | Lógica de precio para compras repetidas o ciclos de membresía | Billing, renovaciones, cuentas y automatización de Orders |
| Fuente externa de precio | Precio controlado por ERP, POS, PIM, marketplace o precios engine | Gobierno de origen of truth, sincronización y operación |
Estas capas pueden solaparse. Un producto puede tener precio de oferta, precio específico por cliente, promoción de categoría, cupón y umbral de envío gratuito al mismo tiempo. La pregunta técnica importante no es solo si cada capa existe, sino cuál prevalece, cuáles se combinan y cómo registra la plataforma el resultado final.
Estructuras de datos habituales detrás de los precios
La fijación de precios suele empezar con un campo, pero muchas tiendas necesitan una estructura más rica. Un producto simple puede tener un precio base. Un producto con variantes puede guardar un precio por SKU. Una tienda B2B o conectada a marketplaces puede mantener listas por mercado, moneda, grupo de clientes, catálogo, contrato o canal.
Campos habituales:
| Campo o propiedad | Función típica | Riesgo técnico |
|---|---|---|
| Product ID o Variante ID | Conecta el precio con el artículo vendible | Determina si aplica al producto principal o a una variante concreta |
| Precio base | Precio estándar | Puede ser a nivel de producto en una plataforma y a nivel de variante en otra |
| Precio de oferta | Precio reducido activo | Puede tener fechas propias o depender de reglas de campaña |
| Compare-at o list price | Precio de referencia mostrado junto al precio activo | Puede afectar la visualización sin cambiar el cálculo |
| Cost o margin campo | Base interna de coste | No suele ser visible, pero importa para informes y margen |
| Currency code | Moneda del valor | Puede requerir listas de precios, reglas de cambio o valores por mercado |
| Tax class | Categoría fiscal del producto | Afecta cálculo de impuestos y cumplimiento regional |
| Customer group o lista de precios ID | Relación de elegibilidad | Controla B2B, mayorista, memberships o precios contractual |
| Quantity threshold | Punto de corte para precios escalonados | Determina cuándo cambia el precio unitario |
| Canal o mercado | Relación con tienda online, región, marketplace o canal | Controla qué precio aparece en cada contexto |
| Fecha de inicio y fin | Ventana de activación | Controla campañas y riesgo de precios obsoletos |
| Prioridad u orden | Valor de resolución de conflictos | Determina qué precio o regla gana cuando coinciden varios |
Una plataforma con un solo precio por producto se comporta de manera muy distinta a otra que almacena múltiples filas por producto, variante, grupo de clientes, mercado o canal. Esa diferencia afecta visualización, edición, exportación, sincronización y validación.
Reglas promocionales como datos basados en condiciones
Los registros promocionales suelen contener dos partes: un activador y una regla. El activador puede ser un código de cupón, un descuento automático, un segmento de clientes, un calendario de campaña o una condición del carrito. La regla define qué ocurre cuando se cumple.
Una regla puede contener muchas condiciones:
| Condición promocional | Ejemplos | Qué puede cambiar entre plataformas |
|---|---|---|
| Elegibilidad de productos | SKU, variantes, categorías, colecciones, brands, etiquetas, proveedors o atributos | El destino puede usar tipos de objeto o lógica de consulta distinta |
| Exclusiones | Artículos en oferta, clearance, gift cards, marcas restringidas, paquetes de productos, suscripciones o variantes | Puede haber soporte limitado o requerir otra regla |
| Elegibilidad del cliente | Customer grupos, etiquetas, segmentos, dominios de email, memberships, fidelización level o cuenta B2B | Los modelos de segmentación pueden no corresponder uno a uno |
| Umbral del carrito | Gasto mínimo, cantidad mínima, gasto máximo, número de artículos o subtotal tras exclusiones | El umbral puede calcularse antes o después de descuentos, impuestos o envío |
| Acción | Porcentaje, importe fijo, buy-one-get-one, artículo gratuito, free envío, oferta escalonada o paquete de productos price | Algunas acciones pueden ser nativas y otras requerir aplicaciones |
| Límite de uso | Por cliente, código, pedido, lifetime o campaña | El historial de uso puede no transferirse igual |
| Periodo | Fecha inicio/fin, campaña programada, zona horaria o ventana recurrente | Depende de timezone y scheduler de la plataforma |
| Regla de combinación | Combinar con descuentos de producto, pedido, envío, fidelización rewards o ajustes manuales | La lógica de stacking suele ser específica de plataforma |
| Prioridad | Qué regla se aplica primero o gana conflictos | Puede ser explícita, implícita o no existir |
Un código de cupón puede parecer idéntico después de la migración y comportarse de otra manera. El código es solo el identificador visible. El motor de reglas controla calificación, exclusiones, importe, combinación y cálculo final.
Orden de cálculo y combinación de descuentos
El orden de cálculo es una de las diferencias más importantes entre plataformas. Dos tiendas pueden utilizar la misma etiqueta de descuento y obtener totales diferentes si una aplica el descuento por línea antes de impuestos y otra al subtotal después de otros descuentos.
Preguntas habituales:
- ¿El descuento se aplica a la línea, subtotal, cargo de envío, importe con impuestos o sin impuestos?
- ¿El sale price sustituye al base price antes de calcular el cupón?
- ¿Puede aplicarse un cupón a un artículo que ya está descontado?
- ¿Pueden combinarse descuentos de producto y pedido?
- ¿El descuento de free envío se evalúa antes o después de elegir método de envío?
- ¿La plataforma prorratea descuentos de pedido entre líneas?
- ¿La lógica de refunds mantiene la asignación original del descuento?
- ¿La plataforma redondea cada línea, cada impuesto o solo el total final?
La combinación es especialmente sensible. Algunas plataformas permiten varios descuentos automáticos y códigos simultáneos. Otras permiten un único código, separan descuentos de producto y pedido, limitan combinaciones con free envío o necesitan aplicaciones para lógica avanzada. Si estas reglas cambian, una promoción puede volverse demasiado generosa, demasiado restrictiva o comercialmente diferente aunque el porcentaje visible parezca igual.
Cómo difieren los modelos entre plataformas
Las plataformas varían en cuánto de la lógica es nativa, configurable, controlada por extensiones o administrada por sistemas externos.
Las plataformas SaaS suelen ofrecer precios estructurados, precios por variante, discount codes, automatic discounts, precios por mercado y extensiones mediante aplicaciones. Simplifican administración, pero pueden limitar combinaciones, B2B avanzado, prioridad de reglas o campañas complejas sin aplicaciones adicionales o planes superiores.
Las plataformas Open-Source suelen dar acceso más profundo a catalog price rules, cart price rules, grupos de clientes, clase fiscales y tablas de extensiones. Esto facilita lógica comercial compleja, pero los datos pueden estar repartidos entre tablas core, módulos, atributos personalizados, configuración serializada y código. Una promoción visible puede depender de varios registros propiedad de una extensión.
Las plataformas enterprise pueden separar precios en price books, shared catalogs, grupos de clientes, websites, mercados, contratos y cuentas. El B2B puede depender de jerarquía de cuentas, permisos de empresa, buyer role, contrato negociado, purchase list o sincronización ERP. Un solo producto puede tener muchos precios según cliente y canal.
En tiendas omnichannel o conectadas a marketplaces, la plataforma de comercio puede no ser la única fuente. Los precios pueden llegar desde ERP, POS, PIM, herramientas de marketplace, reprecios engines o channel managers. En ese caso, la tienda muestra y procesa precios, pero la origen of truth puede estar fuera.
Relaciones con otros datos de la tienda
Los precios y promociones dependen intensamente de estructuras relacionadas. Una promoción de categoría depende de asignaciones a categorías o colecciones. Un precio por nivel depende de grupos de clientes o segmentos. Un paquete de productos discount depende de relaciones de producto e inventario. Una suscripción depende de datos de billing recurrente. Una promoción regional depende de mercado, moneda, envío zone, impuestos o ubicación.
Dependencias habituales:
| Dependencia | Impacto en precio o promoción |
|---|---|
| Productos y variantes | Determina si el precio o descuento aplica al producto principal, SKU, paquete de productos, kit o configurable choice |
| Atributos y etiquetas | Pueden controlar elegibilidad, exclusiones, colecciones automáticas, sale pages o etiquetas |
| Categorías y colecciones | Suelen controlar catalog rules, landing-page discounts, promociones estacionales y grupos de merchandising |
| Customer grupos y segmentos | Determinan B2B, mayorista, fidelización, membership, employee o VIP precios |
| Configuración fiscal | Controla precios con impuestos, clase fiscales, cálculo regional y facturación |
| Envío zones y métodos | Controlan free envío, ofertas regionales, umbrales e incentivos en proceso de compra |
| Moneda y mercado | Controlan precios locales, redondeo, visualización y diferencias de cambio |
| Inventario y procesamiento de pedidos | Pueden afectar paquetes de productos, pedidos pendientes por falta de stock, suscripciones y venta regional |
| Sistemas externos | Pueden sobrescribir o sincronizar precios, descuentos, elegibilidad o totales |
Una regla de precios debe revisarse junto con las estructuras de las que depende. Si cambia el modelo de variantes, se reconstruyen categorías o los grupos de clientes pasan a etiquetas o segmentos, la promoción puede necesitar reinterpretación aunque el nombre sea reconocible.
Funciones específicas de plataforma y comportamientos exclusivos
Algunas capacidades están ligadas a funciones que no existen en todas las plataformas. Pueden ser nativas, basadas en aplicaciones, extensiones, enterprise o sincronizadas externamente.
Ejemplos importantes:
- listas de precios por mercado y precios regional;
- customer-group y B2B account precios;
- shared catalogs y price books por empresa;
- quantity breaks y precios mayoristas por volumen;
- descuentos de suscripción y reglas de pedidos recurrentes;
- cálculos de precio de paquetes de productos, kits y configurables;
- canje de fidelización points y reward credit;
- interacción entre gift cards y store credit;
- descuentos automáticos sin cupón;
- buy-one-get-one y free gifts;
- redondeo por moneda, mercado, impuesto o proveedor de pago;
- precios controlados por ERP y contratos de cuenta;
- reprecios de marketplace y precios por canal.
Estos comportamientos no son intercambiables. Un precio por grupo de clientes no es siempre equivalente a un descuento por customer etiqueta. Una catalog rule no equivale siempre a una regla del carrito. Compare-at price no es lo mismo que un sale price con calendario. Un paquete de productos price calculado por una aplicación no equivale a un precio nativo de variante. Preservar el resultado comercial exige identificar qué función de la plataforma producía el comportamiento original.
Qué suele fallar cuando se interpreta mal la lógica de precios
Los problemas pueden ser difíciles de detectar porque el registro administrativo parece correcto y el resultado en tienda o proceso de compra es incorrecto.
| Patrón de fallo | Causa probable | Impacto |
|---|---|---|
| Código de cupón correcto, importe equivocado | Cambió la acción o el subtotal elegible | Quejas, errores de campaña, pérdida de margen |
| Descuento aplicado a productos excluidos | La exclusión no se trasladó bien | Riesgo de margen y políticas de marca |
| Clientes mayorista ven precios retail | Cambió la relación de grupo de clientes o lista de precios | Fricción B2B y soporte |
| Sale distintivo sin el precio calculado previsto | Display price y active price están separados | Confusión y merchandising incorrecto |
| Total de carrito distinto | Cambió orden, impuestos o redondeo | Abandono, diferencias contables y refunds complejos |
| Free envío demasiado amplio o ausente | Cambió regla, zona, umbral o método | Pérdida de margen o caída de conversión |
| Desaparece fidelización o suscripción discount | No se recreó lógica de aplicación o externa | Problemas de retención y pedidos recurrentes |
| Multi-currency deriva inesperadamente | Cambió cambio, market price o redondeo | Inconsistencia regional y informes |
Estos problemas son estructurales y suelen provenir de modelos no equivalentes, no de etiquetas ausentes.
Cómo inspeccionar datos de precios y promociones antes de migrar
Una revisión útil debe separar valores de precios y lógica comercial. El valor es el número almacenado en producto o variante. La lógica es el conjunto de condiciones que decide cuándo cambia.
Conviene revisar:
- productos y variantes con precios no estándar;
- sale prices activos y campañas programadas;
- precios por grupo de clientes, mayorista, B2B o membership;
- tiered, volume, suscripción y paquete de productos precios;
- cupones activos y descuentos automáticos;
- catalog rules y regla del carritos;
- límites de uso, fechas, prioridades y stacking;
- dependencias de producto, categoría, cliente, región, envío e impuestos;
- precios controlado por aplicaciones, extensiones, ERP, POS, fidelización, suscripción o marketplace;
- reglas históricas que deberían retirarse en lugar de transferirse.
La revisión más sólida empieza por escenarios comercialmente importantes, no por todos los cupones obsoletos. Las ofertas activas alrededor del lanzamiento, precios B2B, fidelización discounts, suscripción prices, exclusiones sensibles al margen y umbrales de free envío merecen más atención que campañas antiguas vencidas.
Implicaciones de migración para precios y promociones
La migración debe preservar los resultados comerciales previstos allí donde la plataforma de destino pueda soportarlos. Algunos datos pueden moverse como valores directos. Algunas reglas deben recrearse en configuraciones nativas. Otros comportamientos necesitan reemplazo de aplicación, configuración, setup manual o tratamiento personalizado porque el destino utiliza otro modelo.
La principal implicación es que los precios deben validarse mediante escenarios realistas de cliente y carrito. Una regla no debe aprobarse solo porque el cupón o el valor aparezcan en administración.
Escenarios importantes:
- producto retail normal sin promoción;
- variante con precio distinto al producto principal;
- producto con sale price y compare-at;
- descuento por categoría o colección;
- precio por grupo de clientes o cuenta B2B;
- quantity break o tiered price;
- cupón con exclusiones y límites;
- carrito con descuentos combinables o no combinables;
- umbral de free envío;
- pedido sensible a impuestos;
- pedido multi-currency o regional;
- escenario de suscripción, paquete de productos, fidelización o extensión-driven precios.
Cuando una regla no puede representarse mediante mapeo directo, conviene separar la respuesta necesaria en transformación de valores, mapeo de relaciones, selección de registros, configuración de destino o lógica adaptada. Reglas propiedad de aplicaciones, tablas de precios personalizadas, identificadores externos y cálculos a medida requieren interpretación explícita y evidencia de aceptación, no la suposición de que mover valores almacenados recreará el comportamiento.
Conclusión
La lógica de precios y promociones es un problema de arquitectura de datos, no solo una configuración de marketing. El precio visible, cupón o etiqueta de descuento es la superficie de un sistema que puede incluir productos, variantes, categorías, clientes, impuestos, zonas de envío, monedas, sistemas externos y un orden de cálculo específico de plataforma.
Antes de migrar, la tarea más importante es identificar qué comportamientos comerciales deben seguir siendo correctos tras el lanzamiento. Base prices, sale prices, customer-group precios, tiered precios, regla del carritos, catalog rules, incentivos de envío y descuentos gestionados por extensiones deben revisarse según las estructuras y funciones que los producen.
Para comportamientos complejos, utiliza escenarios representativos de carrito para validar el resultado. Si una regla depende de estructuras de descuento no compatibles, lógica personalizada, datos de aplicaciones o extensiones, fuentes de precio externas o funciones no equivalentes, aclara el tratamiento necesario antes de la ejecución general.
Preguntas frecuentes
¿Por qué la misma promoción puede comportarse distinto en otra plataforma?
Porque una promoción depende de mucho más que su nombre o código. Condiciones de elegibilidad, exclusiones, reglas de subtotal, momento de impuestos, comportamiento de envío, stacking, prioridad, límites de uso y redondeo pueden variar entre motores de reglas.
¿Cuál es la diferencia entre un precio de producto y una precios rule?
Un precio es un valor almacenado asociado a producto, variante, lista de precios o mercado. Una precios rule decide cuándo cambia ese valor o cuándo se aplica un descuento adicional según cliente, carrito, producto, categoría, cantidad, fecha, envío u otras condiciones.
¿Deben migrarse las promociones caducadas?
No siempre. Las promociones vencidas, obsoletas, de prueba o de bajo impacto pueden retirarse. Campañas activas, precios específicos por cliente, ofertas de lanzamiento, mayorista precios, fidelización rules, suscripción discounts y exclusiones sensibles al margen necesitan revisión más profunda.
¿Cómo debe validarse la lógica de precios y promociones?
Mediante escenarios realistas de cliente y carrito. Revisa descuentos por producto, exclusiones, customer-group prices, tiered precios, stacking, free-envío thresholds, totales fiscales, precios regionales y lógica controlada por extensiones.
¿Cuándo necesita tratamiento personalizado la lógica de precios?
Puede ser necesario cuando el resultado depende de transformaciones de reglas no compatibles, datos de aplicaciones o extensiones, fidelización lógica, suscripción precios, price books específicos por cliente, precios externo de ERP/POS, stacking complejo o cálculos a medida que la plataforma de destino no puede recrear directamente.