身份解析详解：如何跨设备和浏览器追踪用户

同一个用户可能在火车上用手机、在工作时用笔记本、在沙发上用平板访问你的站点。每一种情形下，你的分析看到的都是一个不同的访客。身份解析就是识别出这三个访客其实是同一个人的过程。没有它，你的分析会高估用户数、你的漏斗会在跨设备时断裂，而你的 CRM 会给同一个人发出三封不同的引导邮件。

本文解释身份解析的两种主要方法——基于声明与基于图谱——Gurulu 如何同时实现这两者，以及你需要牢记的隐私考量。无论你是在构建一套自定义身份系统，还是在评估各类分析平台，理解这些基础都将为你省下数月的工作。

基于声明 vs. 基于图谱的身份

基于声明的身份解析，通过从用户交互中收集显式标识符——即声明——来运作。当用户用邮箱登录时，那个邮箱就是一条声明。当他们验证一个电话号码时，那是另一条声明。每条声明都附着到它被观察到的那个会话上。如果两个会话共享同一条声明（例如同一个邮箱），它们就被合并为一个身份。这种方法是确定性的：它只在存在可证明的关联时才合并会话。

基于图的身份识别会构建一个标识符之间的关系网络。它不依赖简单的两两匹配，而是构建一张图，其中节点是标识符（电子邮件、电话号码、设备 ID、Cookie），边表示共同出现的关系。基于图的系统能够解析传递性关系：如果会话 A 与会话 B 共享一个电子邮件，而会话 B 又与会话 C 共享一个电话号码，那么这三个会话都属于同一个人。其代价是复杂度——图识别需要精细调优，以避免因共享设备或被回收的标识符而把不相关的用户错误地关联在一起。

确定性匹配 vs. 概率性匹配

确定性匹配要求在某个稳定标识符上完全一致——相同的电子邮件、相同的用户 ID、相同的电话号码。它准确度极高，但覆盖范围有限：只有当用户主动提供识别信息时才有效。概率性匹配则使用统计模型，从 IP 地址、浏览器指纹、屏幕分辨率和行为模式等较弱的信号中推断身份。它覆盖更广，但会引入误报风险。Gurulu 将确定性匹配作为主要的识别策略，概率性信号仅用于单个浏览器上下文内的会话拼接——绝不用于跨设备合并。

为什么确定性匹配在分析中更胜一筹。 身份图中的错误合并会污染下游的每一项指标。如果两个不相关的用户被合并，他们叠加的会话历史会扭曲漏斗、虚增参与度指标，并扰乱你的 CRM。确定性匹配只在证据确凿时才合并，从而彻底避免了这一问题。

什么时候概率性匹配可以接受。 对于单个浏览器内的匿名会话拼接——即识别出昨天和今天来访的用户是同一个人——概率性模型是安全的。误报代价很低（会话计数略有偏差），而覆盖率的提升却相当可观。

Gurulu 的 6 种声明类型

Gurulu 的身份系统围绕六种声明类型构建。每条声明都是一份证据，将某个会话与一个规范身份关联起来。当系统在多个会话之间发现重叠的声明时，便会将它们合并。

• user_id —— 你应用的内部用户标识符。这是最强的声明，因为它唯一且稳定。通过 gurulu.identify() 设置。
• email —— 电子邮件地址，已规范化为小写。在用户注册、登录或提交包含邮箱字段的表单时采集。
• phone —— E.164 格式的电话号码。适用于移动优先的产品和双因素认证流程。
• oauth_id —— OAuth 提供方加上外部 ID（例如 google:118234567890）。在用户通过社交登录认证时自动采集。
• session_token —— 服务端会话标识符。当用户在会话中途登录时，将匿名浏览与已认证状态关联起来。
• device_fingerprint —— 一种隐私安全的设备哈希，由视口、语言和时区派生而来。绝不用于跨设备合并，仅用于同一设备上的会话连续性。

identify() 调用

向 Gurulu 身份系统输入声明的主要方式是 identify() API 调用。当用户在你的应用中完成认证时，你会带上其用户 ID 和任意附加属性调用 identify()。这会创建一条 user_id 声明，并可选地创建 email 和 phone 声明，从而将当前匿名会话与一个已知身份关联起来。

// Deterministic identity: link anonymous session to known user
gurulu.identify('user_12345', {
  email: 'jane@example.com',
  phone: '+1-555-0123',
  name: 'Jane Doe',
});

// The SDK sends a claim of type "user_id"
// Server-side, Gurulu merges all sessions with
// matching email, phone, or user_id into one
// canonical identity node.

一旦调用了 identify()，当前会话中此前所有的匿名事件都会被追溯归属到所识别出的身份上。如果此邮箱或用户 ID 此前曾在另一个会话中出现过——在另一台设备或浏览器上——这些会话便会合并为一个规范画像。这正是跨设备身份识别在实践中的运作方式：用户在手机上登录后，他们的桌面浏览历史会突然出现在同一个画像中。

跨浏览器合并示例

设想这样一个场景：某用户用笔记本电脑上的 Chrome 访问你的网站，浏览了三个产品页面。第二天，他们用手机上的 Safari 访问并用邮箱注册。第三天，他们回到笔记本上的 Chrome 并登录。此时，Gurulu 拥有跨两台设备、两个浏览器的三个会话。当用户在第三天登录时，identify() 调用会创建一条 user_id 声明。系统发现该 user_id 与手机会话中的邮箱相匹配（因为注册同时创建了这两条声明）。三个会话——Chrome 匿名、Safari 注册和 Chrome 登录——合并为一个具有完整跨设备时间线的规范身份。

这一合并是即时且可追溯的。该用户在你 CRM 中的画像如今展示出完整的旅程：匿名浏览、注册和回访。跨设备的漏斗能正确运作，归因模型也能将转化追溯回第一天将该用户带到你网站的原始流量来源。

隐私方面的考量

身份识别本质上涉及跨会话和跨设备地关联用户数据，这会带来隐私影响。Gurulu 的方案在每一层都设计为尊重用户同意。只有当用户主动提供信息时才会采集声明——登录、提交表单或完成认证。不使用任何被动指纹识别或跨站跟踪。身份图的作用域仅限于你的网站；Gurulu 客户之间不存在数据共享。所有声明都以伪名化哈希而非明文存储，因此即便数据库遭到泄露，也不会暴露用户的邮箱或电话号码。

对于在 GDPR、KVKK 或类似框架下运营的组织，Gurulu 支持对身份识别进行同意级别的门控。你可以将系统配置为仅对已授予分析级同意的用户进行身份识别，同时仍为未授予同意的用户采集聚合指标。这让你兼得两者之利：对已同意用户进行精确的身份识别，对其余所有人采集合规的聚合数据。