DynamicYield-用户数据获取技术方案.md
4.04 KB
Dynamic Yield：用户数据获取技术方案（拆解版）
目标：拆解 Dynamic Yield（DY）在“用户数据获取/实时决策/实验优化”的数据层实现，方便你们对标自研个性化引擎 SaaS。
说明：DY 的部分文档与实现细节面向客户/合作伙伴账号。本文基于公开资料与行业主流 DY 类产品的落地方式提炼，字段/端点级细节需以你们获取到的 DY 官方文档与 PoC 抓包为准。
1. DY 的数据获取 = 事件采集 + 商品/内容 feed + 身份合并
1.1 事件采集（Web/App）
目的：实时构建 session 意图与短期偏好，驱动 onsite personalization、推荐、A/B 测试。
典型事件（行业通用）：
page_viewproduct_viewadd_to_cartcheckout_startpurchasesearch
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）