google关键词查询：工具停服后哪些数据应该优先迁出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3f80b6eec010.html
📄
google关键词查询：工具停服后哪些数据应该优先迁出
优先迁出的不是“全部历史记录”，而是三类仍有下游用途的数据：仍在产生决策的查询词及其分组、与页面或广告组绑定的映射关系、以及能解释口径变化的字段定义。只导出关键词列表而丢掉分组和口径，迁到新工具后往往等于从零开始。
先看一个矛盾现象：导出越多，越难用
旧工具宣布停服时，常见的第一反应是把所有能导出的内容一次性拉下来。结果是拿到几十万行词表，却不知道哪些词属于哪个落地页、哪些词是当初为某次投放临时加进去的。真正能继续使用的数据反而被淹没。
这个现象有两种解释。一种是旧工具的数据结构本身以“词”为中心，分组和备注只存在于界面里，导出时天然丢失；另一种是导出时选了最宽的时间范围和最细的粒度，把早已失效的临时词也混了进来。两者的处理方式完全不同：前者要靠人工或脚本重建映射，后者只需要重新按时间窗筛选。
区分两种解释的证据
判断属于哪一种，可以看导出文件里是否保留了这几类字段：
- 词与目标页面的对应列，或广告组、系列等层级标识；
- 添加时间、最后修改时间、标签或备注；
- 匹配类型、地区、语言等限制条件；
- 当初的指标口径说明，例如统计周期和去重方式。
如果这些列存在但为空，说明是导出范围设置的问题，重新导出即可。如果这些列根本不在导出结构里，说明旧系统的组织信息只存在于界面层，必须在停服前通过截图、逐层展开记录或接口分页抓取的方式补出来。这一步不做，后面任何迁移都会缺一块。
按“下游是否还在用”排序，而不是按数据量
迁移顺序建议这样排：
- 仍在产生动作的词与分组。判断标准很简单——过去一个季度里，是否有人因为这些词改过页面、调过出价或写过内容。是，就优先迁。
- 词与页面、广告组的映射。这是最容易被忽略、重建成本最高的一类。词可以重新查，映射关系往往只存在于旧系统。
- 口径定义与字段说明。新工具的数字对不上时，能靠它判断是数据变了还是统计方式变了。
- 历史指标快照。只保留能作为基线的部分，例如按月的汇总，不必逐日迁移。
- 已停用、已下线的词。最后处理，多数情况下只需要留一份归档文件，不进入新系统。
一个假设的例子：某站点旧工具里有约八千个词，其中约六百个在过去半年被实际使用过。如果先迁这六百个及其分组，再迁映射和口径，迁移工作量可能只有全量导出的十分之一，但覆盖了绝大多数后续动作。数字仅用于说明比较方法，实际比例需要按自己的使用记录统计。
迁移前必须做的两个动作
第一个动作是冻结一份只读快照。在停服前把导出文件、界面截图和字段说明放在同一个目录，标注导出日期。这样做的影响是：之后发现新工具数据对不上时，有可回溯的基准，而不是靠记忆争论。
第二个动作是先小批量试迁，再决定全量策略。挑二三十个仍在使用的词导入新工具，检查分组、匹配类型和指标口径是否还原。如果试迁后发现映射无法保留，就需要调整方案，改为在新工具里重建层级，而不是继续搬运旧结构。试迁结果直接决定后续是全量迁移还是只迁核心部分。
哪些数据可以放弃，以及放弃的前提
已下线的词、重复的变体、没有对应页面的长尾词，通常可以只留归档。但放弃有一个前提：确认这些数据没有被其他系统引用，例如报表、自动化脚本或外部合作方。如果存在引用，先记录引用关系再决定是否丢弃。
另外要注意，导出量下降或某个报表归零，不能单独证明迁移做对了。也可能是筛选条件变了、统计周期没对齐，或者新工具的去重逻辑不同。遇到这种情况，先用快照核对字段定义，再判断是数据问题还是口径问题。
停服迁移的合理目标是：让新系统能继续支撑当前的判断和动作，而不是把旧系统完整复制一遍。按这个目标排序，迁移范围通常会比想象中小，但留下的部分都能用。
