diff --git a/.gitignore b/.gitignore
index 6188760..a78f42b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,10 @@ server/tracker/data/*.xdb
 sdk/node_modules/
 sdk/dist/
 deploy/data/
+
+# 会话临时产物与本地杂物
+.playwright-mcp/*
+!.playwright-mcp/验收-*.png
+_artifact_build_complete/
+gpt/
+/index.html
diff --git a/.playwright-mcp/验收-A6-数据总览.png b/.playwright-mcp/验收-A6-数据总览.png
new file mode 100644
index 0000000..e1a420e
Binary files /dev/null and b/.playwright-mcp/验收-A6-数据总览.png differ
diff --git a/.playwright-mcp/验收-A8-访客详情时间线.png b/.playwright-mcp/验收-A8-访客详情时间线.png
new file mode 100644
index 0000000..aa3cf70
Binary files /dev/null and b/.playwright-mcp/验收-A8-访客详情时间线.png differ
diff --git a/docs/客户画像与销售转化实施方案.md b/docs/客户画像与销售转化实施方案.md
new file mode 100644
index 0000000..e802028
--- /dev/null
+++ b/docs/客户画像与销售转化实施方案.md
@@ -0,0 +1,543 @@
+# 客户画像与销售转化实施方案
+
+> 适用项目：自研多语言 CMS、客户旅程与运营智能系统  
+> 版本：V1.0｜日期：2026-09-11  
+> 目标：把经过授权的客户行为转化为业务人员可理解、可执行、可复盘的订单机会。
+
+---
+
+## 1. 总体结论
+
+客户行为数据只有走完下面的闭环，才能帮助业务产生订单：
+
+```text
+行为采集 → 身份识别 → Person / Account 统一画像
+→ 匹配度、互动度、购买意向、购买阶段
+→ 决策角色与商机识别 → 推荐下一步动作
+→ 分配业务人员与响应 SLA → 跟进、报价、订单
+→ 赢单/输单结果回流 → 校准画像、评分和运营策略
+```
+
+建议新增“**客户洞察与销售工作台**”。它不只是线索列表，而要每天回答：
+
+1. 今天最应该跟进哪些客户或企业？
+2. 为什么是他们，证据是什么？
+3. 他们可能对什么产品和问题感兴趣？
+4. 目前处于了解、考虑、比较还是购买阶段？
+5. 企业中还有谁参与决策，缺少哪个角色？
+6. 应通过什么方式、提供什么内容、询问什么问题？
+7. 跟进后是否形成商机、报价和订单？
+
+---
+
+## 2. 可行动客户画像
+
+画像不是“高端客户”“有钱”“急需”等无法验证的标签。画像必须由事实、推导规则、来源和置信度组成。
+
+### 2.1 七层画像
+
+| 层次 | 回答的问题 | 主要数据 |
+|---|---|---|
+| 身份 | 他是谁、来自哪个企业？ | anonymous_id、person_id、account_id、身份关系证据 |
+| 基本匹配 | 是否属于目标客户？ | 国家、行业、规模、职位、区域、产品适用性 |
+| 行为兴趣 | 最近关注什么？ | 页面、主题、下载、站内搜索、CTA、语言 |
+| 互动强度 | 参与多深、多频繁？ | 访问天数、Session、阅读、回访、表单、邮件互动 |
+| 购买意向 | 是否出现采购信号？ | 价格、对比、集成、实施、案例、咨询、多人访问 |
+| 购买阶段 | 目前处在哪个阶段？ | 触点组合、趋势、销售反馈、商机状态 |
+| 商业关系 | 谁跟进、机会多大、是否成交？ | Owner、任务、商机、报价、订单、赢单/输单 |
+
+### 2.2 画像字段必须可追溯
+
+每个 Trait 保存：字段值、数据来源、原始证据、更新时间、确定/推测、置信度、有效期、允许用途和人工确认状态。
+
+```text
+兴趣主题：ERP 集成
+类型：推导属性
+证据：30 天内访问 4 次集成文档、下载 ERP 指南
+置信度：高
+允许用途：销售准备、站内个性化
+```
+
+不能把“浏览过安全白皮书”直接写成“此人是安全负责人”；只能生成带置信度的角色候选。
+
+---
+
+## 3. Person 与 Account 双层画像
+
+### 3.1 Person 画像
+
+- 姓名、工作邮箱、电话——仅限有权限人员；
+- 职位、部门、职级和可能角色；
+- 国家、语言和时区；
+- 首次来源、最近来源、访问日和 Session；
+- 内容主题、产品兴趣和关键转化；
+- Fit、Engagement、Intent；
+- 生命周期、负责人、任务、联系偏好和 consent；
+- 关联 Account、Opportunity 和订单。
+
+### 3.2 Account 画像
+
+B2B 订单往往由多人决定，因此企业画像是主视角：
+
+- 企业、域名、国家、行业、规模和业务类型；
+- 适配产品和目标客群；
+- 已识别联系人及聚合活动；
+- 企业整体兴趣、活动趋势和产品线；
+- Account Fit、Intent、Reach、购买阶段；
+- Buying Committee 覆盖；
+- Owner、历史商机、订单、竞争与风险。
+
+### 3.3 B2C 适配
+
+若业务属于 B2C，则以 Person 为主；Account 可以关闭或用于家庭/组织关系，保留生命周期、机会和订单闭环。
+
+---
+
+## 4. 调研理念的自研转化
+
+HubSpot 将基于属性的 Fit 与基于行为的 Engagement 分开，用于联系人、公司和交易资格判断。[HubSpot Lead Scoring](https://knowledge.hubspot.com/scoring/build-lead-scores)
+
+Salesforce Einstein 从历史转化中寻找共同特征，对当前 Lead 排序，并展示影响评分的因素。[Salesforce Einstein Lead Scoring](https://help.salesforce.com/s/articleView?id=ai.einstein_sales_lead_insights.htm&language=en_US&type=5)
+
+6sense 将 Account Profile Fit、Intent、Reach 和 Buying Stage 分开，并按 Target、Awareness、Consideration、Decision、Purchase 观察企业阶段。[6sense Scores Overview](https://support.6sense.com/docs/6sense-scores-overview)、[6sense Buying Stages](https://support.6sense.com/docs/predictive-buying-stages)
+
+Segment 的统一 Profile 思想把身份、事件、Traits 和 Audiences 放入同一客户上下文。[Twilio Segment Personas](https://segment.com/blog/put-your-customers-first-with-personas/)
+
+我们的自研系统吸收这些思想，但不购买它们作为核心平台：身份图、评分规则、客户画像、销售反馈和订单结果全部由自有系统掌握。
+
+---
+
+## 5. 四类评分必须分开
+
+### 5.1 Fit Score：是否适合
+
+依据相对稳定的属性：国家、行业、规模、区域、技术场景、职位、产品适配性和排除对象。
+
+```text
+目标国家                         +15
+目标行业                         +20
+员工规模 100～1000               +15
+决策/技术/采购角色                 +10
+明确适配 Product A                +20
+个人邮箱且无企业信息                -10
+竞争对手、供应商或求职者             -30
+```
+
+### 5.2 Engagement Score：互动强度
+
+```text
+30 天内 2 个以上访问日              +8
+有效阅读超过 90 秒                  +3
+再次回访                           +8
+下载资料                           +10
+活动参与                           +12
+回复业务邮件                       +15
+30 天无活动                        -10
+90 天无活动                        -25
+```
+
+使用时间衰减，避免一年前的行为长期保持高分。
+
+### 5.3 Intent Score：购买意向
+
+```text
+查看价格页                         +15
+查看产品对比                       +15
+查看实施、迁移或集成文档             +12
+查看客户案例                        +8
+多次查看同一产品                    +10
+提交咨询或演示申请                  +30
+同一企业多人关注同一产品             +15
+只查看新闻或招聘                     0
+```
+
+访问次数不等于购买意向，必须根据内容语义和行为组合判断。
+
+### 5.4 Reach Score：业务触达状态
+
+综合负责人分配、SLA、最近联系、回复、内容匹配、购买角色覆盖和过度触达风险。Reach 不是联系次数越多越高；频繁无回复可能表示需要降频。
+
+### 5.5 行动矩阵
+
+| Fit | Intent | Reach | 推荐动作 |
+|---|---|---|---|
+| 高 | 高 | 低 | 立即分配销售，个性化联系 |
+| 高 | 高 | 高 | 推进商机、补齐决策角色、处理障碍 |
+| 高 | 中 | 低 | 提供相关案例，持续观察 |
+| 高 | 低 | 任意 | 长期培育，不占用销售时间 |
+| 低 | 高 | 低 | 先做资格核实 |
+| 任意 | 下降 | 高 | 减少触达，调查失去兴趣或体验问题 |
+
+界面可显示 Priority Rank，但必须同时展示四个子分及其影响因素，不能只给一个神秘总分。
+
+---
+
+## 6. 购买阶段
+
+| 阶段 | 客户表现 | 内容/运营动作 | 业务动作 |
+|---|---|---|---|
+| Target | 符合 ICP，无明显行为 | 品牌和基础内容 | 暂不人工联系 |
+| Awareness | 浏览问题类内容 | 教育、趋势内容 | 轻量观察 |
+| Consideration | 产品、方案、案例回访 | 指南、案例、比较 | 资格判断、理解场景 |
+| Decision | 价格、集成、实施、多人参与 | ROI、实施和风险材料 | 演示、方案、角色覆盖 |
+| Purchase | 咨询、报价、合同、采购 | 成交支持 | 商务、法务和采购推进 |
+
+同时保存三种状态：
+
+- `inferred_stage`：网站行为推断；
+- `sales_confirmed_stage`：业务确认；
+- `opportunity_stage`：正式商机阶段。
+
+阶段可以后退。长期无活动、明确输单或暂不采购，应进入 Nurture、Dormant 或 Closed Lost，不应永远保持高意向。
+
+---
+
+## 7. 生命周期与订单漏斗
+
+```text
+Anonymous Visitor → Identified Lead → Engaged Lead
+→ MQL → SAL → SQL → Opportunity
+→ Proposal / Quote → Negotiation → Closed Won / Order
+                               └→ Closed Lost / Nurture
+```
+
+| 转换 | 最低门槛 |
+|---|---|
+| Anonymous → Identified | 表单、登录或其他确定性身份 |
+| Identified → MQL | Fit + Intent 达标，排除垃圾和不合规联系人 |
+| MQL → SAL | 已分配且销售在 SLA 内接受 |
+| SAL → SQL | 销售确认需求、角色和基本资格 |
+| SQL → Opportunity | 明确产品、预计金额、时间和下一步 |
+| Opportunity → Quote | 形成可交付方案与商业条件 |
+| Quote → Won | 合同或订单确认，并保存订单结果 |
+
+这些门槛按产品、区域和业务线配置。
+
+### 7.1 销售反馈必须回流
+
+业务人员至少反馈：接受/拒绝线索、无效原因、真实需求、采购时间、联系人角色、当前障碍、商机创建、赢单/输单原因、订单金额和建议是否有帮助。
+
+没有最终结果标签，系统只能优化访问和表单数量，无法优化真正的订单。
+
+---
+
+## 8. Buying Committee
+
+| 角色 | 典型关注 | 证据来源 |
+|---|---|---|
+| 发起人/使用者 | 功能、流程、易用性 | 产品页、教程、试用 |
+| 技术评估者 | API、安全、集成、部署 | 技术文档、安全白皮书 |
+| 经济决策者 | ROI、价格、风险 | 价格、案例、ROI 内容 |
+| 采购/法务 | 合同、条款、合规 | 条款、安全、采购资料 |
+| Champion | 内部推动和主动沟通 | 深度互动及销售确认 |
+| 阻碍者 | 风险、替代方案、无响应 | 主要来自销售反馈 |
+
+```text
+Account A：Decision 阶段
+已识别：使用者 2、技术评估者 1
+缺失：经济决策者、采购/法务
+建议：请 Champion 引荐预算负责人，并发送 ROI 案例
+```
+
+角色推断必须标记“推测”，由客户陈述、CRM 或业务人员确认后才升级为确定值。
+
+---
+
+## 9. 业务人员工作台
+
+### 9.1 今日优先客户
+
+默认按可行动价值排序，而不是简单按最新线索排序：
+
+```text
+优先级 = Fit × Intent × 时间紧迫度 × 可触达性 × 预计价值
+         - 数据不确定性 - 过度触达风险 - 排除项
+```
+
+卡片展示 Person/Account、行业与区域、购买阶段、四类评分、最近变化、前三个原因、关键轨迹、Owner、SLA 和推荐动作。
+
+### 9.2 Customer 360 页面
+
+```text
+顶部：客户/企业、购买阶段、Owner、优先级、下一步
+左侧：基本资料、Fit、关系、Consent
+中间：跨天轨迹、兴趣主题、阶段变化、商机
+右侧：热门原因、推荐动作、相关内容、待办
+底部：联系人、Buying Committee、沟通、报价与订单
+```
+
+### 9.3 “为什么现在联系”示例
+
+```text
+建议今天联系 Account A
+
+原因：
+1. 目标制造业客户，Fit 86
+2. 7 天内访问 4 次，Intent 从 52 升至 78
+3. 两位联系人分别查看集成文档和价格页
+4. 尚未有效联系，Reach 18
+
+建议：德国区销售 4 小时内联系已留资的技术负责人，
+先确认 ERP 集成环境，并发送相关案例。
+```
+
+### 9.4 销售准备包
+
+- 30 秒客户摘要；
+- 最近兴趣、产品和问题；
+- 建议的发现式问题；
+- 适合发送的案例或实施资料；
+- 决策角色缺口；
+- 已发送内容，避免重复；
+- 风险和不确定信息；
+- 邮件/电话提纲草稿。
+
+---
+
+## 10. Next Best Action
+
+每个动作建议包含：对象、触发原因、事件证据、推荐渠道、内容、时机、SLA、推进目标、风险、审批和效果评价窗口。
+
+可以自动：
+
+- 创建线索和任务；
+- 按区域、产品、行业分配 Owner；
+- 提醒响应 SLA；
+- 准备摘要和联系草稿；
+- 推荐内容；
+- 更新可解释的分数和阶段候选；
+- 在 consent 允许时加入培育分群。
+
+默认人工确认：
+
+- 发送个性化销售邮件；
+- 自动拨打或频繁触达；
+- 修改正式商机阶段；
+- 报价、折扣和合同；
+- 将推测身份/角色写成事实；
+- 任何对客户有重大影响的自动决定。
+
+---
+
+## 11. 让 CMS 内容参与销售
+
+每篇内容增加结构化字段：
+
+- `product_ids`、`solution_ids`、`industry_ids`；
+- `persona_roles`、`buying_stage`；
+- `topic_ids`、`pain_point_ids`；
+- 内容类型、语言、地区；
+- CTA 和预期下一步。
+
+这样系统才能判断客户关注的产品、问题与阶段，并推荐下一条合适内容。
+
+推荐原则：不重复推荐已深度阅读内容；优先提供推动到下一阶段的材料；适配语言、地区、行业和产品；显示推荐原因；证据不足时不假装了解客户。
+
+---
+
+## 12. 数据模型
+
+| 对象/表 | 作用 |
+|---|---|
+| `profile_traits` | 值、来源、置信度、有效期、用途 |
+| `topic_affinities` | Person/Account 主题兴趣 |
+| `product_interests` | 产品兴趣、证据和趋势 |
+| `score_definitions` | 四类评分规则版本 |
+| `score_snapshots` | 对象、分数、版本和数据截止点 |
+| `score_factors` | 每次得分的正负因素 |
+| `buying_stage_transitions` | 推断/确认阶段及原因 |
+| `segments` / `segment_memberships` | 分群定义及历史归属 |
+| `buying_committee_members` | 角色、证据和确认状态 |
+| `lead_assignments` | Owner、规则、SLA、接受状态 |
+| `sales_activities` | 电话、邮件、会议、回复和结果 |
+| `opportunities` | 产品、金额、阶段和预计日期 |
+| `opportunity_contacts` | 商机中的联系人角色 |
+| `quotes` | 报价版本和状态 |
+| `orders` | 成交、金额、币种和产品 |
+| `action_proposals` | 推荐动作、证据和审批 |
+| `sales_feedback` | 有效性、需求、输单和建议评价 |
+
+分数必须版本化，确保以后能解释“当时为什么把这个客户排在第一”。
+
+---
+
+## 13. 从规则评分到预测模型
+
+### 13.1 冷启动使用规则
+
+规则模型上线快、容易解释、便于销售纠正，也不依赖大量历史订单。
+
+### 13.2 数据成熟后再训练模型
+
+预测目标可以包括 Lead→SQL、SQL→Opportunity、Opportunity→Won、预计成交时间和产品兴趣。训练只使用预测当时能获得的数据，避免把成交后的字段泄漏进去。
+
+Salesforce 对自身行为评分的说明也体现了数据量门槛，例如建议至少约 6 个月互动数据及一定数量的机会关联样本。[Salesforce Behavior Scoring Considerations](https://help.salesforce.com/s/articleView?id=mktg.pardot_einstein_behavior_scoring_considerations.htm&language=en_US&type=5)
+
+### 13.3 评估标准
+
+- Top 10%/20% 排名中的真实成交提升；
+- Precision、Recall、PR-AUC 和概率校准；
+- 不同国家、语言、产品的稳定性；
+- 数据和行为漂移；
+- 与规则基线及销售人工排序比较；
+- 是否提升真实订单，而不只是预测容易成交者。
+
+模型先以“影子评分”运行，不直接影响分配；确认产生增量价值后再逐步启用。
+
+---
+
+## 14. 典型销售 Playbook
+
+### 高 Fit、高 Intent、新线索
+
+```text
+Fit、Intent 达标且允许业务联系
+→ 去重并检查已有 Owner/Opportunity
+→ 按区域和产品分配
+→ 生成摘要、证据和建议问题
+→ 创建 4 小时 SLA 任务
+→ 未接受则升级
+→ 联系结果回流并调整阶段
+```
+
+### 高 Fit 匿名 Account 升温
+
+显示为企业机会，不声称识别个人；运营优化相关内容和转化入口，出现确定性联系人后再交给销售。
+
+### 进行中商机再次高频访问
+
+通知 Owner，显示新关注主题和可能角色，建议补充技术、安全、ROI 或采购材料，由销售确认是否推进阶段。
+
+### 报价后意向下降
+
+检查角色缺口、价格障碍和过度触达；提醒更新下一步。没有真实进展则进入 Nurture，避免形成虚假 Pipeline。
+
+### 老客户出现新产品兴趣
+
+生成 Cross-sell 候选，先交现有客户负责人确认，再追踪是否形成新的 Opportunity 和 Order。
+
+---
+
+## 15. AI 销售助手
+
+AI 可以准备客户摘要、意向变化解释、发现式问题、案例推荐、跟进草稿、会前准备和商机风险。
+
+回答必须写成：
+
+```text
+购买意向较高（Intent 78，规则 V3）
+主要因素：7 天内两次价格页、三次集成文档、一次演示申请
+数据截止：2026-09-11 08:30 CST
+身份：确定性；Account 关系：人工确认
+```
+
+禁止根据敏感属性推断购买力或人格；禁止编造预算、权限或个人偏好；禁止未经允许自动发消息；禁止用匿名行为声称识别具体自然人；禁止自动承诺价格、折扣或合同。
+
+---
+
+## 16. 分阶段实施
+
+### S0：销售流程和订单定义（2 周）
+
+定义 ICP、产品线、排除对象、MQL/SQL/Opportunity/Won、输赢原因、SLA、Person/Account 字段和权限，完成工作台原型。
+
+**验收**：市场与销售共同签署生命周期、字段和 SLA。
+
+### S1：统一画像与规则评分（3～4 周）
+
+建立 Trait、内容语义、Person/Account 360、四类评分、因素解释和版本；用历史客户人工回放。
+
+**验收**：所有高分都有证据，销售可以纠正属性和误判。
+
+### S2：销售工作台与线索流转（3～4 周）
+
+建设今日优先列表、分配、接受/拒绝、SLA、生命周期、Opportunity 最小模块、Next Best Action 和销售反馈。
+
+**验收**：一个 Web Lead 可以走到 Won/Lost，并回溯轨迹和动作。
+
+### S3：Account、决策小组与收入闭环（3～5 周）
+
+聚合 Account 行为、Buying Committee、销售 Playbook、内容推荐、报价/订单对接和收入归因。
+
+**验收**：可识别高价值 Account、角色缺口和下一步，订单结果反哺评分。
+
+### S4：预测模型与 AI（数据成熟后，5～8 周起）
+
+审计标签，建立规则基线，训练模型，运行影子评分，评估增量价值，达标后逐步启用。
+
+跨天轨迹底座完成后，规则画像与销售工作台 MVP 约需 8～12 周；Account、Buying Committee 与收入闭环通常再需 4～8 周。预测模型以数据质量为门槛，不按固定日期强行上线。
+
+---
+
+## 17. 验收指标
+
+### 数据和画像
+
+- 已识别 Lead 的留资前轨迹覆盖率；
+- Person→Account 可靠关联率；
+- 画像字段来源完整率；
+- 身份冲突和人工纠正率；
+- 内容主题与产品标签覆盖率。
+
+### 业务效率
+
+- 高优线索分配耗时；
+- 首次响应时间和 SLA 达标率；
+- Customer 360 使用率；
+- 无效线索处理时间；
+- 推荐动作接受率和完成率。
+
+### 漏斗和订单
+
+- Identified→MQL→SAL→SQL→Opportunity→Won；
+- 平均成交周期和订单金额；
+- Pipeline Velocity；
+- 各 Fit/Intent 分层的赢单率；
+- 网站、内容、SEO、广告和语言影响的 Pipeline/Revenue。
+
+成功标准不是画像字段很多，而是响应更快、无效工作更少、有效商机更多，并且赢单率或成交速度获得可验证提升。
+
+---
+
+## 18. 风险控制
+
+| 风险 | 控制 |
+|---|---|
+| 把新闻读者当买家 | Engagement 与 Intent 分开 |
+| 忽略多人决策 | Account + Buying Committee |
+| 神秘总分 | 四类评分 + 因素 + 版本 |
+| 旧行为长期污染 | 时间衰减和有效窗口 |
+| 没有销售反馈 | 强制结果与原因回流 |
+| 小样本预测 | 规则先行、影子评估 |
+| 推测被写成事实 | 来源、置信度、确认状态 |
+| 过度触达 | Reach、频控、Consent、审批 |
+| 只优化表单数量 | 以 SQL、Opportunity、Won 为目标 |
+| 销售不采用 | 嵌入每日列表、任务和 SLA |
+
+---
+
+## 19. 最终建议
+
+```text
+先让跨天轨迹和身份可靠
+→ 建立 Person / Account 统一画像
+→ 分开计算 Fit、Engagement、Intent、Reach
+→ 建立购买阶段、优先列表和销售 SLA
+→ 打通 Opportunity、Quote 和 Order
+→ 最后用真实赢单数据训练模型和 AI
+```
+
+网站帮助产生订单的关键，不是收集最多的数据，而是让每一项数据都能回答一个业务问题、推动一个正确动作，并用最终订单结果证明动作是否有效。
+
+---
+
+## 参考资料
+
+1. [HubSpot：Build lead scores](https://knowledge.hubspot.com/scoring/build-lead-scores)
+2. [Salesforce：Einstein Lead Scoring](https://help.salesforce.com/s/articleView?id=ai.einstein_sales_lead_insights.htm&language=en_US&type=5)
+3. [Salesforce：Behavior Scoring Considerations](https://help.salesforce.com/s/articleView?id=mktg.pardot_einstein_behavior_scoring_considerations.htm&language=en_US&type=5)
+4. [6sense：Scores Overview](https://support.6sense.com/docs/6sense-scores-overview)
+5. [6sense：Predictive Buying Stages](https://support.6sense.com/docs/predictive-buying-stages)
+6. [6sense：Buying Committee 定义](https://support.6sense.com/docs/6sense-product-glossary)
+7. [Twilio Segment：Unified Profiles and Personas](https://segment.com/blog/put-your-customers-first-with-personas/)
+
diff --git a/docs/客户行为数据采集平台完整项目实施方案.docx b/docs/客户行为数据采集平台完整项目实施方案.docx
new file mode 100644
index 0000000..5671075
Binary files /dev/null and b/docs/客户行为数据采集平台完整项目实施方案.docx differ
diff --git a/docs/客户行为数据采集平台方案实施报告.docx b/docs/客户行为数据采集平台方案实施报告.docx
new file mode 100644
index 0000000..a6de3f9
Binary files /dev/null and b/docs/客户行为数据采集平台方案实施报告.docx differ
diff --git a/docs/跨天用户轨迹与身份解析实施方案.md b/docs/跨天用户轨迹与身份解析实施方案.md
new file mode 100644
index 0000000..e44aeeb
--- /dev/null
+++ b/docs/跨天用户轨迹与身份解析实施方案.md
@@ -0,0 +1,903 @@
+# 跨天用户轨迹与身份解析实施方案
+
+> 适用项目：自研多语言静态网站 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)