DSAR 究竟是什么

数据主体访问请求（DSAR）是用户行使 GDPR 赋予其对个人数据所享有权利的时刻。对移动发行商而言，那个“数据主体”就是你的某位玩家或用户，请求可能通过电子邮件、支持工单、应用商店评价或应用内表单送达。触发条件很简单：有人想知道你保存了关于他们的什么信息—或者希望你对此采取行动。

关键在于，DSAR 无需提及 GDPR、使用“DSAR”一词，也无需遵循任何模板。诸如“把我的数据发给我”或“删除我的账户”这样的一行信息，与正式的法律函件一样会坚定地启动计时。仅把看起来正式的请求视为有效，是错过期限的捷径。

请求背后的权利

DSAR 捆绑了若干不同的权利，同一条信息可能援引不止一项。弄清哪项是哪项，决定了你实际需要做什么。

• 访问—用户可要求获取其个人数据的副本以及相关背景：你收集什么、为何收集、与谁共享、保存多久。
• 擦除（“被遗忘权”）—删除其数据，包括传递给广告与分析合作伙伴的副本，但受限于狭窄的法律例外。
• 可携带性—用户提供给你的数据，以 JSON 或 CSV 等结构化、机器可读的格式返回，以便迁移到别处。
• 更正—更正不准确或不完整的数据，例如错误的电子邮件或地区。

相关权利—反对处理与限制处理—常与这些权利相伴出现，尤其围绕广告个性化，用户可能选择撤回同意而非彻底删除其账户。

期限十分严格

你必须在收到请求后不无故拖延且在一个日历月内作出回应。计时从请求到达之日开始，而非你团队中某人注意到它的那天。对于确实复杂的请求，你可再延长两个月，但前提是你在第一个月内告知用户并说明原因。

回应通常免费。只有当请求明显毫无根据或过度时，你才可收取合理费用或拒绝，而证明这一点的举证责任在你。对大多数发行商而言，安全的假设是：免费，且在三十天内。错过这一窗口正是监管机构在评估罚款时所指出的那类疏失。

构建可扩展的工作流程

能从容处理 DSAR 的发行商已把它变成一个可重复的流程，而非一场救火行动。一套可行的工作流程如下：

• 接收。公布单一的、已告知的渠道—一个应用内表单或一个专用的 privacy@ 地址—并将一切都通过它路由，以免任何请求在支持队列中丢失。
• 验证身份。确认请求者拥有该账户，但只索取你所需的信息。为查找游戏内 ID 而要求护照扫描件，本身就是一个合规问题。
• 记录并加时间戳。立即记录到达日期；这是你期限的锚点。
• 定位数据。维护一份涵盖每个存储库的数据地图—你的后端、崩溃日志、分析、广告 SDK、CRM—凡是触及用户数据的，都以稳定的标识符为键。
• 履行并回应。按请求导出、删除或更正，将删除传播至处理者，并以通俗易懂的语言答复。
• 闭环。将请求及你的回应归档，作为你按时行动的证据。

常见陷阱

大多数失败是操作性的，而非法律性的。请注意以下几点：

• 被遗忘的数据存储库。广告与归因 SDK、推送提供商以及崩溃报告器都保存用户数据。跳过它们的删除是不完整的。
• 验证时过度收集，把一个隐私请求变成了一个隐私风险。
• 把非正式信息视为非请求，从而让一个月白白流逝。
• 没有同意证据。如果用户质疑你是否曾有合法依据为广告而处理其数据，你需要证明他们同意了什么以及何时同意的。

CMP 如何让 DSAR 变得可管理

这正是你的同意层体现价值之处。当你能即刻表明用户同意了什么、何时同意以及在哪个框架下同意时，DSAR 就远更容易回应。FlexyConsent—一个支持 IAB TCF 2.3 与 Google Consent Mode v2 的 Google 认证 CMP—为每位用户存储带时间戳的同意记录与审计轨迹。当访问请求到来时，该记录便成为你回应的现成组成部分：所接受的目的、所涉及的供应商，以及所展示通知的版本。当擦除或反对请求到来时，同一记录可证明你在恰当时刻停止了个性化广告信号。把这份同意历史与你的数据地图配对，便能把 DSAR 从手忙脚乱变成一次查找。

本文为面向发行商的一般信息，并非法律建议；请就你的具体情况咨询合格的专业人士。

要点

• 任何请求—无论多么非正式—都可能是 DSAR，而通常免费的一个月期限从它到达之日起算。
• 绘制每个数据存储库的地图，包括广告与分析 SDK，以使访问与删除真正完整。
• 按比例验证身份，并记录每个请求，以证明你按时回应。
• FlexyConsent 的同意记录与审计轨迹为你提供即时、可辩护的证据，以履行访问、擦除与反对请求。