去年 11 月 24 日凌晨两点，一个做厨房小家电的卖家在群里发了一句"完了"。他的主力款在 11 月 22 日晚 8 点被竞品降价截流，从 39.99 美金降到 29.99 美金，还给了一个 15% 的优惠券叠加。他的竞品监控系统直到 11 月 24 日上午 10 点才发出第一次告警，延迟了整整 38 个小时。
那天他问我一个问题：不是说监控系统已经上了吗，为什么还是慢？我看了他的方案文档，发现问题根本不在技术。他的采集频率是 6 小时一次，告警阈值只有一个，"降价超过 5% 就通知"。旺季期间，这个阈值一天被触发上百次，运营早就把通知静音了。
这就是我想聊"竞品监控场景的旺季准备"的起点。旺季竞品监控的失败，90% 不是因为采不到数据，而是因为方案在旺季开始前就没有为"旺季"这三个字重新设计过。下面我按结论、背景、误区、判断逻辑、案例、建议、取舍的顺序，把我这几年踩过的坑和验证过的做法写清楚。
如果只让我说一句话：旺季竞品监控的准备，不是把采集频率从一天一次改成十分钟一次，而是在有限的采集预算里，重新决定"哪些 ASIN 值得高频、哪些字段值得盯、哪些变化值得叫醒人"。
这句话听起来像常识，但我过去几年帮六个亚马逊团队做过旺季监控方案，真正做到的不到两个。剩下的四个都在 11 月第三周遇到同一个问题：数据是有的，但没人看、来不及看、看了也不敢信。
所以我把核心结论浓缩成五条，后面的所有章节，都是围绕这五条的论证和落地细节。
把 500 个 ASIN 的平均采集频率全部提高 6 倍，成本涨 6 倍，但真正需要高频监控的可能只有 40 个。剩下 460 个的噪音会稀释掉这 40 个的信号。分层不是降级，而是把预算集中在真正影响你出单的那几个位置。
我的经验值是：S 级 ASIN 不超过监控池的 10%，但应该吃掉 50% 以上的采集预算。
旺季的准备必须倒排。T-45 天（也就是 10 月中旬）之前把指标口径定死，T-30 天做全链路压测，T-14 天之后停止一切方案变更。
为什么是 T-14 冻结？因为旺季前两周平台风控最紧、竞品动作最密，这时候改脚本、改阈值、改字段，等于在高速上换轮胎。我见过一个团队在 11 月 18 号上线了新的解析规则，结果 11 月 20 号开始连续三天数据断档，等修好已经是黑五当天。
告警不是越多越安全，而是越准越安全。一个运营在旺季能承受的告警数量，我观察下来是每天 8 到 15 条，超过 20 条就开始出现"看一眼不处理"的行为，超过 50 条就一定会关通知。
所以告警必须分级：P0 直接推送到值班群并电话兜底，P1 每小时聚合推送一次，P2 只落库、进日报、不打扰任何人。
自建采集在旺季的出故障概率，明显高于平日。IP 被封、页面改版、Cookie 失效、服务器被限流，任何一个都足以让数据断档。这时候如果没有第二数据源兜底，监控就是一片空白。
降级链路的意思是：当主采集不可用时，你还能用第三方平台的数据把"有没有大变化"这个判断维持住，而不是完全瞎掉。
旺季结束后复盘，不要看"采集了多少万条数据"，要看"有多少次运营或投放的决策，是直接引用监控数据做出来的"。我自己的经验基线是：一个健康的旺季监控系统，每天应该产生 3 到 8 次被真实引用的决策，主要集中调价、广告预算迁移、库存清理三件事上。
如果一整个旺季下来，只有两次有人真的用了数据，那这套系统在旺季的价值就是零，不管它采集了多少条记录。
要理解为什么平日能跑通的方案在旺季会失效，得先看清楚旺季到底改变了什么。我把它拆成四个同时发生的变化，这四个变化的叠加效应，才是问题的真正来源。
平日的亚马逊类目里，头部竞品的价格调整频率大概是每周 2 到 4 次，BSR 波动平缓，库存状态相对稳定。到了 11 月中下旬，同一批竞品的改价频率会跳到每天 3 到 8 次，部分激进卖家在网一当天会改价 10 次以上。
这意味着：如果你的采集频率是 6 小时一次，在平日足够用；在旺季，你看到的永远是过期 3 到 6 小时的价格。对于跟价型卖家，3 小时的价格滞后足以让整个广告和定价策略失效。
这是很多团队完全没预料到的一点。电商平台在旺季前的流量高峰前，会主动收紧对异常访问的识别。同一个 IP、同一个 UA、同一套访问节奏，在平日可能没事，在 11 月中旬就会开始返回验证码或限流页面。
我在 2023 年就吃过这个亏：一套在 9 月、10 月跑得非常稳的采集脚本，11 月 12 号开始成功率从 97% 掉到 40%，排查了两天才意识到是风控策略变了，不是我的代码坏了。
平日发现竞品降价，你可以用两天时间讨论要不要跟、跟多少、跟多久。旺季不行，价格战的时间窗口可能只有几小时。决策窗口的压缩，反过来对数据时效性提出了完全不同的要求。
这也是为什么我一直强调，旺季监控方案的设计起点不是"采集什么"，而是"决策需要多快拿到什么"。
旺季期间，同一个运营要同时处理广告预算调整、库存预警、客服咨询、活动报名。监控数据如果没有被压缩成"一眼能看懂的三行结论"，就会被无限期推迟处理。
我后来给团队定了一条规则：所有旺季告警消息，第一行必须是结论，第二行必须是建议动作，第三行才是数据细节。这个改动看起来很小，但它把告警的响应率从 40% 提到了 78%。
下面这六个误区，我几乎在每一个初次做旺季监控的团队身上都见过。它们的共同点是：平日看不出来，旺季集中爆发。
最常见的思路是"旺季了，把频率调高"。但频率只是三个变量之一，另外两个是"ASIN 覆盖范围"和"字段深度"。三者共享同一份预算：服务器、代理 IP、解析算力、数据库写入。
把频率提高 6 倍，意味着同样的预算下，你能覆盖的 ASIN 数量要减少到六分之一，或者放弃评论、库存、广告位这些更深字段。不做这个取舍，结果就是频率上去了、覆盖面崩了。
我见过一个团队的监控池从 8 月的 120 个涨到 11 月的 900 个，理由是"多监控几个总没坏处"。实际上监控池越大，噪音越大，告警越不准，运营越不信任。
健康的做法是每个季度清理一次监控池，旺季前再做一次强制清理。清理标准可以是：连续 30 天没有价格变动、BSR 排名在你的类目 200 名之外、或者已经被下架。
价格是最容易被监控的字段，但它往往不是最早的信号。在价格变动之前，通常先出现的是：BSR 排名异动、库存状态从 In Stock 变成 Only X left、主图或标题改动、评论增速突然加快、广告位从首页掉到第二页。
只盯价格的团队，通常比综合监控的团队晚 12 到 36 小时做出反应。这个时间差在旺季就是订单差。
平日降价 5% 是大事，旺季降价 5% 可能是日常操作。如果阈值不变，旺季的告警量会暴涨到无法处理。
我的做法是准备两套阈值文件：平日的和旺季的，在 T-14 天切换。旺季阈值通常要收紧到：S 级 ASIN 降价 3% 才告警，C 级 ASIN 降价 15% 才告警。
没有基线的告警，本质上是把判断成本转嫁给了一线运营。系统说"这个数据变了"，运营还得自己去查"这个变化算大还是小"。
好的告警应该自带基线对比：不是"价格变了"，而是"价格比过去 30 天均价低了 18%，超过历史波动区间"。这个基线必须在旺季开始前就建好，旺季期间现建是来不及的。
旺季数据量通常是平日的 3 到 5 倍。如果平日没做存储规划，旺季很容易遇到写入变慢、查询超时、历史数据被覆盖的问题。
我建议在 T-30 之前做一次存储容量核算，并把旺季数据的保留策略写进方案。至少保留到次年 1 月中旬，因为旺季复盘一定会用到。
前面讲了结论和误区，这一章讲方法。我给自己和客户定旺季监控方案时，固定走六步，顺序不能颠倒。
很多方案是从"我们能采什么"开始的，这是反的。正确的顺序是：先列出旺季期间你真正要做的决策，再倒推需要哪些字段。
比如"要不要跟进竞品降价"这个决策，需要的字段至少包括：竞品当前售价、优惠券后到手价、过去 30 天价格中位数、当前 BSR、库存状态。缺了优惠券后到手价，你看到的降价幅度可能是假的。
我用 S/A/B/C 四层。S 级是同款直接竞品，A 级是同价格带竞品，B 级是同类目其它玩家，C 级是观察名单。分级标准必须在 T-45 之前确认，并且由运营和投放共同签字。
四层的采集频率、字段深度、告警等级完全不同。这张表是我常用的配置模板。
| 层级 | 数量占比 | 采集频率 | 核心字段 | 告警等级 |
|---|---|---|---|---|
| S 级 | 约 8% | 10-15 分钟 | 到手价、优惠券、库存、BSR、广告位 | P0 实时推送 |
| A 级 | 约 17% | 1 小时 | 到手价、库存、BSR | P1 小时聚合 |
| B 级 | 约 35% | 6 小时 | 价格、BSR | P2 日报 |
| C 级 | 约 40% | 24 小时 | 价格 | 不告警，仅落库 |
这套配比不是拍脑袋来的，它对应的是采集成本分布。大约 55% 的采集预算集中在 S 级和 A 级这两层上，而这些 ASIN 只占监控池的四分之一。这就是"分层优于提频"的具体含义。
采集频率不是越高越好，它受两个硬约束：预算约束和风控约束。预算决定你一天能发多少次请求，风控决定你在单位时间内的请求上限。
我的做法是先算"每万次请求的综合成本"（包括代理 IP、解析、存储），再乘以你愿意投入的预算，得到每天的请求总量，最后按分层权重分配下去。
举个例子：如果每天可用请求总量是 200 万次，S 级 40 个 ASIN 每天每 ASIN 144 次（10 分钟一次），一年就是 21 万次；A 级 85 个 ASIN 每天 24 次，是 74 万次；剩下 105 万次留给 B、C 级。这样分配下来，你既能保证 S 级的时效，又不会让整体预算失控。
告警设计里有三个参数必须显式配置：分级、聚合窗口、静默期。
分级决定推送渠道，聚合窗口决定同一类告警多久合并一次，静默期决定同一 ASIN 的同类告警多久内不重复推送。我最常用的组合是：P0 无聚合、5 分钟静默；P1 30 分钟聚合、60 分钟静默；P2 24 小时聚合、不推送。
这里有个反直觉的经验：静默期不是"漏报"，而是"去重"。同一个竞品在一小时内连续降价三次，你只需要知道最终价格，不需要被通知三次。
降级链路要提前设计好，并且在 T-30 的压测里真实演练一次。我通常设计三级：
每一级都要有明确的触发条件和退出条件，写进值班手册，而不是留在某个人的脑子里。
最后一步是定义"这套系统算不算成功"。我用的验收指标有四个：数据覆盖率、告警准确率、告警响应时长、被决策引用次数。
其中最重要的是第四个。前三个是过程指标，第四个是结果指标。如果只考核前三个，团队会倾向于把系统做得越来越复杂，但实际价值并不增加。
这一章我用一个具体案例来讲。客户是做家居收纳类目的中型卖家，主力站点美国站，监控池 300 个 ASIN，团队 6 人，其中 1 人兼职负责数据。下面是我在 2024 年 10 月到 11 月帮他们做的完整过程。
他们 2024 年 8 月就搭了自建监控，平日跑得还不错。但 10 月中旬开始出现两个问题：一是采集成功率从 96% 掉到 71%，二是运营开始抱怨告警太多、不敢信。
更麻烦的是，他们的 ASIN 池是拍脑袋定的，很多是在搜索页随手加的竞品，没有系统的发现机制。也就是说，他们监控的 300 个 ASIN，可能根本不包含真正的威胁。
第一步不是修采集，而是修 ASIN 池。我让他们先用 数跨境 的类目榜单和新品榜，把收纳类目近 90 天上升最快的产品拉出来，再和关键词榜交叉比对。
这一步的效果超出预期。他们原来的 300 个 ASIN 里，有 68 个已经连续 60 天没有明显动作，属于"僵尸监控"；而从榜单里新发现的 41 个 ASIN 中，有 7 个后来在旺季里确实发起了明显攻势。
这件事让我更加确信一个判断：竞品监控方案的第一优先级不是采集技术，而是监控对象的选择。监控错了对象，采集再快也没用。
第二步是建基线。他们的告警之所以不准，是因为没有任何历史参照。系统只知道"价格变了"，不知道"这个变化算不算大"。
我们用数跨境的历史数据，把每个 S 级和 A 级 ASIN 过去 90 天的价格、BSR 拉出来，算出中位数和波动区间。然后用这个区间定义异常：价格偏离 30 日中位数超过 12%，或者 BSR 单日变动超过历史 90 分位。
改完之后，他们的日告警量从旺季前的平均 130 条降到 22 条，但被人工确认为真实异常的条数反而从 9 条升到 16 条。告警量下降了 83%，有效告警提升了 78%，这就是基线的价值。
第三步比较有意思。我在做方案时一直有个习惯：不相信单一数据源。所以当他们的自采数据在 11 月中旬开始出现异常波动时，我们做的第一件事不是修脚本，而是拿数跨境的数据做交叉校验。
结果发现，自采数据里有将近 20% 的价格记录是错的。原因是旺季页面加载变慢，脚本在页面还没渲染完成时就抓取了价格节点，抓到了默认占位价格。这个错误在平日不会发生，因为平日页面加载快。
如果没有第二个数据源做校验，这个错误会一直存在，而且看起来数据是"有"的，只是全是错的。这是最危险的一类故障。
他们最初只抓页面标价，不抓优惠券和促销。结果竞品用"标价不变 + 15% 优惠券"的方式降价，他们的系统完全没反应。后来增加了到手价字段，才补上这个盲区。
旺季期间，他们用第三方平台的数据做兜底时，最初是人工手动导出 Excel。前三天还能坚持，到第四天因为导出量变大和人为失误，出现了两次数据版本混乱。兜底链路也必须是自动化的，手动兜底等于没有兜底。
自采数据用 UTC，平台数据用站点本地时间，两边对比时出现了 8 小时错位，一度让人误以为发现了重大价格异动。后来统一在入库时转成站点本地时间并标注时区，问题才消失。这个坑很小，但排查花了大半天。
整个旺季下来，他们的监控系统数据是这样的：S 级 ASIN 的告警平均响应时长从旺季前的 4.2 小时降到 0.6 小时；被决策引用的告警次数达到平均每天 5.3 次；人工救火耗时从每周 19 小时降到每周 5 小时。
更重要的是，他们在黑五当天成功跟进了两次关键调价，事后复盘估计挽回了约 8% 的当日订单。
方案没有标准答案，只有适配答案。下面按团队规模和业务类型，给出五套可以直接抄的配置。注意这些是起点配置，不是终点配置，你需要根据自己的类目竞争强度微调。
人少的团队最大的风险是贪多。我的建议是旺季只监控 20 到 40 个 S 级 ASIN，只抓到手价、库存、BSR 三个字段。频率可以到 15 分钟一次，因为量小，成本可承受。
告警只保留 P0 一级，直接推送到手机。不要做花哨的报表，把精力放在"告警来了能不能马上处理"上。
小团队的核心目标是闭环，不是覆盖。一个能稳定跑通 30 个 ASIN 的小系统，价值远高于一个半死不活覆盖 500 个 ASIN 的大系统。
这个规模的团队可以支撑 S/A/B 三层，监控池控制在 150 到 300 个 ASIN。关键是配置 AB 角：监控系统由一人主责，另一人备份，两人都要在 T-30 之前完成一次完整的故障演练。
告警分 P0 和 P1 两级，P0 进值班群，P1 进日报。同时在 T-14 之前确认好旺季的值班表，把值班表和告警分级对应起来。
多站点团队最容易出的问题是口径不统一。美国站说"降价 10% 才告警"，欧洲站说"降价 5% 就告警"，最后数据没法合并分析。
我的建议是在 T-45 之前出一份跨站点的指标口径文档，把所有字段的定义、计算方式、时间窗口写清楚。采集可以分区部署，但指标口径必须统一。
另外，多站点团队一定要用第三方平台的统一数据源做趋势校准，否则各站点的自采数据会慢慢漂移，最后无法横向比较。
铺货型卖家的 SKU 数量大，不可能逐个监控竞品。务实的做法是只监控每个类目前 20% 的头部产品，用来判断类目整体走向，而不是盯某个具体对手。
这类团队特别适合用第三方平台的类目榜单做趋势监控，因为榜单本身就是头部产品的聚合视图。省下来的精力放在选品和供应链上更划算。
代运营团队要同时服务多个客户，最大的风险是数据串号和权限混乱。方案设计时必须从第一天就做租户隔离：独立的采集队列、独立的存储空间、独立的告警通道。
我的经验是，代运营团队在旺季前一定要和客户确认两件事：告警推送给谁、异常处理由谁负责。这两件事没确认清楚，旺季一定会出扯皮。
旺季方案设计里，最难的不是"怎么做"，而是"放弃什么"。下面五个取舍，每一个都需要你明确表态，含糊过去的结果通常是在旺季中途被迫临时决策。
实时性是有价格的，而且是指数级的价格。从 6 小时一次提到 1 小时一次，成本大约涨 4 到 5 倍；从 1 小时提到 10 分钟，成本再涨 5 倍以上。
我的建议是：只给 S 级 ASIN 买实时性，其它层用小时级或天级。如果你的业务模式不是跟价型，甚至连 S 级都不需要 10 分钟级别，1 小时足够。
同样的预算，你可以监控 500 个 ASIN 的价格，或者 80 个 ASIN 的价格加库存加广告位加评论增速。这两条路没有绝对对错，取决于你的策略。
跟价型和广告卡位型的卖家，应该选深度；铺货型和选品驱动型的卖家，应该选广度。我在实际项目里更常见的是"广度优先、深度补刀"的组合：大面积低频覆盖，加少数高频深采。
自建的优势是字段自由、口径可控、数据不外流；劣势是旺季稳定性没保障、维护成本高。采购的优势是稳定、开箱即用；劣势是字段固定、深度有限、无法完全定制。
我的判断逻辑是：如果监控能力不是你的核心竞争力，优先采购；如果是，自建但要配降级链路。大部分亚马逊卖家属于前者，把精力放在运营上收益更高。
全自动的告警准确率在旺季通常会掉到 70% 到 85%，剩下 15% 到 30% 需要人工判断。但如果每条告警都要人工确认，等于没有自动化。
务实的做法是：P0 告警自动推送 + 人工快速确认（2 分钟内），P1 告警自动聚合 + 人工批量复核（每小时一次），P2 告警只落库不处理。分层的本质就是分配人工注意力。
这是我踩过最多次的坑。为了抓到更精确的数据，你会想加更多字段、更复杂的解析、更精细的模拟行为，但每一个增加都会降低系统稳定性。
在旺季，我的原则非常明确：宁可少采，不可采错。一个稳定输出 3 个准确字段的系统，比一个时好时坏输出 8 个字段的系统有用得多。错误的数据比没有数据更危险，因为它会误导决策。
最后给你一张可以直接用的倒排表。以 11 月第四个星期五（黑五）为 T 日往前推，把每个时间点该做的事写清楚。这张表我在多个团队用过，你可以在上面做增减。
| 时间节点 | 关键动作 | 产出物 | 负责人 |
|---|---|---|---|
| T-45 | 确认监控决策清单、冻结指标口径、完成 ASIN 分层 | 口径文档 + ASIN 分层表 | 运营负责人 |
| T-40 | 清理监控池，剔除 60 天无动作 ASIN，补充新发现竞品 | 最终监控池名单 | 数据负责人 |
| T-35 | 建立历史基线，计算每个关键 ASIN 的价格与 BSR 波动区间 | 基线参数表 | 数据负责人 |
| T-30 | 全链路压测，验证降级链路，确认存储容量 | 压测报告 + 降级演练记录 | 技术负责人 |
| T-21 | 切换旺季告警阈值，配置聚合与静默策略 | 旺季告警配置 | 技术负责人 |
| T-14 | 方案冻结，确认旺季值班表，完成值班人员培训 | 值班表 + 操作手册 | 运营负责人 |
| T-7 | 每日巡检 S 级 ASIN 数据质量，确认采集成功率在 90% 以上 | 每日质量日志 | 数据负责人 |
| T-1 | 进入战时状态，P0 告警实时响应，暂停一切方案变更 | 实时监控值班 | 全员 |
| T+3 | 第一次复盘，评估告警准确率和响应时长 | 初步复盘纪要 | 运营负责人 |
| T+14 | 完整复盘，评估被决策引用次数，规划明年改进项 | 旺季复盘报告 | 运营负责人 |
这张表里我想强调两点。第一，T-14 之后的冻结期不能破例，我在前面已经说过原因。第二，T+3 的初步复盘不要省，因为这个时候记忆最清晰，很多细节到 T+14 就记不清了。
回到开头那个凌晨两点发消息的卖家。他后来复盘时说了一句话我印象很深：他不是没有监控系统，他是没有为旺季重新设计过监控系统。平日能用的方案不等于旺季能用的方案，这中间的差距，就是准备周期里那 45 天要做的事。
如果你现在距离旺季还有一个月以上，建议从今天开始做三件事：把监控池按 S/A/B/C 重新分一次层，把告警阈值改成旺季版本，然后找一个第三方数据源做好交叉校验的准备。这三件事做完，你就已经超过了大部分团队。
如果你距离旺季不到两周，那就只做一件事：把 S 级 ASIN 挑出来，确保这几十个的数据在旺季期间不会断。剩下的，等明年再优化。
去年黑五我是提前两周才开始搭监控的，结果采集链路还没压测完价格就开跌了，整个人是懵的。今年我想认认真真排一次期，但又不确定到底该提前多久、每个节点该交付什么，怕排得太松浪费人力，排得太紧又赶不上。
我的经验是 T-60 到 T-45 之间必须启动，提前一周肯定来不及。
原因是亚马逊旺季（7 月中的 Prime Day、11 月下旬的黑五网一）前 4 到 6 周，竞品就已经开始调价、换主图、加 Coupon 了，如果你在大促前 3 天才开始采集，拿到的只是一个没有基线的孤立数据点，你根本没法判断“这个价是历史低位还是人家平时的常规价”。
具体倒排我会这么排：T-60 定监控清单和指标口径，明确哪些 ASIN 算核心、价格到底取 Buy Box 价还是 List Price、Coupon 算不算进到手价；T-45 完成采集链路压测，按预估峰值的 3 倍 QPS 打，这一步千万别省；T-30 灰度上线，同时开始攒历史数据做基线；
T-14 全量切流，用攒下来的真实基线去校准告警阈值；T-7 需求封版，只允许改配置项（阈值、频率、监控名单），不允许再动代码，封版窗口我一般会在某项目管理工具里单独拉一个看板，谁想加需求都得走审批；大促当天只做运维和值守。
我自己踩过最狠的一个坑是 T-14 才临时加了一批新 ASIN，新 ASIN 没有历史基线，阈值只能拍脑袋设，结果大促当天误报刷屏，值班的同学第二天就干脆不看告警群了，这比没有监控还危险。
我们团队之前是什么都想抓，价格、评论、主图、广告位全上，结果发现一半的数据根本没人看，代理成本倒是翻了一倍。我现在想重新梳理一遍：到底哪些字段是真正会触发运营动作的，频率又该按什么标准来定？
字段我会砍到七类，按优先级排：价格（Buy Box 价、List Price、Coupon/Deal 类型与额度）、库存状态（是否有货、是否转 FBM、有没有被跟卖）、BSR 和类目排名、评分与评论数增量、主图与 A+ 是否变更、搜索结果页的广告占位、变体增减。
这里面只有前两类是真正会直接触发你调价和补货动作的，其他都是辅助判断。频率上不要一刀切：核心竞品（大概占你对标 GMV 60% 以上的那批）15 到 30 分钟采一次；腰部竞品 2 到 6 小时一次；长尾每天一次就够。
判断依据很简单，价格战基本是在 30 分钟内完成跟调的，你 2 小时采一次会漏掉一半以上的降价动作；但评论数一天只变一次，你按 24 次/天去采纯属浪费。
规模上算一笔账你就清楚了：日采集量等于 ASIN 数乘频次，5000 个 ASIN 按 24 次/天算就是 12 万次/天，单机配 10 个左右的代理出口完全跑得动，超过 50 万次/天才需要上分布式和队列削峰。
存储更好算，每条快照 1 到 2KB，12 万次/天乘 30 天也就 6 到 7 个 GB，做冷热分层绰绰有余。真正烧钱的从来不是存储，是无效的高频采集。
去年 Prime Day 当天上午我们的采集成功率从 90% 掉到 30%，代理池里的 IP 一批一批地挂，补都补不赢，只能眼睁睁看着竞品价格在变。我到现在也没想清楚，到底是代理不够多，还是请求节奏太机器化被识别了？
核心是三件事：出口 IP 分层、请求节奏人形化、失败后分级降级而不是硬刚。IP 这块我的实测经验是，住宅或移动代理的成功率能到 85% 到 95%，机房 IP 只有 40% 到 60%，而且大促期间亚马逊风控收紧时机房 IP 掉得最快。
所以正确做法是按 ASIN 重要性分配：核心 ASIN 走住宅池，长尾走机房池，别一股脑全用最贵的。节奏上，单个出口 IP 每分钟不要超过 6 到 10 次请求，请求间隔加 3 到 15 秒的随机抖动，同一个 IP 不要连续打同一类目的 ASIN，这三条能干掉一大半的封禁。
降级要做三级：一级换 IP 重试，最多 2 次，不要无限重试；二级降频到原来的四分之一，并把该 ASIN 标记为“降级采集”；三级直接熔断，只保留价格和库存两个字段，主图、评论、广告位这类重字段先停掉。
判断依据就一句话，旺季宁可少采几个字段，也不能断了价格和库存，因为只有这两个会直接触发你的调价和补货动作。另外强烈建议在 T-45 那次压测里专门打一次 3 倍峰值，很多团队都是等到黑五当天才发现代理池根本不够用，那时候补货已经来不及了。
去年黑五我们的告警群从早到晚没停过，一会儿价格动了 1%，一会儿排名跳了两名，真正重要的那个竞品断货消息反而被淹在里面，等我们反应过来已经过了三个小时。我今年想彻底改一下告警机制，但不知道阈值和分级的依据该从哪来。
我的做法是三级告警加合并降噪加值班 SOP 三件套。P0 是最紧急的：核心竞品价格跌破你预设的底线、Buy Box 丢失、竞品断货，走短信加电话，要求 2 分钟内必达；P1 走企业微信或钉钉群，包括 BSR 排名变动超过 20%、评论数单日增量异常、主图变更；P2 是日常波动，只进日报不打扰人。
降噪规则要写得非常具体：同一个 ASIN 的同类告警 30 分钟内合并成一条；价格波动小于 3% 不报，大促期间可以放宽到 5%；排名波动必须连续 2 个采样点都确认才报，避免单点抖动刷屏。
阈值千万别拍脑袋，用 T-30 到 T-7 攒的那两周真实数据取 P95 分位作为初始阈值，再乘一个大促系数往上调。数据延迟这块，给每条采集任务打上时间戳和“数据新鲜度”标签，前台展示时明确标出“最后更新于 X 分钟前”，超过 SLA 的直接标黄，运营一眼就知道这条数据不能拿来直接决策。
我觉得最实用的一个机制是“兜底巡检”：大促当天每小时跑一次健康检查，统计各字段的采集成功率，一旦低于 90% 就直接电话叫醒值班同学，而不是傻等告警自己触发，告警系统本身出问题的时候，是不会有告警来告警你的。
读者评论
分层优先于提频这点我认同，但S级不超过10%这个经验值要打个问号。我们做家居类目，旺季真正要盯的ASIN能占到三成，因为头部几个链接贡献了七成出单，砍到10%根本覆盖不住。感觉这个比例跟类目集中度关系很大，不能直接照搬。
T-14冻结说得太绝对了。我们去年11月15号临时加了两个竞品的库存字段，就因为平台页面结构变了，不改反而采不到数据。冻结的前提是前期口径真的定得够细，如果T-45那次就是糊弄过去的，后面硬冻只会把问题拖到黑五爆出来。
降级链路那段很实在。我们自采脚本去年网一前一周成功率从95%掉到50%多，当时完全靠人工刷页面，两个人盯了三天。后来才接了第三方数据兜底，但那个供应商在旺季也涨价还限流，所谓兜底其实也不太靠得住，这点文章写得有点乐观了。