周期性项目的规则要在第一次就定好
一次性采集和周期性更新是两种不同的项目。
一次性采集只需要回答“现在是什么样”。周期性更新要回答的是“和上次比变了什么”，而这个问题需要一整套规则支撑。这些规则如果第一次没定，后面补的代价很高——因为首次采集的数据结构可能根本不支持做对比。
需要提前确认的四件事
一、更新频率
按数据的变化速度定，而不是按越勤越好定。
商家名单这类信息变化缓慢，按月或按季度更新通常足够。商品价格变化频繁，但更新频率应该匹配你的决策频率而不是数据的变化频率——如果调价决策每周做一次，那么每天采集并不会带来额外价值，只会增加成本。
有一类例外是需要还原变化过程的场景，比如观察竞品在促销期间的调价节奏。这种情况下高频采集有意义，但应该限定在特定时间窗口内，而不是全年高频。
二、增量规则
明确用什么判断一条记录是新增、消失还是变化。
这需要一个稳定的标识字段。商品有商品编号，帖子有链接，商家则往往没有天然的唯一标识——这时候就要用名称加地址的组合，或者电话、网站域名来判断。这个判断规则和去重规则应该是同一套。
还要约定“消失”怎么处理。一家商家这次没采到，可能是关门了，也可能是搜索结果排序变化导致这次没覆盖到。前者应该标记为已关闭，后者只是覆盖波动。区分不了的时候，标记为“本次未出现”比直接删除更安全。
三、字段变化怎么标记
交付时建议给两份文件：
- 变化对比表：标记哪些是新增记录、哪些本次未出现、哪些记录的哪些字段发生了变化（含变化前后的值）
- 最新全量表：去重后的当前状态，可以直接使用
这两份用途不同。前者用于观察趋势和触发动作（比如竞品降价了要不要跟），后者用于直接进入业务流程。
对于价格这类快照字段，我们默认保留每次快照而不是覆盖。覆盖式更新会让历史无法追溯，而价格数据的价值恰恰在于变化过程。
四、目标网站改版后怎么办
这是周期性项目里唯一无法提前避免的风险。
目标网站调整页面结构后，原有的采集规则可能部分或全部失效。可能的表现是某个字段突然大面积为空，或者条数明显异常。
需要提前约定三件事：谁负责监测这种情况（我们会在每次更新时对比字段完整率，异常会主动告知）、重新适配的成本怎么算（结构小改通常包含在维护范围内，大改会单独说明并确认后再做）、适配期间的交付怎么处理（是暂停一期还是交付部分字段）。
把这三点写清楚，改版发生时就不会变成扯皮。
关于数据一致性
周期性项目有一个容易被忽略的要求：采集参数必须固定。
地区、语言、排序方式、筛选条件，任何一项在第二次采集时发生变化，两批数据就失去了可比性——而且这种差异从数据表面完全看不出来，只会表现为“数据好像变化很大”。
我们会把首次采集使用的全部参数写进交付说明，后续更新沿用同一套参数。如果确实需要调整参数（比如扩大地区范围），会作为一次新的基线重新开始，而不是和旧数据混在一起对比。