fangke/docs/跨天用户轨迹与身份解析实施方案.md

# 跨天用户轨迹与身份解析实施方案

> 适用项目：自研多语言静态网站 CMS、客户数据与运营智能系统  
> 文档版本：V1.0  
> 日期：2026-09-11

---

## 1. 目标定义

系统要记录的不是孤立的 PV，而是一条可以跨会话、跨日期、在确定条件下跨设备延续的客户旅程。

例如：

```text
9 月 1 日
Google 自然搜索 → 英文产品页 → 查看案例 → 离开

9 月 2 日
直接访问 → 价格页 → 点击咨询按钮 → 未提交

9 月 7 日
邮件活动链接 → 德文白皮书页 → 下载资料 → 提交邮箱

识别发生后
将前三次经过合法授权的匿名访问关联到同一 Person

9 月 10 日
再次访问集成文档和价格页 → 意向分数上升 → 生成销售跟进任务
```

运营和销售最终看到：

- 首次从哪里来；
- 每次在什么时间访问；
- 使用哪种语言、设备和渠道；
- 看过哪些页面与内容；
- 点击、下载、站内搜索和表单行为；
- 哪一次成为已识别联系人；
- 哪些行为构成高意向；
- 哪次内容发布、活动或销售动作影响了后续行为；
- 用户当前 consent 状态和哪些行为可以被使用。

“记录所有轨迹”在产品上应定义为：**在明确业务目的、合法处理基础和最小必要范围内，尽量完整记录预先定义的客户行为，不记录密码、表单原文、敏感输入、键盘内容或无业务价值的数据。**

---

## 2. 核心设计思想

### 2.1 事件永久记录，画像动态计算

- 原始行为按事件追加，不能直接覆盖；
- Session、Person、Account、意向分数是派生结果；
- 身份规则变化后可以重算；
- 错误合并可以拆分；
- 删除请求可以沿身份关系传播。

### 2.2 匿名先于实名

第一次访问通常不知道用户是谁。系统先建立假名化的匿名访客身份，用户后来登录、验证邮箱或提交表单后，再建立确定性身份关联。

### 2.3 确定性信号优先

以下信号可作为确定性证据：

- 已登录账号的内部用户 ID；
- 由服务端验证成功的表单联系人 ID；
- 用户点击的单人、限时、签名验证链接；
- CRM 已验证联系人与登录账号的绑定；
- 用户主动输入并经验证的邮箱或手机号。

以下信号不能单独作为“同一个人”的确定性证据：

- IP 地址相同；
- 浏览器和设备特征相似；
- 公司网络出口相同；
- 地理位置相似；
- 浏览内容相似。

这些弱信号最多用于“候选账户”或聚合分析，不用于自动合并 Person。

### 2.4 轨迹与隐私同一套架构

Consent 不是页面上的独立弹窗，而是采集管道的一部分。每个事件都必须知道它在什么 consent 状态和用途下被采集。

中国《个人信息保护法》要求处理具有明确、合理目的，与目的直接相关，并采取对个人权益影响最小的方式，收集范围不得超过实现目的所必需的范围。[国家市场监督管理总局：《个人信息保护法》](https://www.samr.gov.cn/wljys/gzzd/art/2023/art_3ef1e889c1e644d4b65b5f5c7f432386.html)

对欧洲用户，EDPB 说明：除技术必要 Cookie 外，在终端设备存取 Cookie 通常应在充分告知目的并取得同意后进行；假名化数据仍属于个人数据。[EDPB Cookie 与假名化说明](https://www.edpb.europa.eu/contact/frequently-asked-questions_en)

因此本方案是技术产品设计，不替代针对实际经营国家、行业和数据流向的法律评估。

---

## 3. 四级身份模型

```text
Session
一次连续访问过程
    │ many-to-one
    ▼
Anonymous Profile
同一浏览器中跨天延续的假名化访客
    │ deterministic link
    ▼
Person
已确认的自然人/联系人
    │ membership/relationship
    ▼
Account
企业、客户组织或家庭等业务账户
```

### 3.1 `session_id`

- 表示一次访问会话；
- 首次事件产生；
- 连续无活动超过约定时间后产生新 Session；
- 推荐以 30 分钟不活动作为默认值，但做成站点级配置；
- 跨午夜不必强制断开，按实际活动间隔切分；
- 一个匿名访客可以拥有多个 Session。

### 3.2 `anonymous_id`

- 128 位以上加密安全随机值，不包含邮箱、IP 或设备信息；
- 在允许设置分析标识的条件下，由第一方域名签发；
- 同一浏览器次日再来时继续携带，因此实现跨天串联；
- 清除 Cookie、拒绝分析同意、无痕模式或更换浏览器后可能产生新 ID；
- 生命周期由区域政策和 consent 决定；
- 不是“匿名化数据”，而是假名化标识，仍按个人数据保护。

### 3.3 `person_id`

- 自有系统内部不可变 ID；
- 不直接使用 email 作为主键；
- PII 加密存入独立 Profile Vault；
- 行为仓库只使用 `person_id`；
- 一个 Person 可关联多个 anonymous_id 和设备；
- 每条关联都必须保存证据。

### 3.4 `account_id`

- B2B 场景中的公司或组织 ID；
- Person 与 Account 使用独立关系表，可表示职位、状态、来源和有效期；
- 企业邮箱域名只能创建候选关系，必要时经 CRM 或人工确认；
- 共享公司出口 IP 不能证明某个自然人的身份。

---

## 4. 跨天识别流程

### 4.1 第一次访问

```text
请求页面
  ↓
根据地区/站点策略显示 Consent
  ↓
未同意：只保留提供页面所必要的数据，或使用内存级短期会话
已同意分析：第一方 Event Gateway 签发 anonymous_id
  ↓
创建 session_id
  ↓
记录 page_view、来源和内容上下文
```

推荐由第一方 Event Gateway 通过安全 Cookie 签发随机 ID：

- `Secure`；
- 生产环境仅 HTTPS；
- 合理的 `SameSite`；
- 能使用 `HttpOnly` 时由浏览器自动随第一方采集请求发送，SDK 不读取值；
- Cookie 名称不包含用户身份；
- 不把 ID 暴露在 URL 参数中。

### 4.2 第二天再次访问

```text
浏览器携带同一 anonymous_id
  ↓
Event Gateway 识别已有 Anonymous Profile
  ↓
因不活动时间已超过阈值，创建新 session_id
  ↓
新事件追加到同一个 Anonymous Timeline
```

因此第一天和第二天是两个 Session，但属于同一匿名访客轨迹。

### 4.3 表单提交后识别

```text
匿名用户提交表单
  ↓
浏览器只发送 form_id、anonymous_id/session 上下文
  ↓
表单服务端校验并保存 PII
  ↓
创建 lead_id / person_id
  ↓
Identity Engine 创建 anonymous_id → person_id 的确定性证据边
  ↓
历史 Session 作为此 Person 的可追溯历史显示
```

事件数据中不保存表单字段原文；事件只保存 `lead_id`、`form_id` 和成功状态。姓名、email、电话等进入权限更严格且加密的 Profile Vault。

### 4.4 跨设备识别

```text
设备 A：匿名访问 → 登录/已验证表单 → Person 123
设备 B：匿名访问 → 同一账号登录/验证链接 → Person 123
  ↓
两个 anonymous_id 都以独立证据关联 Person 123
```

没有登录、验证或其他确定性信号时，设备 A 与设备 B 保持为两个匿名档案，不使用指纹技术强行合并。

### 4.5 跨域问题

- 同一主域下的子域，可通过第一方 Cookie 和服务端策略统一；
- 不同顶级域之间不能默认共享 Cookie；
- 如业务必须跨域延续，应使用短期、签名、一次性的跳转令牌，并明确评估 consent 与安全风险；
- 不在 URL 中长期传播 anonymous_id；
- 多语言优先使用同一主域的 `/en/`、`/de/` 等路径，可减少身份、SEO 与运维复杂度。

---

## 5. 事件模型

### 5.1 标准事件信封

```json
{
  "event_id": "uuidv7",
  "event_name": "page_view",
  "event_version": 1,
  "occurred_at": "2026-09-11T08:15:22.381Z",
  "received_at": "2026-09-11T08:15:22.624Z",
  "tenant_id": "tenant_01",
  "site_id": "site_global",
  "anonymous_id": "anon_random_id",
  "session_id": "sess_random_id",
  "person_id": null,
  "account_id": null,
  "content_id": "content_product_a",
  "content_revision_id": "rev_42",
  "deployment_id": "deploy_20260911_0800",
  "locale": "de-DE",
  "page": {
    "url": "https://example.com/de/product-a",
    "canonical_url": "https://example.com/de/product-a",
    "title": "Product A"
  },
  "acquisition": {
    "referrer_host": "www.google.com",
    "utm_source": null,
    "utm_medium": null,
    "utm_campaign": null
  },
  "device": {
    "class": "mobile",
    "browser_family": "Chrome",
    "os_family": "Android"
  },
  "consent_snapshot_id": "consent_abc",
  "purpose": "analytics",
  "properties": {}
}
```

### 5.2 时间字段

- `occurred_at`：浏览器实际发生时间；
- `received_at`：服务器收到时间；
- 同时保存 UTC，展示时按站点或用户时区转换；
- 客户端时间异常时，以服务器时间降级并标记；
- 迟到事件允许进入原始层，再按窗口重算 Session 和指标。

### 5.3 核心事件目录

| 事件 | 关键属性 | 作用 |
|---|---|---|
| `session_start` | landing_page、referrer、campaign | 一次旅程入口 |
| `page_view` | content、locale、revision、deployment | 页面访问 |
| `content_engaged` | engaged_seconds、depth_bucket | 有效阅读 |
| `cta_click` | cta_id、placement、target_type | 转化意图 |
| `file_download` | asset_id、content_id | 资料兴趣 |
| `site_search` | query_token/category、result_count | 主动需求 |
| `video_progress` | asset_id、milestone | 内容消费 |
| `form_start` | form_id | 漏斗开始 |
| `form_validation_error` | form_id、field_key、error_code | 表单阻塞；不含字段值 |
| `form_submit_success` | form_id、lead_id | 服务端真实转化 |
| `form_submit_failed` | form_id、error_code | 技术失败 |
| `login_success` | auth_user_id | 确定性身份信号 |
| `consent_updated` | purposes、policy_version | 同意状态变化 |
| `outbound_click` | destination_host、link_id | 外部去向 |
| `experiment_exposure` | experiment_id、variant | 实验归因 |

### 5.4 不应采集

- 密码、验证码、银行卡、证件或健康信息；
- 用户在输入框中的逐字键入内容；
- 未脱敏的表单原文；
- URL 中的 email、电话、token 等敏感参数；
- 精确 GPS，除非有独立明确场景和授权；
- 长期保存的原始 IP；
- Canvas、字体、音频等隐蔽设备指纹；
- 页面 DOM 全量或未经屏蔽的会话回放；
- 与已声明运营目的无关的数据。

### 5.5 事件上下文与业务属性分离

所有事件自动带公共上下文；业务组件只提交最少属性。例如 CTA 组件只调用：

```text
track("cta_click", { cta_id, placement, target_type })
```

SDK 自动补充页面、语言、内容、发布、Session 和 consent，避免不同页面各自实现后产生口径不一致。

---

## 6. 身份关系数据模型

### 6.1 核心表

| 表 | 关键字段 | 作用 |
|---|---|---|
| `anonymous_profiles` | anonymous_id、created_at、last_seen_at、consent_state | 匿名访客档案 |
| `sessions` | session_id、anonymous_id、started_at、ended_at、entry、exit | 跨事件会话 |
| `persons` | person_id、status、created_at | 已识别联系人主对象 |
| `person_identifiers` | type、lookup_hash、encrypted_value、verified_at | email/手机号/账号标识 |
| `identity_links` | source_id、target_id、evidence_type、confidence、rule_version | 可审计身份边 |
| `accounts` | account_id、name、domain、status | 企业账户 |
| `account_memberships` | person_id、account_id、role、valid_from、valid_to | 人与企业关系 |
| `consent_records` | subject_id、purpose、state、policy_version、proof | 同意记录 |
| `journey_touchpoints` | event/session、channel、campaign、content | 不可变触点 |
| `identity_operations` | merge/split/delete、actor、reason、snapshot | 合并拆分审计 |

### 6.2 PII 查找方式

为支持按 email 查找并避免行为仓库出现明文：

```text
规范化 email
  ↓
使用租户级密钥计算 HMAC lookup_hash
  ↓
以 lookup_hash 查询是否已存在 Person
  ↓
明文/可逆值使用独立密钥加密保存到 Profile Vault
```

普通 SHA-256(email) 不足以防字典枚举，应使用带秘密密钥的 HMAC；即使是假名化结果，也按个人数据管理。

### 6.3 身份证据边

每条 `identity_link` 至少保存：

- 左右对象 ID；
- 证据类型；
- 证据来源；
- 建立时间；
- 规则版本；
- 确定性或推测性；
- 置信度；
- 当前状态；
- 创建者（系统/用户/管理员）；
- 撤销原因。

合并不是把旧 ID 删除，而是建立有证据的关系并计算当前视图。

---

## 7. 身份合并与拆分规则

### 7.1 自动合并规则

允许自动合并：

- 同一内部账号成功登录；
- 同一已验证邮箱产生的联系人；
- 服务器验证通过的一次性个人链接；
- 明确业务规则下，同一 CRM contact_id。

需要人工审核或只作为候选：

- 相同企业域名；
- 相同公司 IP；
- 相同姓名和公司；
- 相同设备特征；
- 数据供应商推测。

禁止合并：

- 仅因为 IP 相同；
- 仅因为访问路径相似；
- 仅因为地理位置相近；
- 证据已过期或冲突；
- consent 不允许该处理用途。

### 7.2 共享设备处理

家庭电脑、展会平板和公司共享设备可能被多人使用：

- 登录只把明确登录前、同一浏览器且符合规则的历史窗口作为候选；
- 退出登录后可轮换匿名 ID，防止后续用户继续挂到前一个 Person；
- 若同一匿名 ID 先后出现两个冲突的已验证 Person，不自动把两人合并；
- 生成冲突事件，拆分会话并交由规则或人工处理。

### 7.3 错误合并拆分

```text
选择错误 Identity Link
  ↓
冻结相关画像计算
  ↓
撤销关系边并记录原因
  ↓
重算 Session → Person → Account 归属
  ↓
重算归因、意向分数和受影响报表
  ↓
更新或撤销错误销售任务
```

---

## 8. 客户旅程时间线

### 8.1 时间线视图

运营或销售打开一个 Person 后看到：

```text
首次接触        9/01 10:21  Google 自然搜索 / 英文站
Session 1       产品页 → 案例页                           6 分钟

再次访问        9/02 16:08  Direct / 移动端
Session 2       价格页 → CTA 点击 → 表单开始未提交        4 分钟

活动回访        9/07 09:43  Email / campaign_autumn
Session 3       德文白皮书 → 下载 → 表单成功              8 分钟
身份识别        9/07 09:49  anonymous_id ↔ Person 123

高意向回访      9/10 14:32  Email / 桌面端
Session 4       集成文档 → 价格页 → 联系销售              12 分钟
系统动作        意向分数 42 → 78，创建销售跟进任务
```

### 8.2 时间线筛选

- 日期范围；
- 匿名/已识别阶段；
- 渠道和活动；
- 内容主题和页面；
- 语言和国家；
- 设备；
- 高意向事件；
- 转化与销售动作；
- consent 允许的用途。

### 8.3 轨迹摘要

系统自动形成可解释摘要：

- 首次接触渠道；
- 最近接触渠道；
- 总访问天数和 Session 数；
- 最近 7/30/90 天活跃度；
- 最常阅读的主题；
- 主要语言和地区；
- 关键转化与最后转化页面；
- 意向分数及贡献事件；
- 数据完整度与身份置信度。

摘要不能隐藏原始证据，任何一句结论都能下钻到事件。

---

## 9. Session、触点和归因

### 9.1 Session 化

事件先按 `anonymous_id + occurred_at` 排序：

- 第一条事件开始 Session；
- 相邻事件间隔超过阈值时开始新 Session；
- 显式 `session_start` 可辅助，但服务器仍校验；
- 迟到事件进入后触发受影响窗口重算；
- Bot、内部员工和预览流量单独标记，不混入生产转化。

### 9.2 渠道触点

每次入口保存不可变触点：

- referrer；
- UTM source/medium/campaign/content/term；
- Google click ID 等广告点击标识——仅在合法用途和适当保护下；
- landing page；
- locale、device、country；
- 首次/回访标志；
- 对应内容和 deployment。

### 9.3 归因视图

同一事实可以派生多种归因，不覆盖原触点：

- First touch：发现客户的渠道；
- Last touch：促成当前转化的最后入口；
- Last non-direct：排除直接访问后的最后有效来源；
- Linear/U-shaped：运营分析模型；
- Campaign influence：活动是否参与旅程；
- Content influence：哪些内容在转化前被消费。

报表必须注明归因模型和回看窗口，避免不同团队使用同一“转化”名称却得出不同数字。

---

## 10. Consent 与区域策略

### 10.1 用途分组

建议至少分为：

| Purpose | 示例 | 默认策略 |
|---|---|---|
| `necessary` | 安全、负载、表单提交、语言选择 | 仅限提供服务所需 |
| `analytics` | 跨页/跨天访问分析、漏斗 | 按地区和法律基础控制 |
| `personalization` | 根据历史行为调整内容 | 独立目的和开关 |
| `marketing` | 广告归因、再营销 | 独立目的和开关 |

### 10.2 Consent 快照

每次状态变化创建不可变 `consent_snapshot_id`，事件只引用快照。快照包括：

- 匿名或 Person 主体；
- 各 purpose 的 granted/denied；
- 政策版本；
- 地区规则版本；
- 展示语言；
- 同意/拒绝/撤回时间；
- 获取方式与证明；
- 到期时间（如适用）。

### 10.3 撤回后的流程

```text
用户撤回 analytics
  ↓
立即停止分析事件和跨天标识使用
  ↓
轮换/删除相应浏览器标识
  ↓
生成 consent_updated 审计事件
  ↓
按照适用政策删除、匿名化或限制既有明细数据
  ↓
保留必要的合规证明与不可逆聚合结果（仅在允许时）
```

加州适用企业还需要支持知情、删除、更正、限制以及退出出售/共享等请求，并正确处理 Global Privacy Control。[California DOJ：CCPA](https://www.oag.ca.gov/privacy/ccpa)

---

## 11. 数据存储与处理架构

```text
Browser SDK / Server Events
          ↓
First-party Event Gateway
          ↓
Consent Gate → Schema Validation → PII Redaction → Dedupe
          ↓
┌───────────────────────┬──────────────────────────┐
│ Raw Event Store       │ Quarantine               │
│ 短期、受控、可重放     │ 非法 Schema/可疑 PII      │
└───────────┬───────────┴──────────────────────────┘
            ↓
Validated Event Stream
      ┌─────┴─────────┐
      ↓               ↓
ClickHouse          PostgreSQL/Profile Vault
行为与聚合分析       身份、PII、Consent、审计
      └─────┬─────────┘
            ↓
Identity Engine / Sessionizer / Attribution / Intent
            ↓
Customer Timeline / Operations Center / CRM Tasks
```

### 11.1 推荐职责

- PostgreSQL：Person、Account、Identity Link、Consent、Lead、审计；
- ClickHouse：高频事件、Session 派生、漏斗、路径和聚合；
- 对象存储：短期原始批次、重放和合规证据；
- Redis/队列：实时处理、去重窗口和任务调度；
- KMS/Vault：PII 与连接器密钥。

### 11.2 数据保留

不把保留期写死在代码中。按区域、purpose、数据类别配置：

- 浏览器匿名标识有效期；
- 原始事件保留期；
- Session 明细保留期；
- PII 和线索保留期；
- 聚合指标保留期；
- Consent 和安全审计证明保留期。

到期任务必须自动执行、可审计、可重试，并覆盖备份恢复后的再次删除。具体期限由实际市场、法律基础、合同和业务必要性确认。

---

## 12. 数据质量与覆盖率

### 12.1 必须承认的缺口

- 用户拒绝分析同意；
- Cookie 被清除或到期；
- 浏览器无痕模式；
- 广告拦截器；
- 网络断开或页面快速关闭；
- 用户跨设备但未登录/验证；
- Bot 和预加载请求；
- 浏览器时间错误。

因此不能承诺“识别 100% 用户、记录 100% 行为”。系统应展示：

- 事件发送成功率；
- consent 覆盖率；
- 匿名档案持续天数分布；
- 已识别 Lead 的历史轨迹覆盖率；
- 身份合并率和冲突率；
- 客户端与服务端转化差异；
- Bot/内部流量比例；
- SDK 和 Schema 版本分布。

### 12.2 服务端确认关键转化

浏览器的 `form_submit_click` 只是用户点击，不是成功线索。真相流程应是：

```text
浏览器提交
  ↓
服务端校验
  ↓
事务性写入 Lead
  ↓
服务端发出 form_submit_success + lead_id
  ↓
浏览器成功页面只作为辅助证据
```

这能避免刷新、重复点击、网络错误和拦截器造成虚假转化。

---

## 13. 运营应用

跨天轨迹完成后，运营智能中心可以提供：

### 13.1 客户旅程分析

- 转化前平均访问天数和 Session 数；
- 常见页面序列；
- 首次内容与最终转化内容；
- 不同语言、渠道和客户类型的旅程；
- 哪一步最容易流失；
- 回访频率与转化关系。

### 13.2 高意向发现

示例评分：

```text
30 天内再次访问                 +10
访问价格页                      +15
访问集成/实施文档               +12
下载白皮书                      +15
提交咨询                        +30
7 天无活动                       -8
仅浏览招聘/隐私页面               0
Bot 或内部员工                  排除
```

每一分都要能回到具体事件；评分只做排序，不应直接作出对个人有重大影响的自动决定。

### 13.3 内容运营

- 哪些内容经常出现在高质量线索转化前；
- 哪些页面带来回访但不直接转化；
- 哪个语言版本的旅程中断最多；
- 哪次 CMS 发布影响了后续浏览和表单；
- 内容影响力不再只按最后一次页面判断。

### 13.4 销售提示

当已识别联系人近期出现高意向时，生成一张简洁卡片：

```text
联系人：Person 123（权限允许时显示姓名/公司）
最近活跃：2 小时前
30 天：4 个访问日、7 个 Session、18 个有效页面
主要兴趣：ERP 集成、价格、德国交付
高意向证据：两次价格页、下载方案、提交咨询
建议：由 DACH 销售在 1 个工作日内跟进
```

不应把未经验证的匿名访客身份直接发送给销售。

轨迹进入销售应用后，还需要构建 Person/Account 统一画像，将 Fit、Engagement、Intent 和 Reach 分开计算，并连接购买阶段、Buying Committee、商机、报价和订单结果。完整销售转化设计见同目录：`客户画像与销售转化实施方案.md`。

---

## 14. API 与服务边界

建议拆分为：

```text
tracking-sdk
event-gateway
schema-registry
consent-service
session-service
identity-engine
profile-vault
journey-query-service
attribution-service
intent-service
privacy-request-service
```

关键 API：

- `POST /v1/events/batch`：批量事件；
- `POST /v1/identify`：服务端提交已验证身份关联；
- `POST /v1/consents`：记录或更新 consent；
- `GET /v1/persons/{id}/timeline`：权限过滤后的时间线；
- `POST /v1/identity-links/{id}/revoke`：撤销错误关系；
- `POST /v1/privacy-requests`：访问/导出/删除请求；
- `GET /v1/data-quality/identity`：身份覆盖和冲突指标。

`/identify` 不接受浏览器随意声明 `person_id`。它必须由登录服务、表单服务或受信后端用服务凭据调用，防止恶意用户把自己的轨迹绑定到他人。

---

## 15. 分阶段实施

### T0：业务问题、事件和合规合同（2 周）

**流程**

1. 列出需要回答的客户旅程问题；
2. 定义 20～30 个核心事件；
3. 为每个事件定义目的、属性、Owner 和保留策略；
4. 定义匿名、识别、合并、拆分与删除规则；
5. 完成区域 consent 决策矩阵和隐私评估；
6. 确定时间线原型和角色权限。

**效果**：避免“先全埋点、以后再想怎么用”的数据垃圾。

### T1：匿名跨天主链（3～4 周）

**流程**

1. 开发浏览器 SDK 与第一方 Event Gateway；
2. 签发 anonymous_id；
3. 实现 session_id 和跨天 Session；
4. 附加 content、locale、revision、deployment；
5. 完成 Schema、去重、Bot/内部流量和数据质量；
6. 建立匿名访客时间线。

**验收**：同一测试浏览器隔日访问产生两个 Session、一个 Anonymous Profile；拒绝 consent 时行为符合区域策略。

### T2：表单识别与历史关联（3～4 周）

**流程**

1. 建设 Person/Profile Vault；
2. 表单成功后由服务端创建 Person/Lead；
3. 创建确定性 Identity Link；
4. 历史匿名 Session 显示在 Person 时间线；
5. 实现冲突、拆分和重算；
6. 实现角色级 PII 权限。

**验收**：测试用户第三次访问提交表单后，可以看到前三次合规轨迹；另一个共享设备用户不会被错误合并。

### T3：跨设备、账户与运营使用（3～5 周）

**流程**

1. 接入登录、验证链接和 CRM contact_id；
2. 实现多个 anonymous_id 到 Person；
3. 实现 Person 到 Account；
4. 建设 Journey、归因和意向评分；
5. 接入运营中心和销售任务；
6. 建设效果与数据质量报表。

**验收**：跨设备只通过确定性证据合并；每条高意向结论可以下钻到事件。

### T4：隐私请求和生产强化（2～3 周）

**流程**

1. 实现访问、导出、删除、更正和撤回；
2. 实现保留期任务；
3. 对事件属性进行 PII 扫描；
4. 完成越权、伪造 identify、重放和流量攻击测试；
5. 建立泄露响应和身份规则变更审计；
6. 压测采集与时间线查询。

**验收**：隐私请求能覆盖事件、身份、PII、派生画像和下游任务；所有操作可审计。

匿名跨天 + 表单识别的 MVP 约需 8～10 周，可与 CMS 页面和运营中心并行开发；跨设备、账户、隐私自动化完整版本约需 12～16 周，取决于登录、CRM 与合规范围。

---

## 16. 测试场景

至少覆盖以下端到端场景：

1. 同一浏览器第一天访问、第二天回访：一个 anonymous_id、两个 Session；
2. 第三天提交表单：历史事件关联到 Person；
3. 同一 Person 在另一设备登录：两个 anonymous_id 关联同一 Person；
4. 同一共享设备出现两个登录账号：不合并两个 Person；
5. 用户拒绝 analytics：不建立被禁止的跨天分析标识；
6. 用户先同意后撤回：停止采集并执行配置的既有数据处理；
7. Cookie 清除：创建新匿名档案，不使用指纹重连；
8. 事件重复发送：`event_id` 去重；
9. 离线事件延迟到达：Session 和归因正确重算；
10. 表单点击但服务端失败：不计成功线索；
11. URL 带 email/token：采集前清洗；
12. SDK 发送未知属性：隔离并通知事件 Owner；
13. 错误 Identity Link 被撤销：时间线、归因和评分重算；
14. 删除请求：PII、事件关联和下游数据在 SLA 内完成处理；
15. CMS 发布后访问：每个事件能对应内容版本和 deployment。

---

## 17. 验收指标

### 采集

- 核心事件 Schema 合规率 ≥ 99%；
- 重复事件不重复计数；
- 核心转化由服务端确认比例 100%；
- 事件端到端可见时间 P95 ≤ 60 秒；
- SDK 对前台性能影响达到既定预算。

### 身份

- 所有 Person 合并都有可审计证据；
- 任何 Identity Link 均可撤销和重算；
- 已识别 Web Lead 中，至少 80% 能看到留资前轨迹——以 consent 和标识覆盖率允许为前提；
- 身份冲突率、自动合并率和人工修正率可见；
- 不以 IP 或设备指纹作确定性 Person 合并。

### 业务

- 可计算转化前访问天数、Session 数和内容序列；
- 可按语言、渠道、内容和 Account 查看旅程；
- 高意向提示全部带事件证据；
- 内容发布可以关联后续访问与转化变化；
- 销售可以看到权限范围内的首次来源、最近行为和兴趣主题。

### 隐私与安全

- Consent 拒绝和撤回在采集链路立即生效；
- 密码和敏感表单内容进入分析仓库的数量为零；
- PII 与行为事件隔离并加密；
- 导出、删除、拆分和管理员查看均有审计；
- 多租户身份与事件访问隔离测试通过。

---

## 18. 最终结论

跨天用户轨迹的正确主链是：

```text
第一天匿名访问
→ 第一方 anonymous_id
→ 多个跨天 Session
→ 表单/登录产生确定性身份
→ Identity Link 连接历史匿名行为
→ Person / Account 时间线
→ 漏斗、归因和意向评分
→ 运营或销售任务
→ 效果复盘
```

这套能力应该从 CMS 第一阶段就进入技术契约，因为每个事件必须携带 `content_id + locale + revision_id + deployment_id`。只有这样，未来才能回答的不只是“这个用户来过几次”，还包括“他在哪次内容发布后、通过什么渠道、看了哪个语言版本、完成了什么行为，以及应该采取什么下一步动作”。

---

## 参考资料

1. [中华人民共和国个人信息保护法——国家市场监督管理总局](https://www.samr.gov.cn/wljys/gzzd/art/2023/art_3ef1e889c1e644d4b65b5f5c7f432386.html)
2. [中华人民共和国个人信息保护法——中央网信办](https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm)
3. [EDPB：Cookies、Consent、Pseudonymisation FAQ](https://www.edpb.europa.eu/contact/frequently-asked-questions_en)
4. [EDPB：Guidelines 05/2020 on consent](https://www.edpb.europa.eu/documents/guideline/guidelines-052020-on-consent-under-regulation-2016679_en)
5. [California DOJ：CCPA](https://www.oag.ca.gov/privacy/ccpa)