|
|
@@ -525,3 +525,33 @@
|
|
|
- **阻塞**：业务库退款字段口径混乱（`refund_time` / `refund_success_time` / `refund_fee` / `refund_status` 等多字段），退款判据需先查清才能建退款表。
|
|
|
|
|
|
- **附口径确认**（2026 PG 实测）：302 订单结束(未中卡) 占 2026 的 35%（390万），算消费偏好（拼团类刮刮乐，参与即反映品类偏好，中不中卡不影响信号），dwd 含 302、tdm 统计含未中卡，确认无误。
|
|
|
+
|
|
|
+### ADR-13 埋点事件粒度：行为大类 + 参数化（收敛 event explosion）
|
|
|
+
|
|
|
+- **状态**：草案（数仓侧主张，待与产品对齐推动；存量事件不动、增量优先）
|
|
|
+
|
|
|
+- **背景**：现行 HS 埋点（神策 SDK）按"一个页面/按钮一个事件"设计，已上线 164 个自定义事件（xlsx 定义 197），大量是 `HomepageZTCKClick` / `BottomZTCKClick` / `MyCPCKClick` 这类"页面+动作"具名事件。三个问题：
|
|
|
+ 1. **事件爆炸**：每加一个页面就加一个事件，且每个事件 `params` schema 各异；
|
|
|
+ 2. **数仓结构化层直接受害**：raw 是薄表 JSON（schema-on-read，不受影响），但 **ods/dwd 无法做统一埋点事实宽表**——每个事件得单独映射拍平；新页面=新事件=ods/dwd 建模跟着加，永远收敛不了（2026-06 埋点建模卡顿的根因）；
|
|
|
+ 3. **跨事件分析**（全站点击/曝光/漏斗）困难。
|
|
|
+
|
|
|
+ 神策"事件-属性模型"、Amplitude "事件=动词 / 属性=上下文" 均主张少而结构化的事件 + 丰富属性；当前设计是典型 event explosion 反模式。
|
|
|
+
|
|
|
+- **决策**：埋点按**行为大类 + 参数化**重构（数仓主张，推动产品）：
|
|
|
+ - 导航/UI 长尾交互（各种 `XxxClick` / `XxxView` / `XxxShow` / `XxxShare`）→ 收敛为通用 `Click` / `View` / `Exposure` / `Share`，页面/区块/元素/位置作**标准化属性**（`page` / `module` / `element` / `position` / `content_id` 等）
|
|
|
+ - **核心业务转化事件**（`PayOrder` / `GroupPayOrder` / `SignUp` / 兑换 / 退款）**保留独立事件**——属性丰富、漏斗关键、语义重
|
|
|
+ - **不推倒重来**：存量事件 + 已上线 + 历史数据不动；增量优先（新交互按大类设计），长尾逐步归并，无硬切换
|
|
|
+
|
|
|
+- **后果**：
|
|
|
+ - 正面：埋点事件集有界；新页面=属性新值、仓库零改动（schema 稳定）；ods/dwd 可建统一埋点事实表（标准维度 + typed `params`）；跨事件漏斗/热力天然可做；埋点开发 + 数仓改表 + 测试成本同步下降
|
|
|
+ - 负面：需建立并维护参数命名规范（page/module/element/position taxonomy）；产品/分析师从"具名事件"转向"属性筛选"有学习成本；过渡期新老并存；部分 BI 漏斗对离散事件更友好
|
|
|
+
|
|
|
+- **候选方案**：
|
|
|
+ - 维持一页一事件：event explosion，仓库随页面无限改——否决（本 ADR 起因）
|
|
|
+ - 全塞进单个 `Click` 事件：丢核心业务事件的丰富语义、漏斗难用——否决，核心转化事件保留独立
|
|
|
+ - 纯全埋点（神策 `$AppClick` 自动采集）：缺业务上下文（哪个拼团/商品）——否决，仍需自定义属性补语义（即本方案的参数化）
|
|
|
+
|
|
|
+- **反悔条件**：
|
|
|
+ - 产品坚持不改 → 数仓退守：在 ods 用映射表把长尾事件归一到行为大类（治标不治本）
|
|
|
+ - 引入半结构化无痛 schema 漂移的引擎（全 JSON + schema-on-read 贯穿），event explosion 的仓库代价下降
|
|
|
+ - 团队规模 / 分析诉求变化使具名事件 ROI 反超
|
