TapCub 正式上线:统计、分析、客服一个平台免费用
数据分析

数据保留政策:法律依据、示例时间表和怎么执行

数据保留政策规定每类数据保存多久、怎么删除。讲清法律依据(GDPR、CCPA)、要包含什么、统计数据的示例时间表,以及从「永不删除」改成 13 个月的算例。

伊森·布鲁克斯 发布于 2026 年 11 月 5 日 5 分钟阅读 数据分析
数据保留政策:法律依据、示例时间表和怎么执行示例数据

「以防万一」全部留着,是大多数公司的默认做法,在隐私法下却是负担。本文讲法律依据、保留政策的七个部分、一张把含个人数据的事件和长期汇总分开的示例时间表,以及一个产品把原始事件保留期从 4.5 年降到 13 个月后发生了什么。

读完你会知道

  • GDPR 要求个人数据保存不得超过必要期限
  • 每类数据都要定期限、目的、负责人和到期处理
  • 汇总留长,事件级个人数据留短
  • 自动删除,导出文件和备份也要覆盖
  • 在隐私声明里公布保留期

什么是数据保留政策?

数据保留政策(Data Retention Policy)是一套成文的规则,针对组织持有的每一类数据,规定保存多久、为什么、存在哪里,以及到期后怎么删除或匿名化。它覆盖客户记录、统计事件、日志、备份、邮件和文件。

保留政策出于两个相反的原因:有些数据必须保存一个最短期限(税务记录、合同),而个人数据又不能保存得比必要的时间更长。好的政策两头都满足,而且是自动执行的,不只是写在纸上。

法律关于保留的规定
GDPR 第 5 条第 1 款 (e) 项,存储限制能识别个人的数据,保存时间不得超过收集目的所必需的时间
GDPR 第 13、14 条必须告诉用户数据保存多久,或者用什么标准来决定
GDPR 第 17 条,删除权数据不再必要时,用户可以要求删除
加州(经 CPRA 修订的 CCPA)企业要披露每类个人信息保存多久,且保存时间不得超过合理必要的期限
税务和会计法规发票和财务记录有最短保存期,按国家不同常见 6 到 10 年

监管机构专门因为数据保存过久而罚过款。罚款之外,个人数据每多存一个月,就多一份要保护的东西、处理数据主体请求时多一份要查的东西,一旦泄露也多一份损失。

保留政策包含什么

  1. 范围: 覆盖的系统和数据类别(生产数据库、统计、日志、备份、SaaS 工具、表格)。
  2. 保留时间表: 一张表,列出数据类别、保留期、法律依据或目的、负责人,以及到期后的处理(删除、匿名化、归档)。
  3. 起算点: 从什么时候开始计时:采集日期、最后活跃、合同结束、撤回同意。
  4. 删除方式: 自动任务、匿名化还是人工处理;备份怎么过期。
  5. 例外: 诉讼保全怎么审批、怎么解除。
  6. 角色: 每类数据谁负责、谁审批变更、谁审计。
  7. 复审周期: 至少每年一次,新增系统或用途时也要复审。

统计数据的保留时间表示例

某 SaaS 公司统计及相关数据的时间表(示例政策,请按自己的目的和适用法律调整):

数据类别保留期原因
带假名 ID 的原始统计事件13 个月同比需要 12 个月再留余量
自动采集的点击和表单交互90 天只用于近期的体验排查
每日汇总(不含个人数据)长期不是个人数据;长期趋势需要
实名用户档案最后活跃后 24 个月召回和客服历史
同意记录失效后 24 个月被质疑时证明取得了同意
带 IP 的服务器访问日志30 天安全调查窗口
数据导出和临时 CSV7 天副本是最常见的泄露来源
发票和付款记录按税法(常见 6–10 年)法定义务,不属于统计

关键的设计是把事件级数据(含个人数据,保留短)和汇总数据(不含个人数据,保留长)分开。这样能保住长期趋势,却不必一直留着人的数据。

法律保留规则
GDPR 第 5 条 1(e)不超过必要期限
GDPR 第 13–14 条告知保存期限
GDPR 第 17 条不再需要时删除
CCPA / CPRA按类别披露期限
税法财务记录有最短期限

不构成法律意见,请核对适用于你的法律。

计算示例:把「永不删除」改成 13 个月会怎样

某产品每天发送 12 万个事件,上线 4.5 年来所有原始事件都留着(示例数字):

  • 存储的行数: 约 1.97 亿。改成 13 个月后约 4,700 万,少了 76%。
  • 存有历史的实名用户: 41 万,其中 29 万已超过两年没活跃。执行政策(最后活跃 24 个月后删除档案)后剩 12 万。
  • 数据主体请求的查找范围: 以前一次删除请求要查全部 1.97 亿行,外加共享盘里翻出来的四份临时 CSV 导出;现在只查 4,700 万行,导出文件 7 天后过期。
  • 受影响的报表: 日常看板一个都没有。三年以上的长期图表改从每日汇总读取,汇总里没有个人数据。

公司的数仓存储费用也降了,但更大的收益是泄露时影响更小、合规更简单。

app.tapcub.com/insights/users

存储行数

−76%

▼

保留的档案

−71%

▼

坏掉的报表

0

保留期调整 · 永不删除 → 13 个月

每天 12 万个事件
调整前调整后
原始事件行数约 1.97 亿约 4,700 万
实名用户档案410,000120,000
翻出的临时 CSV 导出4 份7 天后过期
受影响的看板—没有

示例数字。长期图表改读不含个人数据的每日汇总。

示例数据

怎么制定数据保留政策

  1. 盘点数据: 列出所有存储个人数据的系统,包括 SaaS 工具、日志和导出文件。
  2. 给每类数据定目的,再定满足这个目的的最短期限。「可能有用」不算目的。
  3. 和法务或财务确认法定最短期限,比如财务、雇佣和合同记录。
  4. 决定到期处理方式: 删除、匿名化或汇总。
  5. 自动执行。 定时任务、产品里的保留设置、存储的生命周期规则。靠人工执行的政策通常没人遵守。
  6. 处理备份: 按固定周期过期;不要把已删除的个人数据恢复回生产环境。
  7. 在隐私声明里公布保留期,这是第 13、14 条的要求。
  8. 每年复审并记录变更。

常见错误

  • 默认「全部保留」。 最常见、代价也最大的错误。
  • 所有数据一个期限。 不同类别服务不同目的。
  • 忘了副本: 导出文件、表格、BI 抽取和测试数据库。
  • 删掉了还要用的汇总。 先汇总,再删事件级数据。
  • 没有负责人。 没人负责的政策,会随着新工具的加入而走样。

TapCub 里的保留设置

在配置 › 隐私中心 › 数据最小化与保留里,TapCub 分别设置四个期限:事件行(默认 365 日)、自动采集(90 天)、用户档案(730 天)和同意记录(730 天),由定时任务删除过期的行。实际的事件保留期不能超过所用套餐的上限。每日汇总不含个人数据,不受这些计时影响,所以长期趋势会保留下来。分层衰减可以在到期前清空较早事件里属性、来源网址、标题这类高基数字段,同时让趋势和漏斗照常可用。IP 地址在采集时截断,不存在事件里。见 IP 截断和保留期、数据导出和删除和处理数据主体请求。更整体的做法见隐私设计。

参考资料

这篇文章对你有帮助吗?

我们会根据反馈修改和补充这篇内容。

伊森·布鲁克斯

解决方案工程师

围绕 SDK、接口集成与数据接入编写实践指南,关注实施验证、系统协作和技术排障。

设一次,自动执行

事件、自动采集、用户档案和同意记录分别设定期限,汇总保留用于看趋势。

看清数据,找到增长。

每一次点击,都有数据依据。装好一行代码,1 分钟看到第一批数据。

无需信用卡 · 统计与客服都有免费版 · 统计无 Cookie