SDK数据保留与删除怎么设计：期限矩阵、用户请求、备份回收与审计证据

这里讨论的“保留”是数据保存期限与到期回收，不是次日留存率、7日留存率或Cohort同期群分析。读者可以使用文中的决策矩阵和删除状态流程，组织一次研发、数据、安全与法务共同参与的范围评审。

SDK数据保留与删除为什么不能采用一个统一期限

不同SDK数据承担的业务目的不同，期限起点和到期动作也不会天然一致。原始事件可能用于产品分析，账号资料用于提供服务，网关日志可能用于安全排查，交易或行业记录还可能受到额外保存要求约束。把这些数据统一设置为同一天数，往往无法同时满足最小必要、业务验证和法定保存要求。

《中华人民共和国个人信息保护法》将收集、存储、使用、加工、传输、提供、公开和删除都纳入个人信息处理活动。除法律、行政法规另有规定外，个人信息保存期限应当是实现处理目的所必要的最短时间。

“最短时间”不是一个可以直接复制到所有项目的固定数字。企业需要回答三个问题：这类数据为什么继续存在，期限从哪个时间点开始计算，期限届满后系统执行什么动作。

常见的期限起点包括：

• collected_at：客户端采集时间，适合按事件产生时间控制明细数据期限。
• received_at：服务端实际接收时间，适合处理离线缓存和延迟上报，但可能与真实行为时间存在偏差。
• last_active_at：用户最后活跃时间，只适用于确实需要按持续关系计算期限的数据，不应默认用于全部事件。
• account_closed_at：账号注销或服务关系终止时间，可用于启动账号关联数据的处置流程。
• purpose_completed_at：特定分析、活动或项目目的完成时间，适合目的明确且可以判断结束状态的处理活动。
• legal_hold_released_at：法定保存、争议处理或调查限制解除时间，只能用于具有明确依据的例外记录。

期限届满后的动作也不只包括物理删除。根据数据性质和适用要求，可能采取删除、经评估的匿名化、限制处理、归档或人工复核。加密、哈希、改写用户ID或从报表中隐藏记录，不应未经评估就称为匿名化。

企业可以通过SDK数据采集链路先梳理事件、属性、用户ID、本地缓存和服务端接收位置，再讨论各层数据的保留期限。没有完整的数据对象清单，期限配置很容易只覆盖分析平台，而遗漏日志、导出文件和下游副本。

如何建立SDK数据生命周期与删除传播决策矩阵

期限设计应落在可以维护、执行和审计的字段上，而不是停留在隐私政策中的一句“我们会在必要期限内保存”。下面的矩阵是演示框架，不代表任何真实客户项目，也不提供统一保存天数。

正式矩阵还应增加处理目的、处理依据、敏感级别、第三方接收方、责任部门、法定例外、备份残留窗口和最后复核日期。一个字段只有在明确责任人、执行任务和验证方法后，才真正具备实施价值。

期限矩阵覆盖率可以作为内部治理指标，计算方式为：已配置处理目的、期限起点、期限长度和到期动作的数据对象数，除以已识别数据对象总数。这个指标不是法律规定，也不能脱离数据资产清单单独使用。资产识别不完整时，覆盖率可能看起来很高，但大量副本仍未进入治理范围。

用户删除请求怎样覆盖匿名ID、登录ID和派生数据

用户通常通过账号、邮箱、手机号或登录状态发起删除请求，但SDK历史数据未必只使用登录ID保存。用户注册或登录前产生的事件可能绑定匿名ID，登录后又通过映射关系合并到账号主体。跨设备使用时，还可能出现多个匿名ID、设备实例ID和服务端账号ID。

因此，删除流程不应从“执行SQL删除”开始，而应先解析主体范围。一个可执行的状态流程可以包括：

1. 已接收：生成随机请求编号，记录请求渠道和受理时间，避免在工单中复制不必要的原始事件。
2. 身份已核验：确认请求人有权处置相关账号，同时防止共用设备或错误身份导致误删。
3. 范围已解析：通过受控映射找出相关登录ID、匿名ID、设备实例ID、用户属性、文件对象和第三方标识。
4. 例外已审查：确认是否存在仍未届满的法定保存义务、争议处理或其他适用限制，并缩小保留范围。
5. 生产数据处理中：处理账号库、原始事件、清洗表、对象存储、缓存、搜索索引和导出文件。
6. 派生数据处理中：删除或重算标签、画像、归因结果、营销人群和实验分组。
7. 第三方待确认：调用供应商删除接口或提交删除工单，记录回执和失败原因。
8. 备份已限制使用：记录备份残留窗口，防止备份被恢复后继续用于分析、画像或营销。
9. 验证通过：使用批准的身份键和测试查询检查非例外系统中是否仍存在可用数据。
10. 已关闭：记录完成时间、异常处置、审核人和必要的最小化审计证据。

身份映射表的处理顺序尤其重要。如果过早删除匿名ID与登录ID的对应关系，下游系统可能失去定位历史数据的能力；如果长期保留完整映射，又可能继续形成可识别关系。较稳妥的做法是先生成受控的删除范围清单，再执行各系统任务，完成验证后处置映射关系。

原始事件被删除，并不代表派生结果会自动消失。实时标签可能仍在缓存中，离线画像可能尚未重新计算，用户也可能继续存在于推送名单、运营人群或实验分组。需要结合数据血缘判断这些结果是否仍能关联到个人，以及是否应删除、重算、匿名化或停止使用。

用户行为分析数据结构可以补充事件、用户属性、Session、标签与分析结果之间的关系。删除设计的业务影响也由此产生：如果只处理原始事件，不处理仍在业务系统中生效的标签，用户可能继续收到基于旧数据生成的触达。

《中华人民共和国个人信息保护法》规定的删除情形不只包括用户主动申请。当处理目的已经实现、无法实现或不再必要，产品停止服务、保存期限届满、用户撤回同意，或者处理活动违反法律、行政法规或约定时，也可能触发删除要求。法律、行政法规规定的保存期限未届满，或者删除从技术上难以实现时，不应继续进行分析、营销或画像等处理，而应在适用规则下停止除存储和必要安全保护措施之外的处理。

客户端缓存、消息队列和第三方SDK为什么会让数据重新出现

主数据库查询不到用户记录，只能证明这一处当前没有返回结果。SDK数据链路中还存在多个可能重新写入数据的节点。

客户端离线缓存

移动端SDK通常可能存在本地事件队列、批量上传和失败重试机制。用户在离线状态下产生的事件，可能在账号注销或服务端删除完成后才重新联网上传。删除设计需要同时处理两个方向：阻止注销主体继续产生新的账号关联事件，并清理或抑制本地尚未上传的旧事件。

退出登录也不能直接等同于删除。退出登录通常只是解除当前登录状态；匿名ID、本地存储、事件队列以及服务端历史记录是否处理，需要依据实际SDK方案逐项确认。

消息队列与失败重试

事件进入服务端后，可能经过消息队列、延迟任务和死信队列。即使原始表已经完成删除，仍在队列中的旧消息也可能被消费并重新写入。删除编排器应向接入层传播主体状态，或者在写入环节检查受控的删除抑制清单。

同一删除任务还应支持幂等处理。任务重复执行时，不应恢复已经删除的数据，也不应因为第三方接口超时而产生相互矛盾的状态。可记录请求编号、目标主体版本、目标系统、执行次数、结果和失败原因。

第三方SDK和受托处理方

应用中的分析、推送、客服或营销SDK可能保存自己的用户标识和历史数据。停止向第三方发送新事件，不代表历史副本已经被处理。采购和实施阶段应核对供应商是否支持按用户删除、批量删除、状态查询、失败重试和删除回执，并明确这些能力覆盖原始事件、用户属性、标签还是仅覆盖部分数据。

Google Play用户数据政策要求开发者对应用中第三方代码和SDK的数据处理承担相应政策责任。企业不能因为数据由外部SDK接收，就把数据保留、用户请求和安全责任完全转移给SDK提供方。

具体分析产品提供的期限设置也不能替代企业级生命周期治理。例如，Google Analytics数据保留设置只适用于该产品规定范围内的用户级和事件级数据，并受当前产品版本与配置影响。它不能自动控制企业自建数仓、网关日志、对象存储、导出文件或其他第三方平台。

备份不能立即逐条删除时应该怎样处理

备份系统常采用快照、不可变对象、磁带或周期性轮换，未必支持对单个用户进行原位修改。由此不能推出“备份可以永久保留”，也不能简单要求每次用户请求都销毁整块存储介质。

英国信息专员办公室关于删除权与备份的指导指出，在无法立即覆盖备份中的个人数据时，组织需要确保这些数据不再用于其他目的，并按照既定备份计划进行替换，同时向个人说明备份中的处理方式。该指导属于英国数据保护框架下的监管说明，不能替代其他司法辖区的具体要求，但可以用于理解“不可立即修改”与“仍可正常使用”之间的区别。

备份回收至少需要四项控制：

• 限制用途：备份只用于经过批准的灾难恢复，不得继续用于报表、画像、营销、测试或模型训练。
• 记录残留窗口：明确生产删除完成时间，以及包含相关数据的最后一份备份预计何时到期、覆盖或退出使用。
• 恢复后重新执行删除：备份恢复到生产环境后，应自动应用删除抑制清单或重放尚在有效范围内的删除任务。
• 开展恢复演练：使用测试主体验证恢复过程不会让已删除数据重新进入查询、标签、人群和业务触达链路。

备份残留窗口可以作为内部风险指标，计算方式是：生产系统删除完成时间，到包含该数据的最后一份备份到期、覆盖或完成不可用控制的时间差。这个时间差只描述技术状态，不代表企业可以在窗口内恢复并继续使用相关数据。

存储设备退役、磁盘回收或介质报废时，可以参考NIST SP 800-88 Rev.2介质净化指南评估清除、净化和销毁措施。该指南解决的是存储介质净化与处置控制，不是每次用户删除请求都必须销毁整块介质的依据。

删除完成后如何验证，而不是只看任务状态

删除任务显示“成功”，可能只代表接口返回了成功码。真正的验收需要检查应该处理的系统是否全部覆盖、数据是否仍可通过其他身份键检索，以及恢复和重算任务是否会重新生成结果。

以下指标可作为企业内部实施口径，不是法律统一规定：

• 删除目标覆盖率：本次请求已成功处理的适用系统数，除以本次请求应处理的系统总数。
• 删除传播时延：最后一个适用目标完成处理时间，减去请求正式受理时间。可以观察中位数、P95和最大值，但不能把企业内部目标写成法定期限。
• 超期残留数：超过内部截止时间后，仍可在非例外系统中通过批准身份键检索到的数据对象数量。
• 第三方删除确认率：已经取得删除回执或可验证处理结果的受托方数量，除以本次请求涉及的受托方总数。
• 恢复回归通过率：备份恢复演练后，测试删除主体未重新出现在可用生产数据中的通过次数，除以恢复测试总次数。
• 审计证据完整率：具备请求编号、核验状态、处理范围、目标系统、执行结果、异常理由、审核人和关闭时间的工单数，除以已关闭工单总数。

审计日志同样需要最小化。日志应证明什么请求在什么范围内、由什么任务处理到什么结果，但不应复制完整邮箱、手机号、事件属性、用户画像或待删除数据。哈希后的稳定标识如果仍能持续匹配同一个人，也不能未经评估就宣称不属于个人信息。

《个人信息保护合规审计管理办法》及其审计指引要求审查保存期限或确定方法、到期处理方式、删除权保障、申请受理机制和内部制度。处理超过1000万人个人信息的个人信息处理者，适用该办法规定的特定审计频率；这一门槛不能扩大解释为所有企业统一采用相同频率。

验收时不应只检查主数据库。建议准备一组脱敏测试身份，依次检查原始事件、清洗表、宽表、标签平台、对象存储、缓存、搜索索引、消息队列、导出文件、第三方平台和备份恢复结果。发现残留时，应记录残留位置、身份键、产生原因和修复任务，而不是直接关闭请求。

应用商店规则、隐私披露与法律要求应怎样区分

账号删除入口属于平台规则的一部分，数据删除义务则可能同时来自适用法律、合同和企业公开承诺。应用通过商店审核，不代表已经自动满足全部个人信息保护要求；反过来，具备内部删除流程，也不代表账号删除入口已经符合平台当前审核规则。

Apple关于App内账号删除的说明要求支持账号创建的App提供App内删除入口，并处理账号记录及无须依法继续保存的关联数据。只提供暂时停用或禁用账号，不能替代账号删除。Apple App Review Guidelines页面在本轮资料中记录的最后更新时间为2026年6月8日，本次核实日期为2026年7月28日。

Google Play用户数据与账号删除要求规定，支持账号创建的应用需要提供App内和外部网页删除路径，并处理账号及关联用户数据，而不是只冻结账号。该页面在本轮资料中未公开标注更新时间，本次核实日期为2026年7月28日，正式发布前应再次检查官方页面。

网站或产品的公开说明应与实际系统能力保持一致。可以通过隐私政策与信息保护说明披露保存期限或确定方法、用户权利、请求渠道和必要例外，但不能写入后台无法执行的承诺。对基础问题和适用边界，可在常见问题中补充说明账号注销、停止采集、匿名化、限制处理和删除之间的差别。

涉及金融、医疗、未成年人、交易记录、网络日志、跨境处理或争议保全时，保存期限和删除例外可能受到额外规则约束。本文只提供一般性技术与合规信息，不能替代针对具体企业、行业和司法辖区的法律意见，也不能作为应用商店审核通过的保证。

实施前应由哪些角色共同确认

SDK数据保留与删除同时影响数据架构、产品流程、用户权利和安全控制，单独由分析团队或法务团队完成都容易留下断点。

• 研发与SDK负责人：确认客户端缓存、登录状态、匿名ID、失败重试和删除接口的实际行为。
• 数据平台负责人：确认原始数据、清洗表、标签、画像、导出文件和数据血缘。
• 安全与运维团队：确认访问权限、消息队列、日志、备份周期、灾难恢复和介质退出机制。
• 产品与业务负责人：确认每类数据的处理目的、目的结束条件和删除后对功能的影响。
• 法务或个人信息保护负责人：确认适用依据、用户权利、法定保存例外、第三方责任和公开披露。

评审前至少应准备事件字典、身份映射规则、数据资产清单、第三方SDK清单、备份策略、隐私政策条款和一份脱敏删除工单。当前没有真实第一方材料时，只能使用本文矩阵作为演示框架，不能声称其已经在真实客户项目中验证。

下一步检查不应从“保存多少天”开始，而应先选取一个测试账号，画出它从客户端事件、身份映射、服务端接收、数仓加工、标签应用、第三方平台到备份恢复的完整路径。只要其中一个节点没有期限、执行任务或验证方法，SDK数据保留与删除流程就还没有形成闭环。正式上线前，应由内部法务、安全、研发和数据负责人共同复核适用范围、平台规则及最后核实日期。