Blog

Cómo normalizar ofertas por ASIN en Amazon México a escala

Normaliza ofertas públicas por ASIN en Amazon.com.mx y valida precio en MXN, envío, condición y vendedor antes de integrar tus datos.


Editor
Data Extraction Read time: 10 minutes
Ilustración editorial de un flujo de datos que lleva tarjetas de productos identificadas por ASIN a una validación y una tabla de ofertas normalizadas para el mercado mexicano, con señales de vendedor, envío, moneda y Oferta Destacada.

Cuando un catálogo tiene decenas o miles de productos, copiar el importe visible de cada página parece rápido, pero no produce una comparación confiable. Una API de ofertas Amazon México sirve para separar lo que cambia por vendedor de lo que identifica al producto. Así, el equipo puede revisar movimientos de precio sin confundir una variante distinta, un envío desconocido o una condición usada con una caída real del mercado.

Este tutorial propone un flujo práctico para equipos de datos, desarrollo, pricing y agencias: definir el universo de ASIN, validar una muestra manual pequeña, recuperar ofertas, normalizar cada fila, conservar la trazabilidad y enviar anomalías a revisión. El objetivo es una cola de decisiones explicable, no un bot que modifique precios sin controles.

Qué resuelve una API de ofertas Amazon México en un flujo por lote

Una respuesta de ofertas describe una foto puntual de alternativas de compra para un producto. En el mismo ASIN puede haber vendedores distintos, precios de artículo diferentes, cargos de envío, condiciones, métodos de cumplimiento y una señal de Oferta Destacada. La API de ofertas Amazon México es útil cuando esos elementos se registran como columnas separadas y se comparan bajo el mismo marketplace, variante y momento de observación.

Piensa en el ASIN como la carpeta del producto y en cada oferta como un documento dentro de esa carpeta. El error común es meter todos los documentos en una sola celda llamada "precio". Ese atajo oculta si el importe corresponde a un vendedor diferente, si incluye envío o si la oferta ya no está disponible. En cambio, una tabla de observaciones permite responder qué cambió, para quién y con qué evidencia.

Pregunta de negocioDato mínimoRegla de lectura
¿Es el mismo producto?ASIN, variante, marketplaceNo mezclar variantes ni dominios
¿Qué vendedor hizo la oferta?seller_id o identificador estable, nombre visibleEl nombre no reemplaza un identificador estable
¿Cuál es el costo comparable?precio de artículo, envío, moneda, condiciónNo sumar envío ausente como cero
¿Quién aparece primero?señal de Oferta Destacada y cumplimientoNo asumir que el menor precio gana
¿Qué tan actual es el dato?observed_at, received_at, fuenteMostrar demoras y datos obsoletos

Antes del lote: fija el catálogo y un piloto de cinco ASIN

Antes de programar cientos de solicitudes, crea una lista de cinco ASIN representativos: uno con varias ofertas, uno con variante, uno con envío visible, uno con una condición alternativa y uno que pueda generar una respuesta incompleta. Para cada producto, abre la página de Amazon México y anota la variante elegida, el vendedor, el precio mostrado, el texto de entrega y la hora de la comprobación. Esta comparación no busca que cada campo esté lleno: busca que el equipo sepa qué significa cada campo cuando aparece.

El piloto también aclara qué no debe compararse. Un paquete de dos unidades no es equivalente a una unidad; una oferta usada no es una reducción del producto nuevo; una oferta con envío no confirmado no permite calcular el total entregado. Si el equipo usa una API de ofertas Amazon México para alimentar alertas, estas reglas deben vivir junto al catálogo, no depender de una interpretación posterior de un analista.

Guarda una versión de la lista inicial con el motivo de cada inclusión, el responsable de la confirmación y la fecha. Si una marca cambia de variante o se retira del catálogo, conserva las observaciones históricas, pero detén las solicitudes futuras. Esa distinción evita que una ausencia posterior parezca un precio de cero o una eliminación de datos válida.

Separa el contexto de producto de las filas de oferta

Primero valida el producto. La operación Product Detail permite comprobar el ASIN, el título visible, la variante y el contexto básico de la página antes de unir información de vendedores. Para un flujo de Amazon México, conserva el dominio .com.mx como parte de la identidad del registro. Un resultado de otro marketplace no es un sustituto local, aunque el ASIN se parezca.

Después recupera las filas de vendedor. La operación Product Offer está pensada para captar ofertas activas con precio, entrega, condición, método de cumplimiento y contexto de Oferta Destacada. Mantén la respuesta original bajo acceso limitado y crea un registro normalizado aparte. La versión limpia debe conservar una referencia al resultado original para que un analista pueda comprobar por qué una fila fue aceptada, rechazada o enviada a revisión.

Esta separación resuelve otro problema frecuente: el precio destacado en la página de producto puede no representar todos los vendedores. El detalle de producto ayuda a confirmar la identidad; las filas de oferta explican la competencia. Para medir cambios con rigor, no copies atributos de una fuente sobre la otra sin marcar su origen y su hora de observación.

Ejemplo: normalizar filas de oferta sin inventar datos

El siguiente ejemplo ilustra una llamada de prueba y una función de normalización defensiva. Ajusta los nombres de campos con una respuesta real de tu cuenta y tu ASIN piloto. No incluyas la clave en código versionado ni registres una URL con parámetros sensibles.

import os

import requests

params = {

"api_key": os.environ["EASYPARSER_API_KEY"],

"platform": "AMZ",

"operation": "OFFER",

"domain": ".com.mx",

"asin": "ASIN_DE_PRUEBA"

}

response = requests.get("https://realtime.easyparser.com/v1/request", params=params, timeout=90)

response.raise_for_status()

payload = response.json()

offer = (payload.get("result") or {}).get("offer") or {}

rows = offer.get("offer_results") or []

def normalize(row, observed_at):

return {

"asin": params["asin"],

"marketplace": params["domain"],

"seller": row.get("seller"),

"item_price": row.get("price"),

"shipping": (row.get("delivery") or {}).get("price"),

"condition": row.get("condition"),

"featured_offer": row.get("buybox_winner"),

"observed_at": observed_at

}

El ejemplo conserva valores potencialmente nulos. Si falta el precio de envío, la columna debe continuar como desconocida. Si no llega una señal de Oferta Destacada, no debe convertirse en false, porque eso afirmaría que la oferta perdió cuando en realidad la señal puede no estar disponible. Aplica la misma cautela a condición, moneda y vendedor.

Diseña el contrato de datos de la API de ofertas Amazon México

Ilustración de un contrato de datos que combina una tarjeta de producto y varias ofertas de vendedores en un registro normalizado con ASIN, precio, envío, condición, vendedor, cumplimiento y hora de observación.

Un contrato de datos define qué admite cada columna, cuál es su fuente y qué acción se toma cuando falta. Es más útil que una lista de campos suelta porque evita que otra persona cambie el significado de una columna para completar una celda vacía. Por ejemplo, item_price es el importe del artículo, mientras que delivered_total solo existe cuando precio, moneda y envío son comparables y conocidos.

Campo normalizadoPropósitoControl de calidad
asin, marketplace, variantIdentidad del producto observadoDebe coincidir con el catálogo aprobado
seller_id, seller_nameIdentidad de la ofertaPreferir identificador estable; marcar ausencias
item_price, currency, raw_priceImporte mostrado y su contextoGuardar texto original y no redondear prematuramente
shipping_price, delivery_textComponente logísticoNo interpretar vacío como entrega gratuita
condition, fulfillment, featured_offerCondiciones de comparabilidadSeparar desconocido de negativo
observed_at, received_at, source_refTrazabilidad temporal y de origenRegistrar demoras y permitir auditoría
quality_status, reason_codeResultado de las reglasUsar aceptado, revisión o reintento con motivo

Convierte los valores monetarios a un decimal o a centavos solo después de validar la moneda y el separador recibido. Conserva también el valor original. Esto es importante en datos localizados: una cadena con coma, punto, símbolo de moneda o texto promocional no debe tratarse automáticamente como un número comparable. El control debe detener cálculos de total si el valor no puede interpretarse con confianza.

Escala con programaciones, lotes y datos que envejecen

Una API de ofertas Amazon México entrega observaciones actuales; una serie de cambios la construye tu proceso a partir de observaciones repetidas. Guarda tanto observed_at, cuando la fuente lo provea, como received_at, cuando tu sistema recibió el resultado. Si un trabajo asíncrono termina tarde, la hora de llegada no equivale necesariamente a la hora en que cambió una oferta.

Para un lote, modela estados sencillos: planificado, enviado, recibido, normalizado, revisión necesaria y reintento. El envío de un trabajo no confirma que todas las filas llegaron. Conciliar significa comparar los ASIN esperados con los resultados recibidos, identificar faltantes y volver a procesar solo los que requieren acción. Evita volver a consultar el catálogo completo porque un solo producto falló.

Usa una clave de idempotencia basada en el identificador de trabajo y el resultado, o en una huella estable cuando el proveedor no entregue esos valores. Así, un callback repetido no crea dos observaciones idénticas. Sin embargo, dos ejecuciones programadas distintas deben conservarse aunque el precio no cambie: esa continuidad permite medir antigüedad y separar un precio estable de una falta de actualización.

Envía anomalías a una cola, no a una regla automática

Ilustración de una cola de ASIN que pasa por validación y se divide en tarjetas aprobadas, de revisión y de reintento, con iconos de precio, vendedor, envío y hora.

Una regla de calidad debe ser explícita. Envía a revisión una fila con ASIN no coincidente, moneda inesperada, variante ambigua, precio imposible de interpretar, envío desconocido cuando el cálculo depende del total, vendedor sin identificador estable o hora demasiado antigua. La revisión no es un error del sistema: es el lugar correcto para los casos cuya comparación necesita contexto comercial.

Cuando haga falta ampliar la identidad de un vendedor, Seller Profile puede aportar datos de perfil y feedback para un análisis acotado. Úsalo como enriquecimiento opcional, no como una prueba de cumplimiento ni como un reemplazo de tus políticas de proveedor. También limita la consulta a vendedores relevantes para que el proceso no recopile más datos de los necesarios.

Los paneles deben distinguir "sin resultado", "resultado incompleto" y "oferta desaparecida". No son sinónimos. Una ejecución fallida no prueba que no exista un vendedor; una oferta sin envío no prueba envío gratuito; una respuesta tardía no prueba que el precio siga vigente. Esta semántica protege a los analistas de alarmas engañosas y facilita explicar la decisión a compras, ventas o a un cliente de agencia.

Define una salida de cambio que los equipos puedan auditar

Compara solo registros con la misma clave de comparación: ASIN, marketplace, variante, vendedor o criterio de oferta, condición y contexto de entrega. Si cualquiera cambia, registra un evento de contexto además del posible movimiento de precio. Una variación de MXN 20 en el mismo vendedor y condición puede ser una señal; un cambio de vendedor con diferente envío es una situación distinta.

La salida de cada cambio debe incluir valor anterior, valor nuevo, diferencia, moneda, hora de ambas observaciones, campos de contexto y estado de calidad. Los equipos de pricing pueden combinar esa salida con sus costos, márgenes, límites y políticas internas. Este conjunto de ofertas no contiene por sí solo el costo de adquisición, las comisiones reales ni una instrucción para modificar un precio.

Como prueba de aceptación, ejecuta el piloto dos veces con la misma entrada y confirma que un resultado repetido no duplica la fila. Luego simula un envío desconocido, una variante incorrecta y un resultado tardío. El proceso debe bloquear un total calculado cuando falte un componente, conservar el motivo de la excepción y permitir que una persona valide la salida antes de activar una integración posterior.

Conclusión: normaliza antes de decidir

Una API de ofertas Amazon México es valiosa cuando conserva la historia completa de cada oferta, no cuando reduce todo a un número. Empieza con cinco ASIN, separa producto y vendedor, valida moneda y envío, guarda trazabilidad y escala solo después de aprobar las excepciones. Con ese orden, Easyparser puede alimentar una cola verificable para análisis competitivo, sin convertir datos incompletos en decisiones automáticas.

Start extracting Amazon data for free

Start Your Free Trial

100 free credits, no credit card required.

Frequently Asked Questions (FAQ)

Como mínimo, conserva ASIN, marketplace, variante, vendedor, precio de artículo, moneda, envío, condición, cumplimiento, señal de Oferta Destacada, hora de observación, estado de calidad y una referencia al resultado fuente. Un campo ausente debe seguir siendo ausente, no convertirse en cero o falso.

No. Precio, envío, condición, cumplimiento, desempeño del vendedor y contexto de entrega pueden diferir. Guarda la señal de Oferta Destacada separada del precio más bajo y no infieras una a partir de la otra.

En este flujo se usa el dominio .com.mx y se valida que la respuesta corresponda al marketplace, la moneda y el contexto esperados. Confirma los parámetros disponibles y los valores devueltos con un piloto local antes de ampliar el catálogo.

Una instantánea actual no es un historial previo. Tu serie empieza en la primera observación que conservas. Programa nuevas observaciones, guarda sus marcas de tiempo y muestra los huecos de ejecución en vez de inventar valores faltantes.

No lo trates como envío gratuito. Conserva el precio de artículo, marca el costo total entregado como incompleto y envía el registro a revisión si una decisión depende del total. El texto de entrega y el contexto de ubicación también pueden importar.

No necesariamente. SP-API está orientada a aplicaciones y roles autorizados de socios vendedores. Un flujo que observa páginas públicas debe documentar su propia fuente, permisos, controles de calidad y límites operativos, sin presentarse como acceso a datos privados de Seller Central.

Solo después de validar identidad de producto, variante, moneda, condición, envío, antigüedad y duplicados en un piloto. Al principio, dirige los cambios a una cola con revisión humana y define límites de costo, amplitud de cambio y condiciones de detención fuera de este conjunto de datos.
Tags
API de ofertas Amazon Méxicodatos de ofertas Amazon Méxicoofertas por ASIN Amazonprecio envío vendedor Amazondatos de precio MXN Amazonnormalización de ofertas Amazonprocesamiento por lote de ASINintegración de datos Amazon