1. 行为流概述:什么是用户行为流、行为流采集的价值、常见采集场景

大家好,我是这次课程的主讲。做了这么多年大数据,我越来越觉得——行为流是数据工程的起点。你想想看,没有行为流,推荐系统拿什么学?AB 实验拿什么算?用户画像拿什么画?

所以第一章,咱们先把行为流这件事聊透。不急着上代码,先把概念、价值、场景理清楚。后面再动手,心里才有底。

1.1 什么是用户行为流

说白了,用户行为流就是用户在产品上的一系列操作记录。按时间排好队,就成了流。

举个例子。你在电商 App 上搜“机械键盘”,点进第三个商品,看了两分钟,加购物车,最后下单。这一串动作——搜索 → 点击 → 浏览 → 加购 → 下单——就是一条完整的行为流。

每条行为记录,通常包含几个核心字段:

字段 含义 示例
userId 谁做的 u_10086
event 做了什么 product_click
targetId 对什么做的 sku_45231
timestamp 什么时候做的 1712563200000
properties 附加属性 {"page":"search_result","position":3}

嗯,这里要注意:行为流 ≠ 日志。日志是服务器视角,记录的是请求和响应。行为流是用户视角,记录的是意图和动作。两者有交集,但不能划等号。

核心认知:行为流是“人”的叙事,日志是“系统”的流水。做采集时,心里要始终装着用户的操作路径,而不是后端接口的调用链。

1.2 行为流采集的价值

我经常跟团队说一句话:不采集行为流,大数据项目就是空中楼阁。为什么?

  • 理解用户:光看注册量、DAU 这些宏观指标,你根本不知道用户为什么来、为什么走。行为流能告诉你每一步的真相。
  • 驱动产品迭代:我记得有个项目,产品经理坚持要改首页布局。我拉了一周的行为流数据一看——80% 的用户根本滑不到那个位置。改了个寂寞。
  • 支撑算法:推荐、搜索、广告,哪个离得开行为序列?没有行为流,模型只能“盲猜”。
  • 实时监控与风控:刷单、爬虫、异常操作,行为流一上实时 pipeline,几分钟就能逮住。

我的经验:行为流采集不是“先采了再说”。我见过太多团队,埋点埋了一堆,最后 70% 的字段从来没被用过。开始之前,先想清楚你要回答什么问题。问题驱动采集,而不是采集驱动问题。

1.3 常见采集场景

不同业务,行为流的“味道”不一样。我挑两个典型场景聊聊。

电商场景

电商的行为流,特点是路径长、漏斗深、决策重。一个用户从搜到买,中间可能经历十几次交互。

关键事件包括:

  • search — 搜索关键词
  • product_view — 浏览商品详情
  • add_to_cart — 加入购物车
  • checkout — 进入结算
  • payment_success — 支付成功
  • order_cancel — 取消订单

我曾经帮一个电商平台做流失分析。发现大量用户在“加购 → 结算”这一步流失。后来一查,是运费计算接口太慢,用户等不及就走了。行为流把这个问题钉得死死的。

内容平台场景

内容平台(短视频、资讯、社区)的行为流,特点是频次高、时长短、消费为主。用户刷一下可能就几秒钟,但一天能刷几百次。

关键事件包括:

  • feed_view — 信息流曝光
  • content_click — 点击进入内容
  • content_read — 阅读/观看(带时长)
  • like / comment / share — 互动
  • follow — 关注作者

避坑提醒:内容平台的行为流,曝光事件最容易造假。我曾经遇到一个 case,客户端上报的 feed_view 比服务端统计的请求数多了 3 倍。后来发现是预加载机制导致重复上报。嗯,这里一定要做去重和校验。

1.4 行为流采集的整体架构

聊完概念和价值,咱们看看行为流采集在技术架构里长什么样。下面这张图,是我自己项目里常用的分层结构。

行为流采集整体架构 用户行为层 App / Web / 小程序 / 服务端 → 产生原始事件 采集接入层 SDK 埋点 / 服务端上报 / 日志采集 → 统一收口 消息队列层(Kafka) 削峰填谷 / 解耦生产消费 / 持久化保障 消费处理层 实时 ETL / 数据湖写入 / 实时数仓 / 风控引擎 Kafka 是整条链路的“中枢神经”

你看,从用户行为产生,到最终被消费使用,中间Kafka 扮演了核心的缓冲和分发角色。这也是为什么这门课叫《行为流采集与 Kafka 实战》——两者天然绑定。

一句话总结:行为流采集,就是把用户“在做什么”这件事,变成可计算、可回溯、可实时处理的数据资产。没有它,大数据项目就像没有地基的房子——看着漂亮,一推就倒。