fbc7f114
 tangwang
docs
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
# Dynamic Yield：用户数据获取技术方案（拆解版）
> 目标：拆解 Dynamic Yield（DY）在“用户数据获取/实时决策/实验优化”的数据层实现，方便你们对标自研个性化引擎 SaaS。
>
> 说明：DY 的部分文档与实现细节面向客户/合作伙伴账号。本文基于公开资料与行业主流 DY 类产品的落地方式提炼，字段/端点级细节需以你们获取到的 DY 官方文档与 PoC 抓包为准。
---
## 1. DY 的数据获取 = 事件采集 + 商品/内容 feed + 身份合并
### 1.1 事件采集（Web/App）
**目的**：实时构建 session 意图与短期偏好，驱动 onsite personalization、推荐、A/B 测试。
**典型事件**（行业通用）：
- `page_view`
- `product_view`
- `add_to_cart`
- `checkout_start`
- `purchase`
- `search`
### 1.2 商品/内容 Feed
**目的**：推荐与决策需要“可用的候选集合”，feed 的字段质量直接影响推荐与排序。
**典型字段**：
- product_id / sku
- title/description/image
- category/attributes
- price/sale_price
- availability/inventory
- tags/brand
### 1.3 用户属性与业务事实
**目的**：把长期价值与偏好（RFM/LTV/会员等级/历史购买）进入用户画像，支撑更强的策略与实验分层。
---
## 2. 数据采集方式（DY 类产品典型实现）
### 2.1 前端 Tag（DY Tag / JS）
**作用**：
- 为访客分配匿名 ID（cookie/localStorage 一方）
- 采集页面上下文与行为事件
- 拉取“决策结果”（推荐/个性化变体/优惠）并渲染
- 记录实验曝光与转化（A/B、MVT）
**工程要点**：
- 异步加载、避免阻塞渲染
- 事件幂等（event_id）
- 与服务端订单事实对账（purchase 最好 S2S 再补一份）
### 2.2 服务端 S2S（转化/订单事实）
**作用**：
- 提升 purchase/退款/取消的准确性与一致性
- 支撑 server-side personalization 场景（例如在 edge/SSR 输出个性化）
**关键字段建议**：
- order_id（幂等）
- customer identifiers（customer_id / email_sha256 / phone_sha256）
- items、value、currency、timestamp
### 2.3 平台/工具集成（CDP/Email/Ads）
DY 常作为“决策层”，因此会对接：
- CDP（统一事件流）
- Email/SMS（把推荐/人群输出到触达渠道）
- Ads（把人群同步到投放平台、回传转化做归因）
---
## 3. 身份识别与跨设备（DY 类产品常见策略）
### 3.1 匿名到已知
触发点：
- 登录
- 留资（订阅）
- 下单
做法：
- 在“识别事件”发生时，把当前匿名 cookie id 与已知标识（email/phone/customer_id）绑定
- 将历史匿名行为合并到已知画像
### 3.2 跨设备
- **确定性优先**：email/phone/customer_id
- **匹配增强**：哈希 PII + click id 回传给广告平台，借助平台跨设备图谱提升归因（DY/你们都无法直接拿到平台图谱细节）
---
## 4. 实验与归因：为什么 DY 必须“自己采 + 自己记曝光”？
DY 的 A/B 测试与个性化要成立，必须同时拥有：
- **曝光事件**：用户看到了哪个变体/哪个推荐位（exposure/impression）
- **行为/转化事件**：点击、加购、购买
因此在数据获取层，DY 类系统会强制：
- 在前端记录“谁看到什么”（曝光）
- 在订单侧确认“最终发生什么”（purchase/refund）
这也是你们自研时必须具备的两条事件链路。
---
## 5. 去重、延迟与一致性
- 曝光/点击等事件：秒级进入决策系统（用于实时策略）
- 订单事实：以 order_id 幂等，分钟级确认并可反向修正（退款/取消）
- 报表与分析：小时级/天级聚合
---
## 6. 你们自研 SaaS 的可复用点（对照 DY）
- 把“决策层（实时个性化）”与“事实层（订单/客户/商品）”拆开建管道
- 曝光事件是 A/B 与个性化归因的基础（必须采集）
- purchase 必须 S2S 幂等回传（order_id）
- 广告平台闭环：click id + S2S 回传 + 报表富化（见 `docs/用户匹配与外部数据打通-平台官方机制提权.md`）
|