2. 埋点数据模型设计：事件模型、用户模型、设备模型、上下文模型
好，咱们直接切入正题。
埋点数据模型，说白了就是定义「你往日志里塞什么」。
我见过不少团队，一上来就急着写代码，结果埋点数据乱七八糟。用户ID有时是手机号，有时是邮箱，设备指纹更是五花八门。最后做分析时，数据根本对不上。
所以，设计阶段多花点时间，后面能省下大把的返工时间。
2.1 事件模型：一切行为的起点
事件模型是埋点的核心。你想想看，用户每一次点击、每一次下单，都是一个事件。
我个人习惯把事件模型拆成三部分：事件头、事件体、事件属性。
| 组成部分 | 字段示例 | 说明 |
|---|---|---|
| 事件头 | event_id, event_name, event_time | 唯一标识、事件名称、发生时间 |
| 事件体 | page_id, element_id, action_type | 发生在哪个页面、哪个元素、什么操作 |
| 事件属性 | amount, currency, product_id | 业务相关的关键数据 |
举个例子，用户点击「立即购买」按钮：
{
"event_id": "evt_20231027_001",
"event_name": "click_buy_now",
"event_time": 1698384000000,
"page_id": "product_detail",
"element_id": "btn_buy_now",
"action_type": "click",
"amount": 299.00,
"currency": "CNY",
"product_id": "P10086"
}
我的经验：事件名称一定要统一命名规范。我曾经在一个项目里看到过「click_buy」「buy_click」「purchase_click」三种写法，最后清洗数据时差点崩溃。
2.2 用户模型：你是谁
用户模型解决的是「谁干了这件事」。
这里有个坑：很多团队只记录登录后的用户ID。但交易链路中，大量行为发生在未登录状态，比如浏览商品、加购。
所以，我建议至少保留两个ID：
- 游客ID（guest_id）：用户首次访问时生成，存在本地存储
- 登录ID（user_id）：用户登录后，从服务端获取
用户登录后，需要做一次ID映射。把游客ID和登录ID关联起来，这样就能追溯用户登录前的行为。
{
"guest_id": "g_abc123",
"user_id": "u_987654",
"user_type": "registered",
"user_level": "vip3",
"registration_time": 1698000000000
}
注意：千万不要把手机号、身份证号直接当用户ID用。这是合规红线。我见过有公司把手机号明文存日志，后来被罚了款。
2.3 设备模型：从哪来
设备模型记录的是「用户用什么设备操作」。
嗯，这里要注意。设备信息不仅仅是UA（User-Agent）那么简单。在风控场景下，我们需要更精细的设备指纹。
我个人习惯采集以下几类：
- 硬件信息：设备型号、屏幕分辨率、CPU核心数
- 软件信息：操作系统版本、浏览器版本、App版本
- 网络信息：IP地址、运营商、网络类型（WiFi/4G/5G）
- 设备标识：设备ID（IDFA/IMEI/OAID，注意合规）
{
"device_id": "d_xyz789",
"device_type": "iPhone 15 Pro",
"os": "iOS 17.1",
"app_version": "6.8.0",
"screen_resolution": "1179x2556",
"network_type": "WiFi",
"ip": "192.168.1.100"
}
核心观点：设备指纹的稳定性很重要。同一个设备，在不同时间、不同场景下，采集到的指纹应该一致。否则风控规则会频繁误判。
2.4 上下文模型：当时的环境
上下文模型记录的是「事件发生时的环境状态」。
为什么需要这个？因为同一个事件，在不同上下文中，风险等级完全不同。
举个例子：同样是下单1000元，在凌晨3点从陌生IP下单，和在工作日下午从常用IP下单，风险系数天差地别。
我建议上下文模型包含：
- 时间上下文：当前时间、星期几、是否节假日
- 位置上下文：GPS坐标、城市、国家
- 会话上下文：会话ID、页面停留时长、来源页面
- 行为上下文：当前事件前的最近3个事件、事件间隔
{
"session_id": "sess_555",
"timestamp": 1698384000000,
"weekday": 5,
"is_holiday": false,
"city": "北京",
"country": "中国",
"referrer": "https://m.taobao.com/search?q=手机",
"previous_events": ["view_product", "add_to_cart", "click_buy_now"]
}2.5 四模型联动：一张图看懂
这四个模型不是孤立的。它们共同构成了一条完整的埋点记录。
我画了一张图，帮你理解它们之间的关系：
你看，一条完整的埋点记录，就是把这四个模型的数据拼在一起。
2.6 避坑指南
我曾经踩过的坑：
- 字段类型不一致：同一个字段，iOS传字符串，Android传数字，导致ETL报错
- 缺少版本号：埋点字段升级后，老版本数据和新版本混在一起，无法区分
- 过度采集：把用户输入的搜索关键词、评论内容都埋进去，合规风险极高
我的建议：
- 每个模型都加一个
schema_version字段，方便后续兼容 - 所有时间字段统一用毫秒级时间戳，别用字符串
- 敏感字段（手机号、身份证）必须脱敏或加密后再落日志
好了，模型设计这块就聊到这。记住一句话：埋点数据是风控的原材料，原材料质量决定了最终成品的质量。