# 跨天用户轨迹与身份解析实施方案 > 适用项目：自研多语言静态网站 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)