Privacy Statnive Live · Parhum Khoshbakht

DSAR 不必焦虑：在统计脚本中实现访问权与删除权

GDPR 第 15 条和第 17 条不会因为是网站统计就放行。本文介绍如何设计不破坏汇总数据的访问权与删除权端点，以及我们已经上线的实现。

本文为隐私研究内容，不构成法律意见。完整免责声明见页脚。

TL;DR

  • GDPR 第 15 条和第 17 条同样适用于网站统计 —— 哈希后的 IP、Cookie ID、BLAKE3-HMAC 访客签名等假名化标识符依然属于个人数据，这是 Breyer、IAB Europe 以及 2025 年 5 月 14 日布鲁塞尔上诉法院判决一脉相承的立场。
  • 三个端点已上线 —— POST /api/privacy/opt-out、GET /api/privacy/access、POST /api/privacy/erase —— 全部具备 CSRF 保护、速率限制和审计日志。
  • 汇总表在删除请求后依然保留，因为它们已经聚合到不可识别的程度 —— uniqCombined64 HyperLogLog 草图本质上是计数，而非记录，无法反推单个访客的贡献。
  • 8 个隐私审计事件输出结构化的 GDPR 第 28(3)(h) 条问责证据，覆盖退出、访问、删除、同意授予/撤回以及法律页面访问。
  • EDPB 2025 协调执法框架的重点是删除权；EDPB 2026 协调执法框架转向透明度义务。两者都与本文所述的架构方向一致。

为什么网站统计是最容易被遗忘的 DSAR 表面

大多数 GDPR 数据主体访问请求（DSAR）工作流都围绕着个人数据明显存在的系统构建 —— CRM、客服工单系统、订单历史、邮件营销列表。网站统计栈通常是事后才想起的，而即便想起来，运营者的第一反应往往是 「那里没有个人数据，我们已经把 IP 哈希过了」。这种直觉在法律层面是错的，在架构层面也越来越站不住脚。

EDPB 关于假名化的指南 01/2025 草案 —— 于 2025 年 1 月 16 日第 101 次全会通过草案、公众咨询期至 2025 年 2 月 28 日，截至 2026 年 5 月仍在制定中 —— 明确指出：假名化数据（包括哈希后的 IP、Cookie ID、BLAKE3/HMAC 访客签名以及 TC 字符串）只要通过控制者或任何第三方可获得的手段重识别在合理可能性范围内，就仍属于个人数据。 CJEU 的 IAB Europe 判决（C-604/22，2024 年 3 月 7 日），经布鲁塞尔上诉法院 2025 年 5 月 14 日的判决（案号 2022/AR/292）确认后，将这一立场从 TC 字符串延伸到任何与 IP 配对的标识符。Breyer（C-582/14，2016 年 10 月 19 日）则更早就解决了运营者所持 IP 的定性问题。

在实务层面，这意味着：处理 IP、哈希 Cookie、BLAKE3-HMAC 访客签名或任何按访客划分标识符的网站统计，就是在 GDPR 意义上处理个人数据。第 15 条（访问权）和第 17 条（删除权）均适用。第 28(3)(e) 条要求处理者（如果有的话）协助控制者处理这些请求。第 33 条的违规通知时钟也涵盖影响这些标识符的违规事件。

下文是面向运营者的操作指南，包括：网站统计 DSAR 的解剖结构、Statnive Live 上线的三个端点、所需的审计追踪、汇总表为何能在删除请求后保留、面向开发者的 DSAR 操作手册，以及一份可运行的代码示例。

网站统计 DSAR 的解剖结构

针对网站统计栈的 DSAR 与针对 CRM 的 DSAR 不同，没有邮箱地址、没有客户姓名、没有明显的主键。数据主体来找您，实际上是在说：「我偶尔访问你们的网站，请告诉我你们有什么关于我的数据，并请删除。」

运营者实际上掌握了什么？

对于 Statnive Live 以 consent-free 模式运行的无 Cookie 第一方网站统计栈来说，答案是：一个按日范围限定的假名化签名，由访客的 IP、User-Agent、站点范围和一个每日轮换的盐组合派生而来，盐在当日结束时销毁。架构细节见 2026 年 EU 无同意网站统计实战手册。当日签名存在于原始事件表中，直到下一个 UTC 00:00 盐轮换；轮换之后，签名实际上变得不可逆，因为产生它的盐已经不存在。汇总表在盐轮换之前就把签名聚合成计数，因此按访客划分的标识符根本不在汇总表中 —— 表里只有每日、每个页面或每个来源的唯一访客计数。

对于已经同意的 consent-required 或 hybrid Statnive Live 部署，额外会向浏览器发出一个 Cookie ID（原始 UUID）。服务器以 h: 前缀存储 SHA-256(master_secret || site_id || cookieID) 作为持久化键。跨天的访客连续性由哈希后的 Cookie ID 维系，而非每日轮换的盐。

由此可以得出三点结论：

  • 第 15 条访问权。 数据主体需要向运营者提供可供查询的信息 —— 通常是浏览器中的 Cookie ID（如果当前会话中存在）或访问描述（日期、页面、大致时间、来自已知网络的 IP）。运营者可以返回匹配的事件。
  • 第 17 条删除权。 运营者可以定位到相同的事件并删除。运营者能识别到的记录，就是运营者能删除的记录。
  • 无法识别的数据无法删除 —— 但也不需要保留。 UTC 00:00 的每日盐销毁是一次同步执行、自动完成的跨天重识别能力清除。访客第 1 天会话的签名与第 2 天会话的签名在第 1 天的盐被销毁后即永久断开关联；运营者在第 2 天收到第 17 条请求时无法删除第 1 天的记录，因为已无法定位，但这不构成问题，因为它们也已不再可重识别。

架构的设计目标是让稳态下可识别数据的保留量很小。盐的轮换免费完成了 GDPR 第 5(1)(c) 条数据最小化的大部分工作。按此架构设计的网站统计栈所收到的 DSAR 请求，本质上比针对 CRM 的 DSAR 数量少得多 —— 一旦盐轮换，大多数访客根本没有留下按访客划分的记录。

三个端点

Statnive Live 默认上线三个隐私端点。三者均具备 CSRF 保护、速率限制，并输出结构化的审计事件。

POST /api/privacy/opt-out

第 21 条反对权端点。访客通过运营者隐私政策中的按钮调用该端点。服务器将退出选择登记为一个表达用户偏好的严格必要 Cookie（在 ePrivacy 第 25(2)(ii) 条 / TDDDG / 等效的国家法律转置下被允许，因为它实现了用户明确请求的服务偏好）。 之后来自同一浏览器的入站请求在 ingest 层就被丢弃，连访客签名都不会计算。

也可以通过服务器端的抑制列表，以访客哈希签名为键并设置足够的 TTL 来持久化退出选择 —— 由运营者自行配置。

该端点输出 privacy.opt_out_received 审计事件，包含时间戳、站点 ID 以及访客签名的哈希，便于与审计日志交叉对照。

GET /api/privacy/access

第 15 条访问权端点。访客提供：

  • 当前存储在浏览器中的 Cookie ID（如果有的话），或
  • 一个签名的预共享标识符（适用于将自有 DSAR 门户与 Statnive 集成的运营者），或
  • 一个访问描述，范围足够窄以便运营者定位（日期、页面、大致时间、来源网络）。

端点返回在档的事件。响应是一个 JSON 对象，包含与查询匹配的原始事件，以及涉及该访客的汇总派生元数据（其访问贡献到哪些汇总桶，但不披露同一桶中其他访客的信息）。审计事件：privacy.dsar_access_requested。

POST /api/privacy/erase

第 17 条删除权端点。查询方式与第 15 条相同。该端点通过 ClickHouse 的 system.tables 内省动态枚举存储后端的表 —— 然后从每张包含 visitor_signature 或 cookie_id_hash 列的表中删除匹配行。动态枚举是有意为之：未来若添加新表却携带访客标识符但未加入删除路径，集成测试会失败关闭，因为该测试会断言动态枚举覆盖了 schema 已知的每一张表。

聚合汇总表不会被删除。原因 —— 且这是 GDPR 框架下正确的原因 —— 在下一节说明。审计事件：privacy.dsar_erase_requested。

三个端点均拒绝未签名的跨源请求，需要从运营者会话派生的 CSRF 令牌，并按 IP 和按 (IP, site_id) 元组进行速率限制以防止滥用。审计日志独立于网站统计数据库，按运营者的审计日志保留政策保留 —— 通常比 25 个月的网站统计汇总窗口更长。

汇总表为何能在删除请求后保留 —— 以及为何这样做是正确的

网站统计 DSAR 设计中最反直觉的部分，是聚合汇总表在第 17 条删除请求后依然存活。第一反应通常是：如果用户要求被删除，那么所有关于他的数据都得删，包括他贡献的计数？

答案取决于汇总表实际包含什么内容。hourly_visitors 表中的一行记录的是例如：site_id=X, hour=Y, unique_visitors=4271。这一行不包含访客签名、访客 IP 或任何按访客划分的标识符。它包含一个 uniqCombined64 HyperLogLog 草图 —— 一种概率数据结构，可以在不存储单个值的前提下给出准确的基数估算。uniqCombined64 草图是计数，不是关于谁的记录。访客对计数的贡献无法从草图中反推出来。

这是 EDPB 关于聚合数据的标准立场：一旦数据被聚合到无法识别的程度 —— 即任何单个贡献都无法重建的程度 —— 它就不再是个人数据。 CNIL 第 16 号建议指南中要求聚合至最接近 10 的取整，依据的也是同一原则。意大利 Garante 在 Caffeina Media 决定中的匿名化分析，关键也在于重识别是否合理可能；对于源自 HyperLogLog 草图的聚合计数而言，并不合理可能。

实务效果是：第 17 条删除请求会删除原始事件行（携带按访客划分的签名、由 IP 派生的地理定位、仅保留主机的引荐来源、页面），但保留汇总表。运营者的仪表盘继续显示该页面的历史流量，但仪表盘中的任何一行都无法追溯回提出删除请求的数据主体。

这在运营者的隐私政策中描述为：「已聚合到无法识别的程度」。这是恰当的措辞 —— 既没有过度声称「匿名」，也没有低估为「仍属于个人数据」。汇总表是 GDPR 框架下网站统计保留的正确稳态。

25 个月的汇总 TTL 上限（750 天，通过 011_rollup_ttl.sql 迁移设置）始终适用。即便是聚合计数，也会按 CNIL 第 16 号指南的时间线自动过期。

审计追踪 —— 8 个隐私事件

Statnive Live 输出 8 个结构化的审计事件，覆盖隐私与法律相关的表面。这些事件是 GDPR 第 28(3)(h) 条要求的问责证据，可供运营者的 DPO、控制者的审计师或数据保护机构审查：

事件触发用途
privacy.opt_out_receivedPOST /api/privacy/opt-out已登记第 21 条反对
privacy.dsar_access_requestedGET /api/privacy/access已发起第 15 条请求
privacy.dsar_erase_requestedPOST /api/privacy/erase已发起第 17 条请求
privacy.consent_givenstatnive.acceptConsent()在 consent-required / hybrid 模式下授予同意
privacy.consent_withdrawnstatnive.withdrawConsent()撤回同意
legal.lia_viewedGET /legal/lia已展示运营者的 LIA 页面
legal.dpa_viewedGET /legal/dpa已展示第 28 条 DPA 页面
legal.privacy_policy_viewedGET /legal/privacy-policy/{lang}已展示隐私政策页面

每个事件都是结构化 JSON，包含时间戳、站点 ID、请求 ID 以及相关指纹。审计日志独立于网站统计数据库 —— 不会汇总，不会按 25 个月的统计 TTL 过期，按运营者的审计日志政策保留（通常更长，合规证据用途下常常是无限期保留）。

审计追踪是运营者面对监管机构检查时提交的材料。隐私政策是公开的立场；审计事件则是该立场确实得到实施的同步证据。CNIL 检查响应包通常包括：（a）LIA，（b）隐私政策，（c）检查窗口内的审计日志，（d）事件审计端点输出（法国部署的 3 事件上限检查）。Statnive Live 开箱即用地输出全部四项。

面向运营者的 DSAR 操作手册

处理针对 Statnive Live 部署的 DSAR 的可运行操作手册：

步骤 1：识别请求。 数据主体一般通过邮件联系控制者已公布的 DSAR 地址。请求必须具体到运营者能够定位数据 —— 通常意味着访客浏览器中当前的 Cookie ID（访客可通过 DevTools 查看）或一段足以识别事件窗口的访问描述。

步骤 2：核验请求者身份。 GDPR 第 12(6) 条允许控制者在合理必要时额外要求身份证明以核验数据主体身份。对于网站统计请求，证明形式通常是：对 Cookie ID 的控制（访客提交 DevTools 显示 Cookie 的截图），或对访问 IP 的控制（来自同一 IP 的已认证登录，或回调质询）。运营者不应要求超出核验请求所必需的身份证明。

步骤 3：运行访问查询。 运营者调用 GET /api/privacy/access 并传入查询标识符。响应是匹配的事件。如果是第 15 条访问请求，这就是返回给数据主体的内容 —— 按运营者 DSAR 门户的偏好格式化为 CSV、JSON 或 PDF。

步骤 4：运行删除（如有请求）。 运营者使用相同的查询标识符调用 POST /api/privacy/erase。该端点会从每张包含访客标识符的表中删除匹配行；汇总表保持不变（参见上一节）。端点返回每张表删除的行数。

步骤 5：向数据主体确认。 GDPR 第 12(3) 条允许最多一个月响应，复杂请求可再延长两个月。运营者的响应应当：

  • 确认数据已定位，且（如果请求了删除）已删除。
  • 说明保留了什么 —— 汇总聚合 —— 以及为什么它们不属于个人数据。
  • 说明运营者的审计日志保留情况（DSAR 请求本身已被记录的事实）。

步骤 6：将响应记入审计日志。 当运营者调用 API 端点时，Statnive Live 的审计事件已自动输出。运营者还应在更广泛的 DSAR 处理系统（通常是客服系统或 DPMS）中记录发送给数据主体的响应。

整个操作手册可以用半页清单概括。大多数首次实施时担心网站统计 DSAR 会很难，但实际上架构的设计让数据要么存在于一个小而明确的窗口内，要么根本不存在。请求量低、查询有界、响应形式标准化。

一个可运行的集成示例

对于希望将自有 DSAR 门户与 Statnive Live 集成的运营者，下列模式可端到端工作：

// Triggered from a DSAR portal after identity verification
async function handleAccessRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/access?site_id=${SITE_ID}&cookie_id=${verifiedRequest.cookieId}`,
    {
      method: 'GET',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
      },
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR access failed: ${response.status}`);
  }
  const { events, rollup_metadata } = await response.json();
  return { events, rollup_metadata };
}

async function handleErasureRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/erase`,
    {
      method: 'POST',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        site_id: SITE_ID,
        cookie_id: verifiedRequest.cookieId,
      }),
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR erasure failed: ${response.status}`);
  }
  const { rows_deleted_by_table } = await response.json();
  return { rows_deleted_by_table };
}

运营者密钥按运营者的密钥轮换政策定期轮换。CSRF 令牌作为标准 Statnive Live 管理认证流程的一部分，由运营者会话派生。

自托管部署带来的差异

对于将 Statnive Live 作为自托管部署运行 —— 即在运营者自有基础设施上运行二进制文件 —— 控制者与处理者的分析会发生变化。Statnive 完全不是运营者网站统计数据的处理者；运营者是唯一的控制者。没有 Statnive ↔ 运营者的 DPA 需要签署，因为没有 Statnive 作为处理者的对象。

DSAR 端点在自托管二进制文件上与在托管的 Statnive Live SaaS 部署中的工作方式完全相同。审计事件输出到运营者选择的日志接收端（容器化部署中的 stdout / stderr、传统主机上的 syslog，或自托管环境中的专用审计表）。上面的集成示例对运营者的自有端点同样适用。

不同之处在于：控制者对第三方数据主体的第 15 条请求的响应，仅是控制者的响应。没有 Statnive 子处理者参与协助；运营者的 IT 团队就是运营者的 DSAR 响应方。

这是自托管与私有 EU SaaS 对比文章中讨论的取舍之一。对于严格要求第三方不触及数据的运营者（受监管行业、气隙环境），自托管是最清晰的答案；对于严格要求签署处理者协议的运营者（ISO 27001 供应商问卷、大型采购），带有第 28 条 DPA 的 SaaS 是最清晰的答案。DSAR 架构在两种形态下的运作方式相同。

这给运营者带来什么

实际成果：

  • 一份干净的 DSAR 响应包，可应对针对网站统计层的任何第 15 / 17 条请求。三个端点、八个审计事件、一份操作手册和一段集成示例。
  • 可辩护的汇总保留答复。 「已聚合到无法识别的程度」的措辞与 EDPB 的立场一致；25 个月的汇总 TTL 始终适用。
  • 一条问责追踪，对应到处理者关系下第 28(3)(h) 条的审计协助义务，以及控制者自身记录下第 5(2) 条的更广泛问责原则。
  • 向前兼容性对接 Digital Omnibus 第 88a 条对数据主体权利的预期。当前文本不改变第 15 条和第 17 条的实质义务；DSAR 端点无需变更。

它不提供：超过 25 个月汇总窗口保留原始按访客数据的方法，因为盐销毁让这不可能；「撤销」删除请求的方法，因为删除不可逆；为「内部」请求跳过审计日志的方法，因为不存在内部请求 —— 三个端点的每一次调用都会输出事件。

该做什么，不该做什么

该做不该做
把哈希后的访客标识符视为低风险个人数据；对其履行第 15、17、21 条义务。把哈希后的标识符宣传为「匿名」 —— 法律上正确的用词是「假名化」；2025 年 5 月 14 日的布鲁塞尔法院判决再次确认。
接入三个隐私端点（/api/privacy/opt-out、/api/privacy/access、/api/privacy/erase），配以 CSRF 保护、速率限制和审计日志。构建绕过审计日志的一次性 DSAR 处理器 —— 第 28(3)(h) 条问责正是检查时所需的证据包。
把第 17 条下汇总表的保留描述为「已聚合到无法识别的程度」 —— 既不过度声称「匿名」，也不低估为「个人数据」。因第 17 条请求而删除汇总表行 —— 它们是聚合计数，不是按访客记录；这样做不会带来 GDPR 上的好处，反而失去历史流量可见性。
在执行访问 / 删除查询前，按 GDPR 第 12(6) 条核验请求者身份 —— 通常通过对 Cookie ID 的控制或回调质询。要求超出必要的身份证明；EDPB 01/2022 关于访问权的指南明确指出过度要求会损害权利。
记录操作手册并记录每一个隐私审计事件 —— EDPB 2025 CEF 重点是删除权，EDPB 2026 CEF 重点是透明度。把 DSAR 处理当作一次性运维工作 —— 协调的 DPA 执法正在持续进行，同步审计追踪才是正确答案。

结论

GDPR 第 15 条和第 17 条下的访问权与删除权同样适用于网站统计。EDPB 指南 01/2025、CJEU Breyer 与 IAB Europe 判决以及各国监管机构一致的立场都如此声明。架构决策是如何应对 —— 答案是：让按访客数据窗口变小（每日盐轮换），让汇总窗口有界（25 个月 TTL），暴露三个端点（退出、访问、删除），输出八个审计事件，并在隐私政策中说明立场。

Statnive Live 默认上线这一表面。运营者基于此进行集成；审计日志捕获同步证据；汇总表在删除请求后依然保留，因为它们已经聚合到不可识别。当 DSAR 真正到来时，过程是程序性的 —— 一个月时钟、一步核验、一次 API 调用、一封确认邮件 —— 而非架构层面的波折。

更广的隐私框架请参见 2026 年 EU 无同意网站统计实战手册。每日盐轮换为何使架构本质上最小化，请参见 country-by-country 总表。同一批审计事件如何驱动 GPC 与混合模式集成，请参见对应文章。DSAR 表面是贯穿这四篇内容的纽带。

本文为隐私研究内容，不构成法律意见。 文中描述的 DSAR 端点是技术可用性特性。对第 15 / 17 / 21 条请求的法律正确响应是控制者在 GDPR 第 12 条及相关国家立法下的责任。每位 Statnive 客户仍是数据控制者，自行负责其配置和 DPIA。在发布前请与所在司法辖区的合资格法律顾问交叉确认。

监管参考的状态截至 2026 年 5 月 13 日：GDPR 第 12、15、17、21、28(3)(e)、28(3)(h) 和 33 条；EDPB 关于访问权的指南 01/2022（最终版于 2023 年 3 月通过）；CJEU C-582/14 Breyer，2016 年 10 月 19 日（ECLI:EU:C:2016:779）；CJEU C-604/22 IAB Europe，2024 年 3 月 7 日；布鲁塞尔上诉法院 2025 年 5 月 14 日判决，案号 2022/AR/292（确认 IAB Europe / TC 字符串路线）；草案 EDPB 关于假名化的指南 01/2025（2025 年 1 月 16 日第 101 次全会通过草案；公众咨询期至 2025 年 2 月 28 日；截至 2026 年 5 月仍未发布最终版；EDPB 冲刺小组目标 2026 年夏季完成）；EDPB 2024 年 10 月 8 日的关于合法利益的指南 1/2024；EDPB 2025 协调执法框架重点：删除权（第 17 条）；EDPB 2026 协调执法框架重点：透明度与告知义务（第 13/14 条）；ePrivacy 指令 2002/58/EC（生效中）及其成员国转置，包括 § 25 TDDDG（德国）和 Loi 78-17 第 82 条（法国）。

免费获取 Statnive