Casi todo el que busca una "base de datos de Amazon" quiere un conjunto que pueda descargar y consultar con calma.
Eso no existe, y no porque nadie lo haya construido. Lo deciden dos hechos estructurales: los datos se parten por fronteras de autorización en tres bloques que nadie posee enteros, y son un flujo y no un almacén: cada cifra solo vale durante un tiempo.
Primero: los datos se parten por de quién son
| Bloque | Quién puede obtenerlo | Contenido típico |
|---|---|---|
| Los de tu tienda | Solo tú, con autorización de cuenta de vendedor | Pedidos, inventario, liquidaciones, gasto publicitario, informe de términos |
| El lado público del marketplace | Todos | Productos, precios, puestos, reseñas, categorías, palabras clave |
| Los que nadie obtiene | Nadie | Pedidos reales de un competidor, sus términos de backend, identidad del comprador |
La tercera fila no es "todavía no": no hay canal público por diseño. Cuando un plan depende de esa fila, lo que cambia es el plan, no la fuente.
Las filas uno y dos vienen de modelos de autorización completamente distintos, así que ningún endpoint da ambas — la razón directa de que "una base con todo" no funcione. Cómo elegir una API de datos de Amazon desglosa qué devuelve cada vía.
Segundo: qué contiene realmente el lado público
El bloque público no es una tabla grande. Es un conjunto de endpoints repartidos por dominio de negocio — 46 ahora mismo, y la densidad varía mucho:
| Dominio | Endpoints | A qué responde |
|---|---|---|
| Mercado / categoría | 14 | Cuán grande es, quién está dentro, cómo se distribuye |
| Tráfico / flujo de términos | 6 | Con qué términos aparece un producto y dónde |
| Nivel ASIN | 5 | Detalle, tendencias y rivales de un producto |
| Marca | 4 | Información de marca y registro |
| Filtrado de productos | 3 | Preseleccionar productos por condiciones |
| Términos ABA | 3 | Puestos publicados de términos y su movimiento |
| Predicción de ventas | 2 | Convertir un puesto en magnitud de ventas |
| Minería y conversión de términos | 4 | Competencia, pujas y conversión de un término |
| Reseñas | 1 | Contenido, estrellas e indicadores de origen |
Mercado se lleva 14, con diferencia el bloque más denso. Eso refleja algo real: los datos públicos responden mejor a "cómo es este mercado" que a "qué hace exactamente este competidor".
Cómo encadenarlos por escenario: La guía completa de las API de datos de Amazon.
Tercero: es un flujo, no un almacén
Aquí está el problema de fondo de "descargar un conjunto". Un mismo campo caduca con órdenes de magnitud de diferencia:
| Campo | Cuánto tarda en caducar | Qué implica |
|---|---|---|
| Precio, cupones | Horas | El precio de ayer no sirve para fijar el de hoy |
| BSR, posición | Días | Un puesto de anoche solo indica dirección |
| Número de reseñas, valoración | Se acumula a diario | Un punto dice poco; el ritmo dice más |
| Estimaciones de ventas | Siguen al puesto | Si se mueve el puesto, se mueve esto |
| Estructura de categoría, mezcla de vendedores | Meses | Vale la pena guardarlo mensualmente |
| Título, marca, fecha de alta | Prácticamente fijo | Se guarda una vez |
Así que "guardar una copia de los datos" siempre significa guardar una instantánea, no los datos. Que esa instantánea sirva depende por completo de si anotaste cuándo se tomó, y por eso todas nuestras plantillas dan columna propia a la fecha de recogida.
¿Entonces puedes guardar una copia?
Puedes, y deberías. Pero por capas, según la tabla anterior: guarda los campos lentos, pide en vivo los rápidos y refresca los intermedios de forma programada.
Cómo hacer ese reparto y estimar el volumen de llamadas: Cinco decisiones antes de integrar. La prueba es simple: si un campo caduca antes de que lo uses, guardarlo solo fabrica datos rancios.
Tres cosas que ninguna fuente ofrece
Los pedidos reales de un competidor. El marketplace no publica unidades, así que toda cifra mensual se deriva del BSR — el est del nombre del campo es la etiqueta de la propia API. Qué dicen y qué no dicen los datos de ventas.
Su informe de términos de búsqueda del backend. Datos autorizados de su cuenta. La búsqueda inversa devuelve términos que aparecieron en resultados públicos: otra fuente, sin correspondencia.
Causalidad. Los datos muestran que la posición cayó. No muestran por qué. Eso exige tu propio registro de cambios.
Preguntas
¿Hay algún conjunto de datos de Amazon listo para descargar? Los datos del lado público se alcanzan por endpoints, pero vuelven como instantánea por consulta y no como conjunto estático. Cuando de verdad necesitas "una copia", suele significar guardar los resultados bajo tu propia semántica.
¿Qué es el "big data de Amazon"? Normalmente el segundo bloque: datos agregados del lado público. Su valor está en la comparación relativa y la tendencia, no en la precisión puntual.
¿Hasta dónde llega el histórico? Depende del campo. Los endpoints de histórico suelen aceptar un mes natural pasado, pero consulta la documentación de cada uno en lugar de suponer que existe cualquier mes antiguo.
¿Y si dos fuentes no coinciden? Alinea tres cosas: marketplace, nivel de categoría y momento de recogida. Los campos públicos deberían coincidir, y que no lo hagan es un problema de semántica. Las ventas son estimaciones, así que discrepar es normal. El método completo está en Análisis de datos de Amazon.