概念定义与范围界定
咱们先把话说清楚，AB页跳转合规里提到的"斗篷系统接入第三方统计脚本后，数据对不上该按什么顺序校验？一份从信号分层到口径对齐的检查清单">数据留存期限"，到底指什么？简单讲，就是跳转链路跑起来之后，各个环节产生的那些数据，从它生成那一刻算起，最多允许你留多久。这个上限就是留存期限。那删除权落地规范又是干嘛的呢？它是围着这个上限转的一整套操作规矩——谁能提删除、什么情况下触发删、删到哪一步算删完了、删的动作怎么记下来。这俩凑一块儿，才算把AB页跳转的数据生命周期给管住了，缺一块都不完整。
范围这个事儿得先划拉明白。它管的数据对象有这么几样：跳转决策日志，就是记某次请求命中了哪条规则、走了哪个分支那种；访客特征信号，设备类型啊、网络环境啊、来源标识这些拿来判断分流的输入项；分流结果记录，也就是这次曝光到底算A页还是B页；再有就是为归因分析留的聚合统计中间表。那什么不在范围内呢？已经脱敏、聚合到没法回溯到具体个人的报表数据，这类东西因为不具备个体识别能力了，一般走另一套统计口径去管。
为啥非得把范围界定清楚？我见过太多情况，大家一聊AB页跳转合规，就把"日志"当成一个整体来说。可实际上决策日志、特征信号、聚合报表这三样，留存诉求和风险等级差得远了去了。你要是混在一起谈期限，结果就两种：要么定得太严，排查问题的时候抓瞎；要么放得太松，超期数据堆着没人管，隐患就埋下了。
留存期限的分级设定逻辑
留存期限可不是拍一个统一数字就完事，得按数据用途分层来定。分层的依据说白了就两个变量交叉：这数据对识别个体的贡献有多大，以及它对业务追溯有多必要。
按用途分层的三类期限
- 决策追溯类：这类数据是拿来回答"这次跳转凭什么走这个分支"的，故障排查、规则归因都靠它。保存期限一般跟规则版本的生命周期绑在一起，规则一下线，再留一个复核窗口，之后就可以清了。
- 异常核查类： 用来事后核对信号异常、特征冲突这些情况。期限通常比决策追溯类稍微长一点，道理也简单——异常这东西往往是滞后才发现的，你留太短就查不着了。
- 聚合统计类： 只存计数、比例、分布这种没法回溯到个人的结果，按统计周期滚动覆盖就行，不承担个体级的删除义务。
期限设定的约束条件
期限能定多长，受三个条件卡着。头一个是业务目的边界——你留存得有明确写下来的目的，目的没了，留存的理由也就没了。再一个是存储成本和检索效率，决策日志体量本来就大，期限一拉长，存储和查询成本蹭蹭往上涨，日均请求到百万级的系统里这问题特别扎眼。还有一个是规则版本的节奏，假如跳转规则每周都迭代，那决策日志的追溯价值基本集中在最近几个版本窗口里，出了这个窗口，日志对排查的边际价值掉得很快。
实际干活时有个挺常见的做法：把留存期限写成配置项，别硬编码在代码里。这样期限能跟着规则版本节奏调，但每次调整必须留变更记录。弹性有了，也不至于期限被人随手改长了还没人知道。
删除权的落地路径
删除权在AB页跳转这个场景里落地，难的地方真不在"要不要删"这个决定上。麻烦的是怎么删干净、怎么删得能验证、怎么删了还不误伤别的数据。整条路径我一般拆成四个环节来看。
触发条件定义
触发删除的情况分两类。一类是期限到了触发的定期清理，按前面分级设定的时间窗口批量跑。另一类是个体提了删除诉求，或者数据目的提前终止了，这种是请求触发的定向删除。这两类触发得在同一套元数据上打标，不然执行的时候准出问题——定期清理扫不到某些角落，那些数据就成漏网之鱼了。
删除执行的时候，粒度要细到单条决策记录，连它关联的特征信号副本也得算进去。完成判据这块儿，光看主表删成功可不够，缓存层、备份快照、还有下游同步出去的副本，全都得覆盖到。实践里最容易漏的就是缓存和异步同步链路：主库删了，缓存里还躺着呢；下游分析表隔天才同步，这中间那段时间数据其实还能被读到。你说这算删了吗？显然不能算。
删除这个动作本身也得留痕，但留痕内容得克制着来。合理的做法是只记删除批次、影响条数、触发类型和执行时间这几样，别保留被删数据的内容副本。有些人为了"证明我删过"，把原数据抄一份存着——这不叫删除，这叫换了个地方存。
验证与复核机制
删完之后得有抽样复核。从待删集合里抽一部分记录出来，确认在主存储、缓存、下游表里都检索不到了。复核结果才是删除任务的验收依据，不能光凭任务返回个成功状态就完事。
适用条件与边界
这套规范适合什么样的系统？存在个体级跳转决策记录、而且数据目的跟投放追溯直接相关的AB页跳转系统。不适用的情形有两种：一种是纯聚合统计、压根不留个体记录的轻量分流场景，这种按统计口径管就行了；另一种是数据目的本身就要求长期保留的审计场景，这时候留存期限得服从审计要求，但目的说明里必须明确写出来。
边界上还有个点容易被忽略：留存期限和删除权，这俩是两码事。期限到期是批量清理，删除权是个体诉求触发的定向处理。只设期限不建删除通道，真遇到定向诉求你没法执行；反过来只建通道不定期限，数据就无限堆积。得同时存在，规范才算完整。
说个匿名化的案例吧。有个做订阅类产品海外投放的团队，日均跳转请求几十万次量级，服务器就是几台中等规格的云主机加一个对象存储桶。早期他们决策日志全量落盘、不设期限，跑了半年，存储账单翻了好几倍，排查的时候又因为日志太杂找不到关键记录。后来他们把日志按用途拆成追溯类和统计类两路：追溯类跟着规则版本走，版本下线后留一个复核窗口就清理；统计类只存聚合结果。同时补了个按请求标识定向删除的入口，删完抽样核对主存储和缓存。调整之后存储开销回到可控区间，一次定向删除诉求当天就能走完流程。
相邻概念对比
有几个概念特别容易跟留存期限搅和在一起，放一块儿比一比，用起来才不容易出错。
- 跟数据最小化比：最小化管的是"收集什么"，留存期限管的是"留多久"。一个在采集环节起作用，一个在存储环节起作用，前后衔接的关系，谁也替代不了谁。
- 跟日志脱敏比： 脱敏处理的是数据内容的可识别程度，期限处理的是数据存在的时间长度。而且脱敏后的数据，靠关联组合照样可能具备识别性——所以脱敏代替不了期限管理，这点别搞混。
- 跟备份策略比： 备份策略关心数据能不能恢复，留存期限关心数据该不该还在。备份快照要是超出期限还留着原数据，那就是事实上的超期留存，得在备份轮转规则里一并考虑进去。
- 跟访问审计比： 访问审计记的是"谁看过数据"，留存期限管的是"数据本身存多久"。顺带提一句，审计日志自己也有留存期限，这俩得分别设定，别互相引用搞成循环依赖。
常见概念性问答
留存期限定得越短是否越合规
不是这么回事。期限太短，故障排查和规则归因就没了依据，业务侧为了补数据可能转头去用更粗放的采集方式，风险反而被放大。合理的做法是让期限跟业务目的严格对齐——目的需要多久就留多久，超出目的的部分一点不留。
不一定。落地形式可以是人工受理加内部执行流程，关键是触发路径得清晰、执行有记录、结果能复核。自助入口属于效率优化，不是规范的必备条件。
聚合统计结果是否需要纳入删除范围
聚合结果如果已经没法回溯到个体，通常不纳入个体级删除范围。但它自身的保存周期还是得设定，按周期滚动覆盖，不然聚合表无限增长，又成了一个新的留存盲区。
