El problema de vigilar los precios de la competencia a mano no es el esfuerzo. Es que solo miras cuando te acuerdas. La bajada ocurrió el martes a las 3 de la mañana; te diste cuenta el viernes y el tráfico ya se movió.
Una tarea que se ejecuta una vez al día resuelve eso, y bastan tres endpoints.
export ECOMMERCE_DATA_API_KEY="your_api_key"Cada endpoint cubre un rango temporal distinto
| Endpoint | Rango | Para qué sirve |
|---|---|---|
| Product Details | Ahora | Precio, BSR, valoración, reseñas y vendedores de hoy |
| Coupon Trends | Reciente | El ritmo de activación de promociones |
| Product History | Largo plazo | Curvas de precio y ranking, para juzgar si el movimiento de hoy es inusual |
Solo el primero necesita ejecutarse a diario. Los cupones semanalmente son suficientes, y la curva histórica solo cuando hay que decidir si una bajada es grande. Ese reparto es lo que determina tu volumen de llamadas.
La foto diaria
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/asin/detail \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "ES",
"asin": "B08CK5Z5Q1"
}'Guarda la respuesta de cada día con clave (asin, fecha) en lugar de conservar solo el último valor. Conservar solo el último valor equivale a renunciar a la detección de cambios: necesitas la fila de ayer para saber qué se movió hoy.
Si quieres los cupones a la vez, Product Details with Coupon Trends devuelve ambos en una llamada, es decir una unidad facturable en lugar de dos.
Cadencia de cupones
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/asin/coupon-trend \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "ES",
"asin": "B08CK5Z5Q1"
}'El valor de los datos de cupones está en el ritmo, no en el estado actual. Que un competidor mantenga un cupón permanente o los concentre en fechas concretas decide si lo sigues. La bandera de hoy, sola, no sostiene ninguna conclusión.
La curva histórica
curl --request POST \
--url https://ecommercedataapi.com/v1/amazon/keepa/detail \
--header "Content-Type: application/json" \
--header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
--data '{
"marketplace": "ES",
"asin": "B08CK5Z5Q1"
}'Este endpoint responde a «qué magnitud tiene este movimiento en términos históricos». Sin él, tus alertas mezclan ruido rutinario con acciones reales.
Cómo fijar umbrales de alerta
No uses un porcentaje fijo. «Avisar de cualquier bajada superior al 5 %» significa cosas muy distintas según la banda de precio. Usa rangos históricos como línea base:
- El precio cae por debajo del mínimo histórico de N días → merece mirarlo.
- El BSR cruza un orden de magnitud en un día (de cinco cifras a cuatro) → merece mirarlo.
- El número de vendedores salta → posibles nuevos revendedores, prioridad mayor que un cambio de precio.
- Las reseñas se disparan en un solo día → regístralo, pero no siempre requiere acción.
Los dos primeros necesitan histórico, y para eso está el tercer endpoint.
Programación y volumen de llamadas
Supongamos 50 ASIN de competencia:
| Tarea | Frecuencia | Llamadas por ejecución | Aprox. al mes |
|---|---|---|---|
| Foto diaria | Diaria | 50 | 1.500 |
| Cupones | Semanal | 50 | 200 |
| Curva histórica | Por disparo | Según necesidad | Depende de las alertas |
Una petición facturable correcta consume una llamada por defecto, así que el coste de monitorización es básicamente «número de ASIN × frecuencia». Para recortar coste, reduce ASIN o frecuencia, no campos: el endpoint devuelve todos sus campos y factura igual. Los tamaños de paquete están en precios.
Tres cosas que la implementación debe resolver
Una: los límites son por cuenta. Cincuenta ASIN en serie está bien; cincuenta en paralelo no. Aplica espera ante un 429 usando Retry-After; la lista completa de errores está en errores y límites.
Dos: los fallos no se facturan, así que reintentar es seguro. Las peticiones que fallan antes de devolver un resultado facturable no se cobran. Añade reintentos, limítalos y registra X-Request-Id para poder diagnosticar.
Tres: distingue «el valor cambió» de «la consulta falló». Ante un fallo, no escribas 0 ni un valor vacío: eso se convierte en una caída falsa en tu curva. Salta ese día y márcalo.
Límites
- Una foto es el valor en el momento de la consulta. Una vez al día implica que los movimientos intradía son invisibles.
- El BSR y el precio son visibles en la plataforma y verificables; las cifras de ventas son estimaciones.
- La granularidad y la cobertura históricas dependen de lo que devuelva el endpoint. No todos los ASIN tienen un histórico igual de largo.
- Este flujo monitoriza datos públicos de mercado. No incluye tu inversión publicitaria, tu inventario ni tus pedidos: exporta eso desde tu propio panel.
Para ejecutar el mismo flujo a mano antes de escribir un planificador, delégalo a un agente: Análisis de competencia en Cursor o Codex.