盯竞品价格这件事，手工做的问题不是累，而是你只会在想起来的时候看。降价发生在周二凌晨，你周五才发现，这期间的流量已经过去了。
一天跑一次的定时任务能解决这个问题，用三个接口就够。
export ECOMMERCE_DATA_API_KEY="your_api_key"三个接口各管一段时间
每天都要跑的只有第一个。 优惠券趋势按周跑够了，历史曲线只在需要判断"这次降价算不算大"时才调。这个分工直接决定调用量。
每日快照
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": "US",
"asin": "B08CK5Z5Q1"
}'把每天的返回结果按 (asin, 日期) 落库，而不是只保留最新值。只存最新值等于放弃了变化检测——你需要昨天的数值才能知道今天变了什么。
如果同时要看优惠券，用 商品详情与优惠券趋势 一次拿到，比分两次调用省一次计费。
优惠券节奏
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": "US",
"asin": "B08CK5Z5Q1"
}'优惠券的价值在节奏而不在当下状态。竞品是长期挂券还是在特定时间点集中发券，决定你要不要跟。单看今天有没有券，得不出结论。
历史曲线
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": "US",
"asin": "B08CK5Z5Q1"
}'这个接口回答的是"这次变动在历史上算什么量级"。没有它，你的告警会把常规波动和真实动作混在一起报。
告警阈值怎么定
不要用固定百分比。 "降价超过 5% 就告警"在不同价格带上完全不是一回事。可行的做法是用历史区间做基准：
- 价格跌破历史 N 天最低 → 值得看。
- BSR 在一天内跨越一个量级（比如从 5 位数进 4 位数）→ 值得看。
- 卖家数突增 → 可能出现跟卖，优先级高于价格变动。
- 评论数单日异常增长 → 记录但不一定要动作。
前两条需要历史数据，这就是第三个接口的作用。
调度与调用量
假设监控 50 个竞品 ASIN：
| 任务 | 频率 | 每次调用 | 每月约 |
|---|---|---|---|
| 每日快照 | 每天 | 50 | 1,500 |
| 优惠券趋势 | 每周 | 50 | 200 |
| 历史曲线 | 触发时 | 按需 | 视告警数量 |
一次成功的计费请求默认消耗 1 次调用，所以监控成本基本等于"ASIN 数 × 频率"。想压成本就减 ASIN 数或降频率，不要靠减字段——同一个接口返回全部字段，计费一样。各调用包的规模见定价。
工程上必须处理的三件事
一、限流按账号算。 50 个 ASIN 串行跑没问题，别开 50 个并发。429 时按 Retry-After 退避，完整错误码见错误与限流。
二、失败不计费，所以可以重试。 返回结果前就失败的请求不计费。给任务加重试，但要限制次数并记录 X-Request-Id，方便排查。
三、区分"值变了"和"没查到"。 接口失败时不要把字段写成 0 或空——那会在曲线上变成一次假的暴跌。失败就跳过这一天并标记。
限制
- 快照是查询时刻的值。一天跑一次意味着日内的短时变动看不到。
- BSR 和价格是平台可见字段，可核对；销量类字段是估算值。
- 历史数据的粒度和覆盖范围取决于接口返回，不保证每个 ASIN 都有同样长的历史。
- 这套流程监控的是公开市场数据，不包含你自己的广告花费、库存和订单——那些要从你自己的后台导出。
不想写调度脚本可以先用 Agent 手动跑一遍同样的流程，见在 Cursor 里做竞品分析。