采集技术选型：埋点方案对比与数据格式设计
做行为流采集，第一个绕不开的问题就是：怎么把数据弄进来？
说白了，就是埋点方案的选择。我见过不少团队，一上来就拍脑袋选了个方案，结果后面改得痛不欲生。今天咱们就把三种主流方案掰开揉碎聊一聊。
三种埋点方案，到底怎么选？
目前业界主流的埋点方案就三种：代码埋点、全埋点、可视化埋点。没有银弹，只有最适合你场景的。
| 对比维度 | 代码埋点 | 全埋点 | 可视化埋点 |
|---|---|---|---|
| 实现方式 | 开发者在代码中手动调用SDK API | SDK自动采集所有用户交互事件 | 通过后台圈选页面元素，动态配置 |
| 灵活性 | 最高，可携带任意自定义参数 | 低，只能采集通用事件属性 | 中等，依赖页面结构和CSS选择器 |
| 开发成本 | 高，每次需求变更都要发版 | 低，接入一次即可 | 中等，需要搭建圈选平台 |
| 数据准确性 | 高，逻辑由开发者控制 | 中等，容易采集到无效或重复事件 | 中等，页面改版后容易失效 |
| 适用场景 | 核心业务路径、关键转化节点 | 用户行为探索、漏斗分析初筛 | 运营活动、快速验证假设 |
我的建议：不要只用一种方案。我经手的项目，通常采用「代码埋点为主 + 全埋点为辅」的组合策略。核心业务用代码埋点保证质量，探索性分析用全埋点兜底。
代码埋点：最笨，但也最可靠
代码埋点，就是你在业务代码里手动调用采集接口。比如用户点击了「加入购物车」按钮，你就写一行 track('add_to_cart', { sku_id, price })。
我在项目中遇到过最典型的坑：埋点代码和业务代码耦合太紧。有一次重构页面，顺手删了一段「看起来没用」的埋点调用，结果整个加购漏斗数据断了三天。嗯，从那以后我强制团队用AOP（面向切面编程）或者装饰器模式来解耦。
避坑指南：我曾经见过一个团队，每个按钮点击事件里都写三行埋点代码。后来需求变了，要加一个参数，得改几十个文件。我的做法是：封装一个统一的埋点工具函数，业务方只需要传事件名和关键参数，其他公共属性（设备信息、页面路径等）由工具函数自动补充。
全埋点：省事，但别指望它解决所有问题
全埋点，也叫无埋点。SDK接入后，自动采集所有点击、页面浏览、滚动等事件。听起来很美好对吧？
但实际用起来你会发现：数据量大得吓人，但真正有用的不多。你想想看，用户在一个页面上随便点了个空白区域，SDK也会上报一条事件。这些噪音数据进了Kafka，占带宽、占存储，最后还得写ETL去过滤。
我个人习惯：全埋点只用来做用户行为热力图和初步的漏斗探索。一旦确认了关键路径，立刻转成代码埋点来精细化采集。
注意：全埋点采集到的数据，事件命名通常是自动生成的（比如 click_btn_123），可读性极差。我建议在SDK层面加一层映射表，把自动生成的事件名映射成业务语义的名称，否则后面分析的时候你会疯掉。
可视化埋点：运营同学的利器
可视化埋点，就是运营或产品经理在后台页面上「圈选」元素，系统自动生成埋点配置。比如圈一下「立即购买」按钮，系统就知道要采集这个按钮的点击事件。
这种方案最大的好处是不需要开发介入，运营同学自己就能配。但问题也很明显：页面结构一变，圈选就失效。我记得有一次前端改了按钮的CSS类名，结果所有可视化埋点配置全部失效，数据断了整整一周才排查出来。
所以我的建议是：可视化埋点只用于短期运营活动或快速验证，不要用在核心长期指标上。
数据格式设计：JSON Schema 是底线
不管选哪种埋点方案，最终数据都要落到一个统一的格式里。否则下游消费数据的同学会骂娘的。
我个人强烈推荐使用JSON Schema来约束数据格式。为什么？因为它是事实标准，Kafka Connect、Flink、Spark都能原生支持。
下面是我在一个电商项目中用过的行为流数据Schema，你可以直接拿来改：
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "行为流事件",
"type": "object",
"required": ["event_id", "event_type", "timestamp", "user_id", "properties"],
"properties": {
"event_id": {
"type": "string",
"description": "全局唯一事件ID，UUID格式"
},
"event_type": {
"type": "string",
"description": "事件类型，如 page_view, click, add_to_cart, purchase"
},
"timestamp": {
"type": "integer",
"description": "事件发生时间戳，毫秒级Unix时间戳"
},
"user_id": {
"type": "string",
"description": "用户唯一标识"
},
"device_info": {
"type": "object",
"properties": {
"platform": { "type": "string", "enum": ["web", "ios", "android"] },
"browser": { "type": "string" },
"os_version": { "type": "string" }
}
},
"page": {
"type": "object",
"properties": {
"page_url": { "type": "string" },
"page_title": { "type": "string" },
"referrer": { "type": "string" }
}
},
"properties": {
"type": "object",
"description": "事件自定义属性，不同事件类型携带不同字段",
"properties": {
"sku_id": { "type": "string" },
"price": { "type": "number" },
"quantity": { "type": "integer" },
"category": { "type": "string" }
}
}
}
}
核心原则：公共字段（event_id、timestamp、user_id、device_info）所有事件共享，差异化的业务字段放在 properties 对象里。这样既保证了结构统一，又保留了灵活性。
埋点方案与数据格式的整体关系
为了让你更直观地理解这三者之间的关系，我画了一张图：
从这张图你可以看到：不管上游用哪种方式采集，最终都要落到统一的JSON Schema里，再进入Kafka。这样做的好处是，下游的实时计算、离线数仓、数据服务都不需要关心数据是怎么来的，只管消费就行。
我的经验：Schema定下来之后，一定要用工具做兼容性校验。我见过最惨的一次，有人往properties里塞了一个嵌套五层的对象，结果下游Flink任务直接OOM。后来我们强制要求：properties里最多两层嵌套，且所有字段必须声明type。
小结一下
埋点方案没有标准答案，但有几个原则你可以记住：
- 核心业务用代码埋点，保证数据质量和可控性
- 探索性分析用全埋点，快速覆盖，但要做好噪音过滤
- 运营活动用可视化埋点，灵活配置，但别依赖它做长期指标
- 数据格式统一用JSON Schema，公共字段和业务字段分离，下游消费才不痛苦
嗯，这一块内容不少，但都是实打实的经验。你先把这三种方案的区别吃透，后面讲到Kafka数据接入的时候，你就知道该怎么选型了。