1688 广告数据，等 16 天真的够吗？我们做了个重采实验
TL;DR
「等 16 天再下结论」不够。我们把 5 个早已「定型」的历史周从平台重新拉了一遍，做了一次对照实验：结束后的广告周，最晚到第 29 天还在长新数据（晚加的词会回来「翻旧账」）；而到第 40 天以后，哪怕把历史周整个重采一遍，已有的旧数字一个都没被改；比定稿更残酷的是保留期——平台明细只留 6~7 周，54 天后 6 个计划全部无法补回。每周采集、本地存档——换来的是两样东西：不可逆的决定不踩坑，历史数据归你自己。
导火索：结束后第 29 天，还在长新数据
一间工业品类目 B2B 店铺（已匿名）的例行续采里，8 月 10 日的一次采集，往一个已收尾 29 天的自然周写进了 27 行新的区域明细——涉及 5 个计划，行数 +22%。而按圈内流传的口径，这个周早在半个月前就该「16 天封账」了。
16 天到底是平台实测，还是以讹传讹？验证方法现成：往更老的历史周里再采一次。如果几十天前早已「定型」的周重采后会冒出新行、改掉旧值，说明 16 天远不是终点；顺手还能量出平台把明细到底留多久。8 月 21 日，我们把 5 个更老的周重新拉了一遍，就有了下面这个实验。
这个实验，来自开发 AI 运营 过程中的一次数据口径核查。
实验设计：把 5 个「已定型」的周重新拉一遍
思路很朴素：基线 → 重采 → 逐行对照。
- 选 5 个连续自然周（2026-06-08 ~ 07-06），补采前它们距当时已有 40~74 天，按任何口径都算「定型」；
- 先导出一份基线（4 张明细表：总览 / 商品 / 关键词 / 区域，共 1199 行）；
- 触发一次平台补采（指定日期范围，全量重拉），再导一次；
- 逐行 diff：新增多少行、值变化多少、消失多少。2026-09-02 复查，结论未变。
对照结果：
| 表 | 基线行数 | 重采后 | 新增行 | 值变化 | 消失 |
|---|---|---|---|---|---|
| 计划总览 | 18 | 18 | 0 | 0 | 0 |
| 商品明细 | 682 | 682 | 0 | 0 | 0 |
| 区域明细 | 405 | 405 | 0 | 0 | 0 |
| 关键词明细 | 94 | 105 | +11 | 0 | 0 |
1,199 行逐行对照的净结果：没有一个历史数字被修订（值变化 0、消失 0），唯一的差异是关键词表多出 11 行。这 11 行不是值改了，而是新长出来的实体——两种回补机制的区别见发现二；平台这次到底只重新返回了哪些计划的明细，藏在发现三。
发现一：值的账，16 天封不住，40 天后才是真终态
先说结论的边界：「16 天」既对，也不对。
- 平台口径的归因回补约 15 天，「16 天封账」由此而来；
- 导火索事件正是反例：结束后第 29 天仍长出 27 行新区域数据，几乎是口径的两倍；
- 实验补上终止点：40~47 天龄的周重采后历史值零变化——回补终究会停，只是停止点比 16 天晚得多。
对运营的含义：用 16 天做「大概能看」的依据可以，作为「定稿」的依据不够。 计划去留这种不可逆决定，等满 4~5 周再看封账数据，才踩在实测的停止点之后。停计划前的完整检查清单，见 1688 广告计划什么时候该停？先过五道检查。
发现二：中途加过的词，会把以前的数据「补」回来
人话版结论先行：你能「翻旧账」翻出多少东西，取决于你现在挂了哪些词。
实验店铺的某个计划中途加过几个词。重采历史数据时，平台把你现在挂在计划里的词，连以前每周的表现一起送了回来——有个词补出的历史周带着完整指标：11179 次曝光、¥342.7 消耗、10 条询盘、11 笔订单。这些数一直躺在平台那边，只是你不去采，它就不出现。
（专业注：机制叫「实体级回补」——接口按当前关键词列表返回历史周数据。行数会涨，已有行的值一个不变。所以看到重采后数据变多，先分清是旧数字被改了、还是长出了新行：前者要警惕，后者是白捡。）
但「白捡」有个前提：平台还得留着明细。留多久？这就是发现三。
发现三：真正的悬崖不是定稿晚，是明细被删
回补慢只是「等」，保留期是「没」。重采时按计划逐个检查了平台还能不能返回明细：
- 40~47 天龄的两个周：同一批 6 个计划里，只有 3 个还能返回完整明细；
- 54~74 天龄的三个周：还是这 6 个计划，全部返回 0 行——不是值旧了，是明细已经从平台侧删除，永远无法补采；
- 40 天就返回全空的那 3 个，是计划级保留期更短、比全局悬崖走得更早——本次样本仅一例，待后续观察。
换句话说：凡是没在 6 周内落到自己库里的明细数据，平台已经替你删了。 「以后有空再导」不是拖延，是丢弃。
这套发现值多少：先算两笔账
误杀账。 16 天口径最大的成本，是把「数据没到」误读成「计划不行」。发现二里那个补出历史数据的词，单周就有 10 条询盘、11 笔订单——一个正在起量的计划被提前误停，一周的损失就是这个量级，还没算重新起量要再搭的一两个结算周。等满 4~5 周再拍板，买的是「不做错决定」。
丢失账。 平台 6~7 周就删明细，「回头再补」是会过期的幻想。上季度哪个区域在供询盘、哪个词的成本在悄悄爬升——这些问题只有把数据落进自己库里的人才答得上来。每周一次采集导出，买的是「历史永远可查」。
给运营者的三条纪律
- 看趋势，随时看；下不可逆的决定，等 4~5 周。 16 天做参考线，29 天做保险线。
- 每周固定采集或导出一次明细，本地存档。 平台侧的明细比你想的短命得多，存档才是你自己的数据资产。
- 复盘前先补齐「结算尾巴」（每个周期还在陆续补记的那部分数据）。 评估某段时期的整体效果，要把每个周期的回补都算进去，否则结果会系统性偏低——分不清旧数字被改了还是长了新行时，用实验里那招：逐行对照。
给做数据集成的人：重叠窗口至少留 5 周
如果你的系统在按周续采 1688 广告报表（或做类似平台的归因数据管道）：平台口径 15 天的归因窗口，实测最晚回补在 +29 天。严格周节奏 + 4 周重叠的配置，最后一次重写落在周末后 +22 天——恰好盖不住实测的 +29 天事件（我们那次是靠采集间隔偶然拉长才兜住的）。把重叠窗口从 4 周调到 5 周，每周请求量约多 20~25%——每多回溯一周，就多拉一周的分页明细，换的是不再漏数据。
每周固定两个动作
- 采：本周明细落库或导出，重叠窗口留够 5 周——存档是对抗删除的唯一手段；
- 等：停/留决定等数据满 4~5 周封账再拍——封账是对抗误判的唯一手段。
常见问题
1688 广告数据要等多久才算定稿？
平台口径归因约 15 天，但实测最晚回补发生在周末后第 29 天。稳妥做法是等满 4~5 周再下计划去留的结论。
历史广告数据没及时导出，之后还能补回来吗？
大概率不能。平台明细只保留约 67 周：实测 4047 天仅 3/6 计划可查，54 天后 0/6，超期永久丢失。
为什么重采后多了没见过的关键词行？
接口按当前关键词列表返回历史周数据。晚加的词会补出历史行——实体级回补：行数会涨，已有行的值不会变。
这套「基线 → 重采 → 逐行对照」的核查方法，已经内建进 AI 运营——基于大语言模型的智能分析，自动洞察市场趋势、用户行为、销售数据，提供精准运营策略。广告数据是一切分析的地基，而地基的口径，值得实测一次。