符合 GDPR 与 KVKK 的分析：开发者的同意管理指南

隐私法规正在不断增多。GDPR 覆盖欧盟，KVKK 覆盖土耳其，CCPA 覆盖加州，LGPD 覆盖巴西，而新的框架每年都在出现。对于构建分析的开发者而言，问题不在于是否要合规——而在于如何在不破坏数据质量的前提下合规。答案在于一个分层的同意模型，它能根据用户的隐私偏好来调整数据采集。

本指南涵盖法律全景、Gurulu 的 4 级同意模型、技术实现，以及让你的分析技术栈在不丢失所依赖洞察的前提下实现合规的实操步骤。

法律要求概览

GDPR 和 KVKK 共享一条共同原则：没有合法依据就不得处理个人数据。对于分析而言，两个相关的依据是同意（用户明确同意）和正当利益（数据处理对于某个不凌驾于用户权利之上的目的而言是必要的）。其中的难点在于，构成个人数据的范围比大多数开发者设想的要广。IP 地址、设备标识符、Cookie，乃至行为模式，只要能与某个个人关联起来，都可能被认定为个人数据。

由此带来的实际意义是：如果你的分析工具使用 Cookie、存储 IP 地址或创建持久化标识符，那么在欧盟和土耳其采集数据之前就需要获得同意。如果你的工具完全不做这些——就像 Gurulu 默认的无 Cookie 模式——你便可以主张未处理任何个人数据，基础分析无需同意。但一旦你启用了带 PII 的身份识别，同意就重新成为必要。

4 级同意模型

Gurulu 实现了一个 4 级同意模型，让你能随着用户授予更广泛的同意而逐步采集更多数据。每一级都是前一级的超集：

第 0 级：匿名 —— 仅聚合指标。页面浏览和事件会被计数，但不与任何会话或身份关联。不处理任何个人数据。该级别在任何框架下都无需同意。
第 1 级：功能性 —— 启用会话跟踪。事件会通过服务端启发式方法（时序、导航模式）归入会话，但不创建任何持久化身份。会话数据在 24 小时后删除。通常可由正当利益涵盖。
第 2 级：分析 —— 带伪名化身份的完整事件跟踪。identify() API 处于激活状态，会话会跨访问关联，身份图随之构建。所有标识符都以加盐哈希存储。在 GDPR 和 KVKK 下需要明确的分析同意。
第 3 级：营销 —— 启用跨站跟踪、广告归因和第三方数据共享。UTM 参数、广告点击 ID 和引荐链路会被存储并关联到身份画像。需要明确的营销同意。

关键洞见在于：有用的分析并不需要最高的同意级别。大多数产品团队在第 1 级（功能性）就能回答其关键问题，而该级别通常无需同意横幅。第 2 级和第 3 级则为已具备同意基础设施的团队提供更丰富的数据。

SDK 集成

将同意集成进 Gurulu SDK 只需寥寥几行代码。你在初始化时设置一个默认同意级别，并在用户通过你的同意界面做出选择时更新它。

// Initialize Gurulu with consent awareness
gurulu.init({
  siteId: 'YOUR_SITE_ID',
  consent: {
    default: 'anonymous',  // Level 0: aggregate only
    // Consent levels:
    // 'anonymous'    → aggregate metrics, no identity
    // 'functional'   → session tracking, no PII
    // 'analytics'    → full event tracking, pseudonymized
    // 'marketing'    → cross-site, ad attribution
  }
});

// Update consent when user makes a choice
gurulu.setConsent('analytics');

// Or revoke consent
gurulu.setConsent('anonymous');

同意状态持久化在服务端，而非 Cookie 中。当用户再次到访时，Gurulu 会检查所存储的同意级别并应用相应的数据采集规则。如果同意被撤回，系统会立即停止在被撤回级别上采集数据，并可选地删除此前为该用户采集的数据。

伪名化身份图

在第 2 级（分析同意）下，Gurulu 使用伪名化标识符构建身份图。电子邮件以带站点专属盐的 SHA-256 哈希存储。电话号码规范化为 E.164 格式后以相同方式哈希。用户 ID 则原样存储，因为它们本就是由你的应用控制的不透明标识符。

这种伪名化意味着，即便身份图数据库遭到入侵，攻击者也无法提取出电子邮件地址或电话号码。这些哈希是单向且站点专属的，因此来自其他泄露事件的彩虹表毫无用处。就 GDPR 而言，伪名化数据仍属于个人数据，但它显著降低了泄露的影响，并体现了对数据最小化原则的遵循。

身份图支持被遗忘权请求。当用户依据 GDPR 第 17 条请求删除时，API 会移除该规范身份对应的所有身份节点、声明和关联的事件数据。删除会传播到所有已合并的会话，确保彻底移除。

实操实施步骤

第 1 步：审计你当前的跟踪。 在实施同意管理之前，先弄清你的分析当前采集了哪些数据。如果你以无 Cookie 模式使用 Gurulu 且没有任何 identify() 调用，那你很可能已处于第 0–1 级，或许根本不需要同意横幅。

第 2 步：选择你的默认级别。 将 SDK 默认值设为无需同意即可提供有用数据的最低级别。对大多数网站而言，这是 “anonymous” 或 “functional”。更高级别仅在用户同意时才激活。

第 3 步：实现你的同意界面。 构建或集成一个同意横幅，说明每个级别启用了什么。当用户做出选择时，带上相应级别调用 gurulu.setConsent()。其余的交由 SDK 处理：激活或停用功能、更新服务端同意记录，并实时调整数据采集。

第 4 步：处理同意的变更。 用户可能会改变主意。你的同意界面应允许用户随时撤回同意，而 SDK 应立即响应。Gurulu 的 setConsent() 调用是幂等的，并在当前会话内生效。

归根结底

同意管理不是勾选复选框的形式工作。它是你分析架构中的根本组成部分，决定了你能采集哪些数据、能保留多久，以及能用它做什么。一个实现得当的同意模型，能在尊重用户偏好的同时，让你获得法律允许范围内的最大数据量。

Gurulu 的 4 级模型通过将数据采集与同意要求解耦，使这一切变得切实可行。你无需在合规与分析质量之间二选一——你可以兼得二者，并按每位用户所授予的同意进行伸缩。