迁移 Amazon Ads 报表时，别把指标口径一起迁错

Amazon Ads 已经给旧报表流程标出了删除日期。旧版 Sponsored Ads 和 Amazon DSP 报表页将在 2026 年 12 月 31 日关闭；Amazon 明确说，届时还留在旧页面里的已保存报表、计划报表、报表发送设置和历史数据都会被永久删除。

自助迁移工具预计在 8 月底可用，所以这不是 12 月才要收尾的杂活，而是现在就该进排期的运营任务。搬过去一个报表名称和发送时间不难；真正难的是保证搬完后，这个数字仍然代表原来的意思，仍然发给对的人，也仍然支持同一个决策。

把 12 月 17 日当成真正截止线

Amazon 从 6 月 8 日开放手工迁移，8 月底提供自助迁移。11 月 16 日进入 45 天倒计时。到了 12 月 17 日，旧报表不再允许新建或编辑，现有报表只读保留到 12 月 31 日关停。

这意味着 12 月 17 日才是最后的纠错闸门。如果团队那天之后才发现过滤器错了或计划任务漏了，虽然还能看旧输出，却已经不能修旧配置。Amazon 还特别注明这些日期可能变化，因此要保存当前公告快照，并指定一个人持续复核。

盘点时不能只看管理层熟悉的周报。计划邮件、代运营导出、财务对账、预算 pacing、客户仪表盘和低频月报都要纳入。一份平时没人提的报表，也可能正喂给关键预测。

先盘业务决策，再盘文件

每份报表至少记录负责人、收件人、账户、国家、campaign、过滤器、维度、指标、时间粒度、预期归因窗口、发送计划、下游去向，以及它最终支持哪个决策。重建前保存一份有代表性的旧输出和配置。

这样迁移才能变成控制测试。如果没人说得清这份报表支持什么，它可能可以退休；如果财务结账、竞价规则、客户账单或周度预算会依赖它，就必须有具名负责人和写清楚的指标契约。

也别假设新版今天已经覆盖所有旧报表。Amazon 列出的 2026 年晚些时候才计划接入的项目，包括 MRC viewability、Benchmarks、Conversion Path、Sponsored Products video、Sponsored Products prompts、Sponsored Products across retailers，以及部分 legacy Sponsored Brands 的 targeting 和 search term 报表。停旧流程前先把这些依赖单独挂起。

搬的是指标含义，不只是列名

统一报表把 Sponsored Ads 与 Amazon DSP 的术语拉齐了，但熟悉的列名可能对应更大的范围。Amazon 对 DSP 给出的关键提醒是：新版基础指标 Purchases 同时包含 promoted 和 halo purchase；旧版 DSP 的 Purchases 对应新版 Purchases (promoted)。如果不做这层翻译，dashboard 可能在广告表现没变化时突然变好。

转化日期也变了。统一报表把转化记在 traffic date，也就是广告互动发生的日期，而不是旧 DSP 和 legacy Sponsored Brands 使用的后续转化日期。即使总归因转化不变，历史日曲线也可能整体往前移动。

归因窗口虽然从指标名称里消失了，却没有从测量里消失。Amazon 说明：卖家 Sponsored Products 的基础指标使用 7 天，vendor 使用 14 天；其他广告类型通常是 14 天，使用 flexible lookback 的 DSP campaign 则按广告主选择的点击与浏览窗口。不要再从列名猜，要把这套 campaign-type 逻辑写进映射表。

先测历史窗口，再相信总数

统一报表按时间粒度设置了不同的历史和单次拉取上限。小时级只能看 14 天；Date 粒度历史可到 24 个月，但单次最多拉 120 天；Week 单次最多 15 个月；Month 历史可到 72 个月，但单次最多 25 个月；Year 与 date-range 汇总最多可跨 72 个月。

部分字段起点更晚。Advertised product 和 Converted product 从 2025 年 2 月 13 日开始，Audience segment 从 2 月 9 日开始，Frequency group 从 2026 年 1 月 16 日开始；reconciled cost 和 ROAS 从 2024 年 8 月 4 日开始，Reach 从 2024 年 7 月 1 日开始，off-Amazon conversions 从 2025 年 6 月 27 日开始。

Amazon 写得很清楚：超出可用期的维度会出现 null，历史不足的指标则可能返回不完整的汇总。因此，报表成功生成不等于数据完整。每次迁移都要拿请求日期范围对照字段可用期，并在下游 dashboard 标注部分覆盖期。

做一次双轨、负责人和权限测试

用同一组账户、campaign、日期范围、过滤器和时间粒度重建关键报表。对比行数和总量，再把差异分类：指标语义变化、历史窗口缺口、维度不适用、权限限制，或仍无法解释而必须阻断切换的问题。

发送链路也要测试。新 Reporting 页面支持按日、周、月计划发送，并可指定时区。Amazon 同时说明：收到邮件链接的人即使没有 Amazon 账户或 Ads Console 权限，也能打开报表。收件人列表就是一道访问边界；重建计划时要删掉离职员工、过期供应商和私人邮箱。

完成这些之后，才能重新连接表格、BI、代运营 scorecard 和自动化决策。新旧输出至少并行跑完一个完整运营周期，再由具名负责人确认指标映射与已接受差异。

The Operator Read

12 月 31 日是删除日，12 月 17 日是纠错截止线，而 8 月底是开工信号。

迁移成功不能用“复制了多少计划任务”来衡量。真正的验收是：团队能解释每个变化的总数，能指出每个不完整历史窗口，能说明谁可以打开每次发送，也能把 dashboard 追溯到一份获批的指标定义。

先盘决策，再翻译指标契约；双轨对照后，带证据切换。只有当业务仍然用一个自己理解的数字做同一个决策，这次报表迁移才算完成。