第2章行为数据采集实战

第二章：行为数据采集实战

大家好，我是老张。今天咱们聊聊数据采集这个环节。

说实话，很多团队在数据采集上栽过跟头。我见过最夸张的项目，埋了300多个事件，结果上线后发现一半数据对不上。为什么？因为埋点设计出了问题。

这一章，我会把我在多个项目中踩过的坑、总结的经验，一次性讲清楚。

2.1 埋点设计原则

先说说原则。很多人一上来就写代码，这是大忌。

我个人习惯，先画一张图，把用户行为路径理清楚。比如用户从首页到详情页，再到下单，每一步都对应什么事件。

核心原则就三条：

唯一性：每个事件有且只有一个ID，别搞重复
可追溯：能通过事件ID反查到埋点位置和业务含义
低侵入：埋点代码不能影响业务逻辑

我在项目中遇到过最头疼的事：产品经理说「我要看用户点击了哪个按钮」，结果开发埋了10个不同的事件ID，每个都叫「按钮点击」。你想想看，这数据怎么分析？

所以，我建议团队用统一的命名规范。比如：

# 事件命名格式
[页面]_[模块]_[动作]_[状态]

# 示例
home_banner_click_success
detail_addcart_click_fail
pay_confirm_click_loading

嗯，这里要注意：事件名不要超过5个层级，否则维护成本太高。

2.2 前端埋点

前端埋点，说白了就是在用户浏览器或App里埋代码。主要有两种方式：代码埋点和全埋点。

2.2.1 代码埋点

这是最传统的方式。开发人员在需要采集的地方手动写一行代码。

// 代码埋点示例
document.getElementById('buy-btn').addEventListener('click', function() {
  track('detail_buy_click', {
    productId: '12345',
    price: 99.9,
    source: 'recommend'
  });
});

优点很明显：精准、可控。缺点嘛，你想想看，如果业务逻辑改了，埋点代码也得跟着改。我曾经维护过一个老项目，光埋点代码就占了整个JS文件的30%。

我的建议：

代码埋点适合核心业务路径，比如注册、下单、支付。这些事件不能丢，必须精确采集。

2.2.2 全埋点

全埋点也叫无埋点。原理是自动监听所有用户交互事件，比如点击、滑动、输入。

// 全埋点示例（伪代码）
document.addEventListener('click', function(e) {
  const target = e.target;
  const path = getElementPath(target);  // 获取DOM路径
  const text = target.innerText || '';
  
  track('auto_click', {
    path: path,
    text: text,
    timestamp: Date.now()
  });
});

全埋点的好处是「一次接入，永久生效」。但问题也很明显：数据量巨大，而且很多数据其实没用。

我记得有个客户，全埋点上线后每天产生10亿条事件，但真正有用的不到1%。服务器成本直接翻了三倍。

避坑指南：

我曾经在金融项目中全埋点，结果把用户的密码输入框内容也采集了。虽然我们做了脱敏，但合规部门还是找上门了。所以，全埋点一定要做白名单过滤，敏感区域绝对不能采集。

2.3 后端埋点

后端埋点，也叫日志采集。说白了，就是在服务器端记录用户请求。

为什么需要后端埋点？因为前端数据可能丢失。比如用户网络断了、浏览器崩溃了，前端事件就发不出去。但后端日志是可靠的，只要请求到达服务器，就能记录下来。

2.3.1 日志格式设计

我个人习惯用JSON格式，方便解析。比如：

{
  "event": "order_create",
  "user_id": "u12345",
  "timestamp": 1700000000,
  "properties": {
    "order_id": "ord_67890",
    "amount": 199.9,
    "payment_method": "wechat"
  },
  "extra": {
    "ip": "192.168.1.1",
    "user_agent": "Mozilla/5.0..."
  }
}

这里要注意：日志里不要存敏感信息，比如密码、身份证号。我曾经见过有人把用户手机号直接写进日志，结果被安全部门通报了。

2.3.2 日志采集架构

下面这张图是我常用的日志采集架构：

这个架构我用了很多年，核心思路是：

应用服务器写本地日志文件
Filebeat实时采集日志，发送到Kafka
Kafka作为缓冲，防止数据丢失
数据处理服务消费Kafka，清洗后写入数据仓库

经验之谈：

Kafka的Topic分区数建议设置为服务器数量的2倍。比如你有10台服务器，分区数设20。这样能保证负载均衡，不会出现某台服务器压力过大。

2.4 前端 vs 后端：怎么选？

很多新手会问：到底用前端埋点还是后端埋点？

我的答案是：两个都要。

场景	推荐方式	原因
用户点击行为	前端埋点	后端不知道用户点了哪里
页面停留时长	前端埋点	需要浏览器端计时
订单创建	后端埋点	保证数据不丢失
支付结果	后端埋点	前端可能被篡改
性能监控	前端+后端	两端数据对比才能定位问题

举个例子：用户下单了，前端发了一个事件，后端也记录了一条日志。如果两边数据对不上，说明有问题。我曾经靠这个办法，发现过一个前端SDK的bug——它在某些浏览器下会丢失事件。

重要提醒：

前后端数据对账是必须的。我建议每天跑一次对账脚本，差异超过1%就要报警。别问我为什么知道，问就是吃过亏。

2.5 实战：一个完整的埋点方案

最后，我分享一个我在电商项目中用过的埋点方案。这个方案支撑了日活500万的App，数据准确率99.9%。

核心思路：

核心业务事件用代码埋点（前端+后端双写）
UI交互事件用全埋点（只采集点击和滑动）
所有事件统一ID，统一格式
每天做数据质量监控

嗯，这里有个小技巧：全埋点的事件，我会加一个「auto_」前缀，方便和手动埋点区分。这样在数据分析时，一眼就能看出数据来源。

好了，这一章的内容就到这里。记住一句话：数据采集是地基，地基不稳，楼盖得再高也会塌。

公众号:蓝海资料掘金营，微信deep3321