你是否也遇到过
算和推没衔接好，改价反而出事
数据还没到，就开始调价
昨晚的报告还没下载完，规则已经按前天的数据把词降了价，第二天高峰没流量。
版位加价先生效，出价还没降
三样设置分三次推，中间有一段时间是新加价配旧出价，点击价一下子冲得很高。
推了一半就断了
推到一半被限流或电脑重启，一部分词是新价、一部分是旧价，也不知道哪些没推上去。
系统怎么做
算完再推、三项同轮、以回执为准
- SP 与 SB 同一轮计算。一次读取数据，同时算出 SP 与 SB 所有投放的下一轮出价，并经过利润上限、平台出价下限、丢展示地板等 多层护栏。
- 计算先记下范围。计算开始前记下这一轮要算哪些；进程中途被打断，巡检发现后按原范围重新提交，直到算完；之后已有成功的计算就不再重复。
- 下发等计算完成。下发开始读数据前先确认没有计算在进行，有就等它结束再推，而不是中止；计算与下发不会同时写同一批数据。
- 三项同轮、按安全顺序。基础出价、版位加价、时段规则在同一轮提交，顺序保证过渡过程中执行价不越界，见 三合一下发。
- 以回执为准、只补没到位的。三项都确认到位的系列才算完成；没到位的留待补推，已到位的不会重复提交。
- 让位不算成功。因为计算占用而没推成的一轮，会被记为“可重试”，由补做机制在窗口内跟进，而不是被当作“已完成”跳过。
- 日内分时按时刻判断。进入低谷与恢复高峰两个任务，按执行那一刻所处的时段决定写低谷值还是争抢价，所以补做也不会写错时段，见 日内分时。
对比
出价计算与下发：三种做法的差别
| 对比项 | 手工运营 | 通用工具 | PPCWISER 琼仁智度 |
|---|---|---|---|
| 计算前数据是否就绪 | –看运气 | –视工具而定 | ✓同步在前、计算在后，不读半成品 |
| SP 与 SB 是否同一口径 | ✕两个后台分开调 | –视工具而定 | ✓同一轮计算 |
| 出价、版位、时段是否同轮 | ✕三处分开改 | –多为分开设置 | ✓同一轮按安全顺序下发 |
| 计算没完成会不会下发 | – | –视工具而定 | ✓下发等计算完成再推 |
| 推到一半中断 | ✕不知道哪些没推上 | –视工具而定 | ✓以回执为准，只补推没到位的系列 |
| 日内低谷与高峰 | ✕需要守夜手改 | –视工具而定 | ✓两个任务自动切换，按时刻判断写什么 |
“视工具而定”表示我们无法替其他产品作答，请以各服务商的说明为准。
用了以后
每一次改价都是完整的一轮
不再推半成品
计算与下发前后衔接，推出去的都是完整算完、过了护栏的结果。
过渡期执行价可控
三项同轮、按安全顺序落地，不出现新加价配旧出价的高价窗口。
中断之后不留烂摊子
计算按原范围续算，下发只补没到位的系列，不会重复提交已经成功的部分。
夜里也在按计划调整
转化低谷自动让价、时段结束自动恢复，你不用守到半夜。
与广告结构的关系
下发以系列为单位，结构越清楚，每一轮越安全
版位加价和时段规则都是系列级设置，所以计算与下发都按 广告结构 以系列为单位组织：精准单词系列、分层系列、探索系列各自的出价逻辑不同，结构统一之后，每个系列这一轮该推什么、推到没有，才分得清。接入时可以选方案 A 重构正在跑的系列，或方案 B 保留原系列、另建一套标准结构。
关于计算与下发任务的常见问题
为什么出价每天只算一轮？
每天的计算结果主要作用于接下来一天的流量；一天之内的时段差异由时段规则和日内分时切换承担。这样既能用上完整的一天数据，又能避免一天内反复改价造成来回波动。
计算做到一半服务重启了怎么办？
计算开始前系统已记下这一轮的范围，巡检发现计算被打断后，会按原范围重新提交直到算完；重试有次数限制，之后已有成功计算的不再重复。
下发时正好在重新计算，会冲突吗？
不会。下发开始前会检查是否有计算在进行，有就等它完成再推，推出去的是最新算完的结果；两者不会同时写同一批数据。
有的系列没推上去怎么办？
系统以亚马逊逐条回执为准，三项都确认到位才算完成；没到位的系列留待补推，已到位的不会重复提交。失败原因在下发记录里可以看到。
我能不用自动下发、自己手动推吗？
可以。在定时任务中心停用下发任务后，仍可在手动更新出价等页面单独推送出价、版位或时段，见 人工随时介入。
继续了解
相关功能
护栏与下发
三合一协同下发
出价、版位加价、时段规则作为整体同轮下发，先降后升，以逐条回执为准。
查看 →时段与版位日内分时
识别全店转化低谷，自动收紧搜索位加价与 SB 出价，时段结束自动恢复。
查看 →护栏与下发出价安全护栏
下发前按真实执行口径逐格核对：利润封顶、最低出价兜底、每轮小步、主力词优先恢复。
查看 →漏跑补执行漏跑补执行与续跑
按执行窗口判断有没有做成：窗口内补做有上限，中断按原范围续跑，离线回线补一次。
查看 →可靠下发限流下可靠下发
限流自动降速，三项成组安全下发，新建不重放，失败只补差。
查看 →透明与可控人工随时介入
单条、勾选或一键推送新出价，防重复、自动重试、失败原因排行；还可按产品重算或暂停。
查看 →REFERENCES
参考资料与权威来源
本页所有涉及亚马逊规则、行业数据与方法论的表述均标注来源。链接指向官方文档、同行评审论文、专利或法律法规原文；访问日期 2026-09。
- [1]官方Bid controls — Amazon Ads API Docs · 2026竞价策略与版位加价都是广告活动级设置，可单独或同时使用，由亚马逊实时合并计算出价；版位加价按原出价的百分比叠加（$1.00 加 50% 为 $1.50），取值 0–900%；固定出价不受动态调整影响。
- [2]官方Schedule bid rules — Amazon Ads API Docs · 2026时段规则先作为优化规则单独创建，再关联到广告活动；条件满足时提高出价，多条规则的加价会叠加；新建或修改后 24 小时内生效；单个活动最多 20 条；叠加在版位加价与竞价策略之上。
- [3]官方REL04-BP04 Make mutating operations idempotent — AWS Well-Architected Framework · Reliability Pillar · 2026分布式系统里“至多一次”或“至少一次”容易做到，“恰好一次”很难；修改类操作要做幂等设计并记录每个操作的状态，重试才不会产生重复记录或副作用。
- [4]官方Rate limiting — Amazon Ads API Docs · 2026请求过多时返回 429 并带 Retry-After 头，限流随系统负载动态调整，官方建议指数退避重试。
- [5]论文Distributed Periodic Scheduling with Cron（Site Reliability Engineering 第 24 章） — Google SRE Book · 2016定时任务有“漏跑”和“重复执行”两类失败；许多任务不是幂等的，重复执行可能无法撤销，因此需要可靠记录任务“即将启动”和“已经完成”两个时点，才能在故障后正确恢复。