我曾经计划让 RongAds 24 小时运行（2026 年 10 月起它改成了每周用一次、由人上传的 Bulk 工具，见文末）。“24 小时运行”这句话很容易被误解成“每个关键词每天自动调一次 bid”，其实两者完全不是一回事。
程序可以每天拉报表、检查预算、核对资格并生成 dry-run；如果没有新增信息、归因还没成熟、对象仍在冷却，正确结果往往就是 no-op：什么也不改。对会直接影响广告费的系统来说，稳定地不动作也是成功运行。
Amazon 没有给所有账户规定一个通用的调价日历。平台真正定义的是数据如何出现、转化按什么窗口归因，以及报表日期怎样回填。调价频率必须在这些事实之上，由自己的风险和证据策略决定。
专题导航：本文属于 Amazon 广告优化与 RongAds 实战 系列；可从专题页按“基础 → 数据 → 决策 → 工具”查看完整阅读路径。
先给结论：每天观察，不等于每天改价
| 工作 | 建议节奏 | 是否修改 bid |
|---|---|---|
| 服务健康、预算与资格巡检 | 持续或每天 | 否 |
| 下载并规范化广告报表 | 每天 | 否 |
| 生成候选建议与 dry-run | 每天也可以 | 否 |
| 常规加价或降价复核 | 以成熟数据为基础，通常按周 | 可能 |
| 紧急止血 | 每天检查，但只在明确风险条件触发 | 只允许受限降价或暂停 |
| 方向反转 | 比同向续调要求更强的证据 | 可能，但不能靠模型一天一变 |
“通常按周”不是 Amazon 的官方规定，也不是所有账户的万能答案。它是我根据德国站当前低点击密度、7 天卖家归因窗口和历史日频失稳案例采用的保守基线。高流量对象可以更快积累信息，但仍要通过相同的成熟、冷却和回执闸门。
四只时钟必须分开保存
1. 数据刷新时钟：今天拿到了什么
刷新时钟只回答报表是否成功生成、摄入和规范化。Amazon Ads 官方说明，转化可能需要一段时间才显示；Unified Reporting 还把转化指标统一记录到 traffic date，也就是广告互动发生的日期。
所以今天重新下载昨天的数据，订单数可能比昨天看到的更多。这是数据回填，不是广告效果被程序“改写”了。一次成功刷新只能证明拿到了一个新快照，不能自动获得调价资格。
2. 归因成熟时钟：哪些 traffic date 可以下结论
Sponsored Products 的基础转化指标通常使用：
- Seller：点击后 7 天；
- Vendor 与 Author：点击后 14 天。
Amazon 明确提示，在适用的 lookback window 结束前，某个报告日期的归因指标仍不完整。因此 Seller 在 7 月 8 日看到 7 月 7 日“0 单”，不能把它当作成熟的零转化；Vendor 的等待时间还会更长。
调价工具必须知道 attribution_window 和 maturity_cutoff，而不是从字段名猜。2026 Unified Reporting 已经不再把 7 Day、14 Day 写进很多基础指标名称，但底层适用窗口仍然存在。
3. 对象冷却时钟：上一次真实动作过去多久
冷却期解决的是机械重复和方向震荡，不是归因成熟。比如“加价后至少 5 天不再写回”可以拦住复利式日调，但 5 天并不会让 Seller 的 7 天归因自动变完整。
下一次动作的最早时间应该取多个闸门的最大值：
next_eligible_at = max(
applied_at + object_cooldown,
maturity_cutoff,
reversal_cooldown_until,
policy_review_at
)
这里最关键的是 applied_at。冷却只能从 Amazon 已明确生效且经过核验的时间开始，不能从 suggested_at、计划生成时间或请求发出时间开始。
4. 执行审计时钟：建议到底有没有生效
一个 bid 从计算到生效至少经历：
observed → eligible → planned → approved
→ requested → applied → cooling → evaluable
如果请求超时、只有部分回执，状态必须进入 unknown_outcome 或 quarantined。先从 Amazon 端重新读取实际 bid 对账，再决定是否重试。直接把同一请求再发一次，可能造成重复动作；把“请求已发送”当“已生效”，则会让冷却和审计都从错误时间开始。
为什么 5 天冷却和 D-7 不矛盾
假设 7 月 1 日给一个 Seller 关键词加价，并在当天核验生效：
| 日期 | 状态 | 能否据此再次调价 |
|---|---|---|
| 7 月 1 日 | 新 bid 已生效，进入 5 天机械冷却 | 否 |
| 7 月 6 日 | 机械冷却结束 | 仍不能仅凭 7 月 1 日结果判断 |
| 7 月 8 日以后 | 7 月 1 日点击的 7 天归因窗结束 | 才进入可评估候选 |
| 下一复核点 | 同时检查新增点击、经济性、预算和异常 | 通过后才可能动作 |
换句话说，冷却是“不要重复写”，成熟是“不要过早下结论”。两只钟都通过，才获得评估资格；获得资格也不等于必须改价。
正常调价与紧急止血必须分轨
我不再使用“加价周频、降价日频”这种过于简化的写法。日频降价若只因为昨天 0 单，同样会追逐未成熟噪声。
正常路径要求成熟事实、可比配置和足够新增信息；紧急路径只处理明确风险，例如组合花费异常、产品失去资格、预算或利润护栏被击穿。紧急动作应满足：
- 只允许暂停或有上限的降价，不允许借“紧急”加价；
- 记录
decision_basis=emergency_risk，不混入正常学习样本； - 动作后禁止立即反向加价，先进入隔离和重新观察；
- 不能用“昨天 0 单”单独触发止血；
- 无法确认风险范围时 fail closed，优先暂停而不是全账户乱改。
方向反转比同向调整更危险
历史复盘里最典型的问题不是单次幅度，而是昨天加、今天砍、后天又加。方向反转说明模型对状态没有稳定判断，或者价格、库存、竞争和归因窗口已经破坏可比性。
因此 up → down 或 down → up 不能只复用普通冷却。至少要额外检查：
- 距上次真实动作是否新增了足够点击或花费；
- 前一动作影响对应的归因是否成熟；
- 短窗恶化是否达到死区之外，而不是轻微波动；
- 期间是否发生售价、优惠、库存、Featured Offer、Listing、预算、Placement 或竞价策略变化；
- 是否存在组合级异常，需要先拉下加价熔断器。
任何结构变化都会开启新的 comparison_epoch_id。旧动作前后的数据不再直接可比，系统应暂停自动归因，而不是把产品端变化误算成 bid 效果。
no-op 为什么也必须写日志
每天运行后如果没有动作，系统仍应记录原因，例如：
immature_attribution：归因未成熟；insufficient_new_clicks：距上次动作没有足够新增信息；object_cooling：对象仍在冷却；inside_deadband：建议差异处于噪声区；unknown_execution_outcome：上一请求结果未知；comparison_invalidated：配置或商品状态破坏可比性；portfolio_breaker_open：组合加价熔断器已打开。
这样才能区分“系统正常判断不该动”和“调度器根本没跑”。24 小时自动化真正需要的不是每天生成很多修改，而是每天都能解释为何改、为何不改，以及改完是否真的生效。
一套自动执行系统需要保存的最小证据
每条动作至少应关联：
| 证据组 | 必要字段 |
|---|---|
| 数据来源 | report/import ID、窗口、traffic date、生成时间、账户类型 |
| 决策 | policy ID/version/hash、当前 bid、建议 bid、方向、gate 结果 |
| 成熟与冷却 | maturity cutoff、evidence state、applied at、cooldown until、reversal cooldown until |
| 执行 | request ID、幂等键、payload hash、逐对象回执、confirmed bid |
| 可比性 | comparison epoch、价格/库存/Listing/预算/Placement 快照 |
| 恢复 | rollback version、核验时间、异常状态与人工审批人 |
计划、请求、回执和远端核验不能合成一个布尔值。审计日志要 append-only；纠错通过追加新事件和 supersedes_event_id 完成，不能回头改掉旧记录。
RongAds 现在怎么处理这四只时钟
2026 年 10 月起，RongAds 不再是 24 小时运行的程序，而是一个每周用一次的网站：你上传最近 30 天的 Bulk 文件，它给出每个词的建议，你核对后下载上传。四只时钟因此变得很朴素：
- 刷新时钟：你导出文件的那一刻。网站从文件名读出窗口，短于 14 天会警告。
- 归因成熟时钟：要求窗口结束日距上传日至少 3 天，不满足就警告“最近几天的转化率偏低，降价建议会偏多”。不做 D-7 严格截断：按周运行时，30 天窗口里只有最后 3 天未成熟，影响被稀释。
- 对象冷却时钟：上期接受过加价的词 5 天内不再加。靠的是你下载的“本期记录”文件：下次拖回来，网站就知道上次加了哪些词、什么时候加的。没有 API 回执，“生效时间”只能近似为记录的导出时间，这是手工流程付出的精度代价。
- 执行审计时钟：没有了。上传由你完成，网站不知道也不记录你有没有传。取而代之的是“决策记分卡”：下一期把上期加价、降价、收割的词分组对账，看它们这期各自怎样了。
原来那套 applied_at、幂等键、回执对账的契约，随 API 自动化一起删除了，见《Amazon 广告自动调价：我给 RongAds 加了 7 道安全闸，然后把自动化删了》。
一份可直接使用的调价检查单
在任何 bid 写回前，逐项回答：
- 数据来自哪个不可变报表快照，窗口和账户类型是什么？
- 参与判断的 traffic date 是否已经过 7/14 天适用归因窗？
- 距上次确认生效动作新增了多少点击和花费？
- 对象冷却与方向反转冷却是否都结束？
- 售价、库存、Featured Offer、Listing、预算、Placement 和竞价策略是否可比？
- 目标 ACOS 与当前利润上限是否仍有效？
- 请求是否有幂等键、预期旧值和逐对象回执？
- 状态未知时是否先隔离并远端对账？
- 失败后能否回滚，并验证实际 bid 已恢复？
- 若最终 no-op，是否留下了可读原因？
计算建议 bid 的公式和小样本边界，可继续看：Amazon 关键词 bid 怎么算？用目标 ACOS、CVR 和客单价反推 CPC。为什么近期订单会回填、D-7/D-14 应怎样切成熟数据，则见：Amazon 广告订单为什么会回填？7 天归因窗口别再看昨天 ACOS。
参考资料
- Amazon Ads：Ad campaign attribution
- Amazon Ads：Understand unified reporting
- Amazon Ads：Create a report in unified reporting
调价最重要的频率，不是程序每天几点运行，而是证据何时成熟、动作何时真实生效、系统何时有资格再次改变同一个对象。把这四只时钟分开，不管是每天在线的程序还是每周一次的人，都不会冲动。
