El "análisis de datos de Amazon" suele tratarse como una cuestión de herramientas: qué software, qué métricas.
Lo que de verdad se rompe casi nunca son las herramientas. Es que tres clases de dato con estatus completamente distinto acaban en una misma tabla y se usan como si fueran lo mismo.
Tres clases, tres niveles de confianza
| Clase | Ejemplos | De dónde sale | Qué puede sostener |
|---|---|---|---|
| Hecho | Precio, BSR, número de valoraciones, texto de reseñas | Publicado, comprobable | Se cita tal cual |
| Estimación | Unidades y ingresos mensuales, tamaño de mercado | Derivado del BSR y otras señales públicas | Solo magnitud y dirección |
| Criterio | Si merece entrar, dónde está el problema | Lo añade una persona o un modelo | Indica de quién es el criterio |
El error caro es usar la segunda como si fuera la primera.
El endpoint de predicción llama a sus campos estDailySales y estMonthSales: el est es la etiqueta que pone la propia API. El marketplace no publica unidades vendidas de ningún producto, así que "2.965 unidades al mes" en cualquier sitio está calculado, no consultado. Vale para ordenar magnitudes; no vale como base de un compromiso de compra. Qué dicen y qué no dicen los datos de ventas desarrolla esa capa.
Que la tercera clase se filtre en las dos primeras es el error inverso: poner "creo que esta categoría tiene hueco" en la misma columna que "el 83% de las unidades de esta categoría va a listings de más de tres años" deja a cualquiera, tres meses después, sin saber qué frase la dijeron los datos.
Busca los datos desde la pregunta
El análisis empieza en una pregunta, no en un panel. Las preguntas habituales apuntan a datos distintos:
| Tu pregunta | Qué leer | Dónde |
|---|---|---|
| ¿Puedo entrar aún en esta categoría? | Las cuatro distribuciones | Análisis de categorías |
| ¿Qué producto elijo? | Las cuatro capas de eliminación | Cómo investigar productos |
| ¿Por qué me gana un competidor? | Diferencia de términos y reseñas | Análisis de competencia |
| ¿De dónde viene mi tráfico? | Colocación orgánica frente a pagada | Monitorizar posiciones |
| ¿Qué términos optimizo? | Las cuatro clases de conversión | Optimizar palabras clave |
| ¿Cuánto pujo? | Rangos de puja por concordancia | Pujas en PPC |
| ¿De qué se quejan los compradores? | Origen y clasificación de reseñas | Analizar reseñas |
Partir de una pregunta rinde más que abrir un panel y buscar patrones. Un panel lleva tu atención a lo que más se movió, y lo que más se movió suele ser ruido.
Una regla de registro para todo
Analices lo que analices, cada fila necesita dos cosas anotadas: de qué clase es (hecho, estimación, criterio) y cuándo se recogió.
La marca de tiempo es lo que más se omite y lo que más cuesta omitir. Sin hora de recogida no puedes saber tres meses después si la tabla sigue sirviendo, y posiciones, precios y número de reseñas se mueven a diario.
Por eso todas las hojas que publicamos dan columna propia a la fecha de recogida: la hoja de investigación, la hoja de competencia y la hoja de reseñas.
Tres cosas que ningún dato público puede hacer
Sea cual sea la herramienta, estas tres no se obtienen porque no están en el lado público:
Tus propios datos de cuenta. Pedidos reales, gasto publicitario, informe de términos de búsqueda, inventario: viven en Seller Central como datos autorizados. Los endpoints públicos cubren el lado del mercado. Se complementan y no se sustituyen.
Los datos de cuenta de un competidor. Por la misma razón: solo los ve su cuenta. Cualquier cosa que prometa ventas exactas o términos de backend ajenos es, por dentro, una estimación.
Causalidad. Los datos te dicen que la posición cayó y la conversión bajó. No te dicen por qué. La causa necesita tu propio registro de cambios, lo que hace que fechar las ediciones del listing sea más útil que cualquier herramienta de análisis.
De dónde salen estas fronteras y por qué un modelo no puede cruzarlas está en Por qué la IA no puede responder preguntas de datos de Amazon. Cómo esa misma frontera de autorización parte los datos en tres bloques se explica en de dónde vienen los datos de Amazon.
De leer datos a llamar endpoints
La consulta manual solo se encarece cuando se repite. La prueba es simple: cuando empiezas a hacer lo mismo cada semana — los mismos filtros, los mismos campos exportados, la misma fórmula — toca convertirlo en una tarea programada.
Los 46 endpoints agrupados por trabajo están en La guía completa de las API de datos de Amazon, y lo que hay que cerrar antes de integrar en Cinco decisiones antes de integrar. Cómo hacer que la salida programada sea comparable semana a semana se trata en cómo hacer un informe de datos de Amazon.
Preguntas
¿Por qué métrica empieza un principiante? Por ninguna. Escribe la pregunta que necesitas responder y ve hacia atrás hasta los campos que requiere: descubrirás que la mayoría de las métricas no tienen que ver con tu pregunta.
¿Y si dos herramientas no coinciden? Alinea tres cosas: marketplace, nivel de categoría y momento de recogida. Solo una diferencia que sobreviva a las tres es de semántica. Los campos públicos deberían coincidir; que las ventas no coincidan es normal.
¿Cada cuánto reviso? A la velocidad a la que se mueve el dato. Precios y cupones a diario, la posición solo tiene sentido semanalmente, la estructura de categoría mensual o trimestral. Mirar más rápido de lo que se mueve el dato solo enseña ruido.
¿Puedo pasarle esto directamente a un modelo? Sí, y clasificar le va bien. Pero exige que su salida caiga en la clase de criterio y conserva las columnas originales de hecho y estimación: la conclusión del modelo y el dato tienen que poder separarse.