Files

T

浅念 fe3fcfab07 chore: 入库需求基线文档与验收截图，忽略会话临时产物（终审卫生项）

Co-Authored-By: Claude Code <noreply@anthropic.com>

2026-09-15 22:13:00 +08:00

29 KiB

Raw Blame History

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

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

1. 目标定义

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

例如：

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 状态和用途下被采集。

中国《个人信息保护法》要求处理具有明确、合理目的，与目的直接相关，并采取对个人权益影响最小的方式，收集范围不得超过实现目的所必需的范围。国家市场监督管理总局：《个人信息保护法》

对欧洲用户，EDPB 说明：除技术必要 Cookie 外，在终端设备存取 Cookie 通常应在充分告知目的并取得同意后进行；假名化数据仍属于个人数据。EDPB Cookie 与假名化说明

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

3. 四级身份模型

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 第一次访问

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

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

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

4.2 第二天再次访问

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

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

4.3 表单提交后识别

匿名用户提交表单
  ↓
浏览器只发送 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 跨设备识别

设备 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 标准事件信封

{
  "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 组件只调用：

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 查找并避免行为仓库出现明文：

规范化 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 错误合并拆分

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

8. 客户旅程时间线

8.1 时间线视图

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

首次接触        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.1 用途分组

建议至少分为：

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

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

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

10.3 撤回后的流程

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

加州适用企业还需要支持知情、删除、更正、限制以及退出出售/共享等请求，并正确处理 Global Privacy Control。California DOJ：CCPA

11. 数据存储与处理架构

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 只是用户点击，不是成功线索。真相流程应是：

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

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

13. 运营应用

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

13.1 客户旅程分析

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

13.2 高意向发现

示例评分：

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

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

13.3 内容运营

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

13.4 销售提示

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

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

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

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

14. API 与服务边界

建议拆分为：

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 周）

流程

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

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

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

流程

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

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

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

流程

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

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

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

流程

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

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

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

流程

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

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

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

16. 测试场景

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

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

17. 验收指标

采集

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

身份

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

业务

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

隐私与安全

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

18. 最终结论

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

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

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

29 KiB Raw Blame History Unescape Escape