chore: 入库需求基线文档与验收截图，忽略会话临时产物（终审卫生项）
Co-Authored-By: Claude Code <noreply@anthropic.com>
This commit is contained in:
浅念
@@ -12,3 +12,10 @@ server/tracker/data/*.xdb
|
|||||||
sdk/node_modules/
|
sdk/node_modules/
|
||||||
sdk/dist/
|
sdk/dist/
|
||||||
deploy/data/
|
deploy/data/
|
||||||
|
|
||||||
|
# 会话临时产物与本地杂物
|
||||||
|
.playwright-mcp/*
|
||||||
|
!.playwright-mcp/验收-*.png
|
||||||
|
_artifact_build_complete/
|
||||||
|
gpt/
|
||||||
|
/index.html
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 65 KiB |
@@ -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/)
|
||||||
|
|
||||||
Binary file not shown.
Binary file not shown.
@@ -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)
|
||||||
Reference in New Issue
Block a user