昨天广告后台显示 20 次点击、€8 花费、0 单；今天重新查看昨天，突然变成 1 单，ACOS 也从“没有分母”变成 32%。如果把每天导出的报表当成不会变化的账本，这种现象很像系统出错。
其实，Amazon 广告报表记录的不是一条即时结算流水，而是一套持续更新的归因结果。点击先发生，购买可能几天后发生；订单随后被记回产生广告互动的那一天。取消订单、付款失败和无效点击校验还可能让旧数字再次下降。
理解这件事，关键不是背一个“等 48 小时”的经验，而是分清数据刷新、归因窗口和事后修正这三只时钟。
专题导航：本文属于 Amazon 广告优化与 RongAds 实战 系列；可从专题页按“基础 → 数据 → 决策 → 工具”查看完整阅读路径。
回填不是把订单记到购买日，而是改写点击日
Amazon 当前统一报表使用 traffic date（流量日期）口径：转化归到广告互动发生的日期，而不是实际购买日期。
例如，买家 7 月 1 日点击 Sponsored Products，7 月 3 日完成购买。广告报表最终会把这笔转化记在 7 月 1 日。于是：
7 月 1 日：点击与花费先出现，订单暂时为 0
7 月 3 日：买家购买，系统完成处理后把订单归回 7 月 1 日
之后重下 7 月 1 日报表：订单、销售额、CVR、ACOS、ROAS 都可能变化
这就是运营中常说的“订单回填”。它没有改变购买发生的日期，只是用历史广告互动解释这笔购买来自哪里。
三只时钟决定数字什么时候稳定
把所有延迟都叫“归因延迟”会误导判断。Amazon 官方资料实际上描述了三个不同过程：
| 时钟 | 官方当前口径 | 它会改变什么 |
|---|---|---|
| 数据处理 | 报表数据每天多次刷新，多数指标约每 3–6 小时刷新；订单指标可能最多约 12 小时才出现，Campaign Manager 的销售数据可能最多约 48 小时补齐 | 今天和昨天的近端数字逐步出现 |
| 归因回溯 | Sponsored Products 卖家 7 天、供应商与作者 14 天；窗口结束前，给定流量日期的归因指标仍不完整 | 几天后的购买继续回填到历史点击日 |
| 事后修正 | 点击/花费可能在流量质量验证期间继续调整；72 小时内取消或付款失败的购买会从归因指标扣除，取消后的扣减处理还可能持续数天 | 历史点击、花费、订单和销售额可能向下修正 |
所以，“等 12 小时”“等 48 小时”和“等完整 7 天”不是互相冲突的说法。前两个回答近端数据什么时候大致可见，最后一个回答一条 seller Sponsored Products 点击什么时候走完整个转化机会窗口。
卖家 7 天、供应商 14 天，别只看字段名
Sponsored Products 当前基础转化口径如下：
| 账户类型 | 点击归因窗口 | 可归因商品范围 | 广告互动 |
|---|---|---|---|
| Seller | 7 天 | 广告商品，以及该 Seller Central 商家销售的其他商品 | 点击，last click |
| Vendor / Author | 14 天 | 广告商品，以及符合品牌光环规则的同品牌相关商品 | 点击，last touch，优先考虑商品相关性与点击 |
新版统一报表逐步去掉了指标名里的“7 Day / 14 Day”字样，但这不表示窗口消失。Amazon 会根据广告产品和账户类型给基础 Purchases、Sales、ROAS 等指标自动套用正确窗口。
因此，同一套脚本不能因为列名都叫 Purchases，就默认所有账户都用 7 天。账户类型、广告产品和报表版本必须和原始文件一起保存。
一个 7 天时间线：昨天 ACOS 为什么会越来越低
假设 seller 账户的一次点击发生在 7 月 1 日，CPC 为 €0.80：
| 查看时间 | 系统新增事实 | 7 月 1 日历史行可能显示 |
|---|---|---|
| 7 月 1 日 | 点击发生 | Cost €0.80，Purchases 0，Sales 0 |
| 7 月 2 日 | 暂无购买 | 数字可能不变 |
| 7 月 3 日 | 买家购买 €20 商品 | 处理后变为 Purchases 1，Sales €20，ACOS 4% |
| 7 月 5 日 | 同一买家在合格范围内又购买 | 历史 Sales 或 Units 可能继续增加 |
| 7 月 8 日以后 | 该点击走完 7 天回溯窗口 | 归因机会基本封口，但仍可能出现取消订单或流量验证修正 |
这里的 €20 只是演示时间关系，不代表不同账户实际一定采用相同的税费、折扣或商品相关性口径。
为什么旧数据有时反而会下降
回填并不只会增加订单。Amazon 官方列出的常见下修原因包括：
- 订单取消或付款失败：创建后 72 小时内发生的取消或付款失败会从归因指标扣除，扣减处理可能在取消后最多约 7 天完成；
- 无效流量验证：点击和 Cost 在验证期间可能被修正，Amazon 的报告说明 Cost 可在点击或可见展示发生后最多 3 天继续更新；
- 归因竞争：一笔转化不会被重复归给多个广告互动，系统按商品相关性、点击/浏览优先级与 last-touch 规则确定唯一归属；
- 报表维度不同：按 advertised ASIN 看时，广告归因销售额可能包含买家最终购买的其他合格商品，不能把每个维度的行机械地和零售订单表一一对应。
这也解释了为什么每天保存原始快照很重要：不是为了证明 Amazon“改过数据”，而是为了区分正常回填、取消修正、流量验证与自己的解析错误。
广告销售额为什么对不上后台零售销售额
广告归因报表与零售销售报表回答的是不同问题。
| 广告归因报表 | 零售/财务报表 |
|---|---|
| 按广告互动日回填结果 | 通常围绕订单、发货、结算或交易日期 |
| 判断哪些广告互动获得转化归因 | 判断实际卖了什么、何时结算、扣了什么费用 |
| 可能包含合格的其他商品销售 | 按实际订单商品记录 |
| 归因销售额不一定包含购物车折扣和税 | 财务口径还受 VAT、退款、平台费用与汇率影响 |
因此，广告优化可以用归因 Sales 算 ACOS 和 ROAS；月度利润桥接则应把同一自然月的实际广告花费、零售销售、退款、费用和汇率分别对齐。不要把“归因到 6 月点击的 7 月购买”直接当成 6 月财务销售。
成熟数据截止日：D-3 只是降噪，不是完整成熟
很多团队习惯把报表截止到 3 天前。这个做法能避开最严重的近端缺口，但它不是 Amazon 官方定义的完整归因窗口。
更准确的分层是：
seller Sponsored Products
监控区：D 到 D-2，主要看花费、异常流量、库存与预算
软动作区：D-3 到 D-6，只做可撤回的小幅降价或限预算
成熟区：D-7 及以前，可用于零订单硬判断和正式调价
vendor / author Sponsored Products
监控与软动作原则相同
成熟区改为 D-14 及以前
明显无关的搜索词不必等待转化窗口结束才能否定，因为语义本身已经给出证据；但“相关词 0 单”“ACOS 过高”“CVR 太低”这类依赖转化结果的结论，必须等适用窗口成熟。
自动调价应该同时维护观察窗和决策窗
如果一个调价程序每天运行，最危险的实现是每天下载“最近 30 天”，直接把最新订单数喂给同一条调价公式。这样会在订单尚未回填时连续降价，等订单出现后又反向加价，形成追逐噪声的振荡。
更稳妥的自动化数据模型应至少保留两套窗口：
| 窗口 | 用途 | 允许动作 |
|---|---|---|
| 观察窗，包含最近日期 | 发现花费突增、预算耗尽、Buy Box/库存异常、明显无关流量 | 告警、熔断、只降不加、限预算 |
| 成熟决策窗，截止 D-7/D-14 | 计算 CVR、ACOS、零订单证据、bid 建议和边际表现 | 生成正式建议，仍由人核对后执行 |
每条计划还应记录 data_start、data_end、maturity_cutoff、账户类型、生成时间、原始快照哈希和执行回执。缺少任何一项时 fail closed，不把“今天没看到订单”解释成“这个词已经无效”。
RongAds 现在的做法更简单：一周跑一次，要求导出的 30 天窗口结束日距上传日至少 3 天，不满足就在页面上警告；上期加过价的词 5 天内不再加。按周运行时，一个 30 天窗口里只有最后 3 天未成熟，影响被稀释，不值得为它维护两套窗口。
2026 年报表迁移还会带来字段名变化
Amazon 已宣布旧的 sponsored ads reports 与 Amazon DSP reports 页面将在 2026 年 12 月 31 日停止，并要求把保存报表和定时任务迁移到统一 Reporting 页面。统一报表会标准化指标名，并把转化统一放到 traffic date。
对脚本来说，这意味着：
- 不要只靠固定英文列名判断 7 天或 14 天窗口；
- 保存报表类型、账户类型、站点、时区和生成时间；
- 迁移前做新旧报表同窗口并行对账，确认 Purchases、Sales、ROAS 与 promoted/halo 字段映射；
- 不要在 2026 年底才第一次验证新报表解析器。
一张可以直接使用的归因检查表
□ 这是 seller、vendor 还是 author 账户？
□ 广告产品是 Sponsored Products 还是其他产品？
□ 报表按 traffic date 还是 conversion date？
□ 最近数字只是尚未刷新，还是仍处于归因窗口？
□ 硬判断是否只使用 D-7/D-14 以前的数据？
□ 订单下降是否来自取消、付款失败或归因竞争？
□ Cost 变化是否来自无效流量验证？
□ 报表时区、站点、币种与窗口是否固定？
□ advertised product 与 purchased product 是否混为一谈？
□ 自动计划是否保存数据截止日、快照与执行回执？
昨天的 ACOS 不是“错”，只是它对昨天那批点击的结果还没有完全长出来。近端数据适合发现风险，成熟数据才适合证明效果。把这两个用途分开，既能及时止血，也不会因为订单晚到几天就把仍然有效的流量入口误杀。
归因成熟只是自动化的其中一只时钟；对象冷却必须从真实 applied_at 起算，请继续看 Amazon 广告多久调一次价？把运行频率、归因窗口和冷却期分开。
官方资料与继续阅读
- Amazon Ads：广告活动归因、回溯窗口与事后修正
- Amazon Ads：Performance metrics 数据更新时间
- Amazon Ads：创建可下载报表与刷新频率
- Amazon Ads：统一报表与 traffic date
- Amazon Ads：2026 年统一报表迁移说明
- Amazon 搜索词花到多少该停？别再套用固定点击阈值
- Amazon 搜索词报告怎么看？从报表到否定关键词的 7 步流程
- Amazon 利润和领星为什么对不上？一张桥接表拆清差额
- Amazon 广告自动调价：我给 RongAds 加了 7 道安全闸，然后把自动化删了
- Amazon 广告预算烧完要不要加钱？先分清 budget、bid 和转化问题
- Amazon 广告多久调一次价？把运行频率、归因窗口和冷却期分开
