El endpoint de predicción de ventas devuelve campos llamados estDailySales y estMonthSales.
est es estimated. La API reconoce, al nivel del nombre del campo, que es un número derivado. No es un descargo de responsabilidad: es información que debería cambiar cómo lo usas. El marketplace no publica las unidades reales de ningún producto, así que ese "2.965 unidades al mes" que ves en cualquier herramienta, extensión o informe está calculado, no consultado.
Conviene establecer primero cómo se calcula, porque eso decide qué conclusiones puedes sacar.
El endpoint de BSR deja el modelo a la vista
De los tres endpoints de ventas, el más revelador es la predicción por BSR, en POST /v1/amazon/sales/prediction/bsr.
Sus entradas son marketplace, bsr y categoryId.
Fíjate en lo que falta: no hay ASIN. Nunca le dices de qué producto se trata. Le dices "marketplace de Estados Unidos, esta categoría, puesto 1024" y devuelve estDailySales y estMonthSales.
Lo que significa que el modelo es una curva: dada una categoría, el puesto se traduce en ventas. Qué producto es, cuánto cuesta o lo bien redactado que esté el listing no entran en el cálculo.
Una vez asumido esto, varias cosas se explican solas:
- Por qué el mismo ASIN muestra ventas mensuales distintas en herramientas distintas: curvas distintas, mismo puesto
- Por qué las categorías no son comparables: cada categoría es su propia curva, y el puesto 1.000 en Juguetes no es el puesto 1.000 en Automoción
- Por qué una oscilación de puesto mueve tanto la estimación: el puesto es la única entrada
Para qué sirve cada uno de los tres
| Predicción por BSR | Predicción por ASIN | Tendencia de ventas por ASIN | |
|---|---|---|---|
| Ruta | /v1/amazon/sales/prediction/bsr | /v1/amazon/sales/prediction/asin | /v1/amazon/asin/sales-trend |
| Entrada | bsr + categoryId + marketplace | asin | asin + marketplace |
| Devuelve | estDailySales, estMonthSales, itemList | asinDetail más dailyItemList, monthItemList | Un objeto asin más salesTrendPoints |
| Úsalo para | Convertir un puesto en un orden de magnitud, criba masiva | Series diaria y mensual de un producto | Serie mensual, separando padre e hijo |
Elegir entre ellos es simple: si solo tienes el puesto, el primero; si tienes un ASIN y quieres una serie temporal, el segundo; si necesitas separar padre e hijo, el tercero.
Endpoint de predicción de ventas por ASINRecibe un ASIN y devuelve el detalle del producto más las series de ventas diaria y mensual, con las tablas completas de camposUn detalle: el endpoint por ASIN quita el prefijo est
El endpoint de BSR devuelve estDailySales. En el endpoint por ASIN, el elemento correspondiente dentro de dailyItemList se llama simplemente sales, igual que el de monthItemList.
Cambió el nombre, no la naturaleza del número. Sigue siendo derivado. Y hay una prueba directa en la respuesta: cada fila de dailyItemList lleva a la vez bsr y sales, es decir, la entrada y la salida en la misma fila.
Así que en tus propias tablas márcalo con una columna en lugar de fiarte del nombre del campo. Qué números son hechos y cuáles derivados debería existir de forma explícita en tu modelo de datos:
| Campo | Naturaleza | Nota |
|---|---|---|
price, averagePrice | Hecho | Público en la página, citable tal cual |
bsr | Hecho | El puesto que publica el marketplace |
ratings, rating | Hecho | Número de valoraciones y valor medio |
sales, estDailySales, estMonthSales | Derivado | Convertido desde el BSR |
amount, parentSalesRevenue, childSalesRevenue | Derivado | Unidades derivadas × precio: dos capas de error |
Esa última fila merece mirarse aparte. Los ingresos son un recuento derivado multiplicado por un precio, y los errores se acumulan. Vale si solo necesitas el orden de magnitud; si construyes un modelo de márgenes encima, estás apilando un supuesto sobre dos estimaciones.
El error de comparación más común: padre frente a hijo
Dentro de salesTrendPoints, en el endpoint de tendencia, conviven cuatro campos:
parentUnitSales: unidades del padrechildUnitSales: unidades del hijoparentSalesRevenue: ingresos del padrechildSalesRevenue: ingresos del hijo
En un listing de ropa con ocho colores, las unidades del padre son el total de las ocho variaciones; las del hijo son el color concreto que consultaste.
Comparar las unidades padre del producto A contra las unidades hijo del producto B puede desviarse varias veces, y nada falla: simplemente obtienes una conclusión de aspecto razonable. Buena parte de los "este listing nos vende muchísimo más" de los informes de competencia sale exactamente de ahí.
La regla es simple: compara lo mismo con lo mismo. O todo padre o todo hijo, y escribe cuál en la cabecera de la columna.
Tres cosas que estos datos hacen bien
Ordenar dentro de una categoría. Misma curva, así que el orden relativo es fiable. Responder "cuál de estos veinte competidores va por delante" es lo que mejor hacen.
Juzgar la magnitud. Diez unidades al día y quinientas al día son negocios distintos, y distinguirlos no requiere precisión.
Leer la dirección. Usa dailyItemList o salesTrendPoints sobre una ventana: aunque el valor absoluto esté desviado, subir o bajar suele ser fiable, porque el sesgo va en el mismo sentido a lo largo de una única curva.
Tres cosas que no pueden hacer
Servir de promesa detrás de una orden de compra. Un número derivado te dice aproximadamente cuánto vale esa posición; no te dice cuánto venderás tú cuando llegues a ella.
Comparar entre categorías. Categorías distintas son curvas distintas, así que los puestos son comparables y las estimaciones de ventas no. Compara el percentil de puesto dentro de la categoría.
Cuadrar tu contabilidad. Tus ventas reales están en Seller Central y en SP-API como datos exactos y autorizados. Verificar tus propias cuentas contra una estimación es validar un hecho con una conjetura. Cómo elegir una API de datos de Amazon cubre esa frontera al completo.
Cómo marcarlo en la hoja
Si estás montando una hoja de investigación, Cómo rellenar una hoja de investigación de productos de Amazon cubre la estructura entera. Para este grupo de campos bastan tres reglas:
- Pon un sufijo o un color a las columnas de ventas para que se distingan de precio y BSR
- Registra la hora de consulta en cada fila: si el puesto se movió, la estimación se movió
- Indica padre o hijo en la cabecera
Con eso, seis meses después seguirás pudiendo decir qué números de esa hoja son citables.
Preguntas
¿Por qué las herramientas no coinciden en las ventas mensuales? Porque las curvas de conversión difieren. El puesto es público y común; la curva es propia de cada proveedor. Cierta dispersión es normal y la magnitud debería parecerse. Si ni la magnitud coincide, comprueba primero que ambas miran el mismo nivel de categoría.
¿Cuán precisas son las estimaciones? Depende de la categoría y del tramo de puesto. Los puestos altos tienen muestras densas y estiman con relativa estabilidad; la cola larga es escasa y oscila más. No esperes una tasa de error única.
¿Puedo obtener las ventas reales de un competidor? No. Las ventas reales solo existen en la cuenta de ese vendedor y en sus datos autorizados. Cualquier cosa que prometa ventas exactas de la competencia sigue siendo, por dentro, una estimación.
¿Debo usar padre o hijo? Depende de la pregunta. Usa padre para juzgar si vale la pena entrar en un modelo; usa hijo para juzgar si merece la pena aprovisionar un color o una talla. Lo importante es que toda la hoja sea coherente.