用 SP-API + Ads API 搭亚马逊每日自动报表：字段清单、时区口径，和三张表悄悄停更 5–7 周的教训

2026 年 3 月我们还是用脚本连上已经登录的 Chrome，到 Seller Central 和广告后台点下载报表；浏览器没开调试端口，脚本直接退出，当天就没有数据。后来改成以 SP-API 为主、广告走 Amazon Ads API，浏览器下载只留作过渡兜底。现在每天的数据源是这样的（接口版本以我们 2026-10 的接入文档为准）：

这是我们真在用的两份列清单。活动报告 9 列够用；定向报告必须多要 7 列「是哪个词、哪个定向」的身份字段，否则每一行都只是活动级汇总，入库时会被当成无效行丢掉。

自动报表里最常见的错，不是公式错，而是两个数字其实不是一个口径、一个日子。我们定死了下面 5 条：

2026-10-09 我们给每个数据源登记「最大允许滞后天数」后跑了第一次检查。销售和广告活动数据到 10-07、订单明细到 10-08、财务到 10-04，都在预期内；但有三处明显停了。停了多少天是我们自己从最后一次正常更新算到 10-09 的：

大家搭自动报表，通常先做漂亮的日报和看板。我们的看法是顺序反了：日报会在数据停了以后继续照常生成，看不出问题；只有一张写着「每个来源截止到哪天、允许滞后几天」的表，才会在某个来源超过允许滞后时报警。

我们的登记表每个来源一行：用哪张表、看哪个日期列、过滤条件、最大允许滞后天数、谁负责生产、状态（在用 / 已知停更 / 已退役）。滞后按美西当天算。每天流水线最后一步跑一次检查，结果同时写成人读日志和机器读文件；已知停更和已退役的来源只显示不报错。检查不让整条流程失败，只告警，避免一张表停了连带其他报表都不出。

给 AI 做分析时也一样：每次复盘开头先贴这张表，结论里分别写订单、广告、库存、流量各自截止到哪天。具体怎么写，见我们的「证据分 4 级、每个来源单独写截止日期」一文。

没有开发能力，也能拿到这套做法里最值钱的部分。下面是我们的建议，不是我们店铺的数据：

它让我们少看错数据，但不会自己带来销量。店铺目前仍未真正盈利；我们没有「上自动报表前后」的利润对照，也没有统计省了多少工时，所以不写这类数字。部分接口要单独申请角色（比如库存台账），申请到之前就是会有缺口，只能如实标「未知」。

我们不对外提供接口代码和密钥。每日复盘的提示词、agent 规则模板和报表字段清单整理在 ¥99 工作流包里；想让我们帮你的店铺接数据、定截止日期规则，可以登记首次诊断。