用户行为日志分析系统：从埋点到指标查询

用户行为日志记录的是用户在产品里的动作。页面访问、按钮点击、搜索、曝光、加购、下单、支付，这些事件串起来，就能还原用户路径和业务转化。

一个好的行为日志系统，不只是为了做报表。它还可以支撑增长分析、A/B 实验、推荐系统、风控策略和产品决策。

行为日志系统解决什么问题

最基础的是统计 PV、UV、DAU、留存、转化率。

更进一步，可以分析用户从进入页面到下单支付的路径，找到流失最多的环节。

再进一步，可以把行为数据提供给推荐、搜索排序、用户画像和营销系统。

但这些价值的前提是：事件定义清晰，字段稳定，采集链路可靠，指标口径一致。

整体架构

一套常见链路是：

前端 / App / 服务端
        ↓
埋点 SDK / 日志网关
        ↓
      Kafka
        ↓
清洗任务 / Flink / 离线任务
        ↓
  OLAP 数据库 / 数据仓库
        ↓
  BI / 指标平台 / 实验平台

Rendering diagram...

前端和 App 负责采集用户操作，服务端负责采集业务事件。日志网关负责接收和校验，Kafka 负责缓冲，计算任务负责清洗和聚合，OLAP 数据库负责查询。

事件模型设计

行为日志最重要的是事件模型。一个通用事件可以包含：

event_id
event_name
user_id
device_id
session_id
timestamp
page
referer
platform
app_version
ip
user_agent
properties

event_name 表示事件类型，比如 page_view、button_click、search、add_to_cart、pay_success。

properties 保存事件特有属性。搜索事件可以有关键词，点击事件可以有按钮 ID，商品曝光事件可以有商品 ID 和位置。

事件模型要稳定。字段今天叫 uid，明天叫 userId，后天叫 member_id，分析系统会很快失控。

一个埋点事件可以这样上报：

{
  "event_id": "evt_01HX",
  "event_name": "product_click",
  "user_id": "u_10001",
  "device_id": "d_abc",
  "session_id": "s_20260517_001",
  "timestamp": "2026-05-17T20:35:00+08:00",
  "page": "/product/sku_10001",
  "platform": "ios",
  "app_version": "3.8.0",
  "properties": {
    "sku_id": "sku_10001",
    "position": 3,
    "source": "home_recommend"
  }
}

客户端埋点和服务端埋点

客户端埋点能看到用户真实操作，比如页面停留、点击、滑动、曝光。但它容易受网络、版本、拦截器、客户端时间不准等问题影响。

服务端埋点更可靠，适合记录关键业务事件，比如下单成功、支付成功、退款成功。但它看不到所有用户界面行为。

最佳实践通常是两者结合。客户端记录行为路径，服务端记录权威业务结果。比如支付按钮点击由客户端记录，支付成功以服务端事件为准。

日志采集链路

客户端 SDK 不应该每条事件都立刻发请求。通常会批量上报，减少网络开销。

日志网关需要做基础校验，比如字段是否完整、事件名是否合法、时间戳是否异常、数据大小是否超限。

采集服务最好把原始日志先稳定写入 Kafka 或对象存储。即使后面的清洗逻辑出错，也能从原始数据重新处理。

数据清洗

清洗任务要做几类事情。

第一是字段标准化。统一时间格式、平台名称、版本号、页面路径和事件名。

第二是过滤脏数据。比如测试流量、机器人流量、字段缺失事件、明显异常时间戳。

第三是补充维度。通过 IP 解析地域，通过 User-Agent 解析设备，通过用户 ID 关联用户属性。

第四是身份合并。未登录时只有 device_id，登录后有 user_id，需要把匿名行为和登录用户关联起来。

OLAP 表设计

行为日志系统通常至少有一张原始事件明细表。

这张表应该按事件时间分区，常用过滤字段可以参与排序，比如 event_name、user_id、session_id、page。

在明细表之上，可以建设聚合表：

页面访问日汇总表。
用户活跃日汇总表。
漏斗步骤汇总表。
留存分析表。
搜索关键词汇总表。
商品曝光点击汇总表。

明细表保证灵活，聚合表保证性能。

事件明细表的 DDL 可以按 OLAP 思路设计：

CREATE TABLE behavior_events (
  event_date Date,
  event_time DateTime,
  event_id String,
  event_name LowCardinality(String),
  user_id String,
  device_id String,
  session_id String,
  page String,
  platform LowCardinality(String),
  properties String
)
ENGINE = MergeTree
PARTITION BY event_date
ORDER BY (event_name, event_date, user_id, session_id);

常见指标

PV 是页面访问次数。UV 是去重用户数。DAU 是日活跃用户数。

点击率通常是点击次数除以曝光次数。转化率通常是后一步人数除以前一步人数。

留存率看的是某天新增用户，在后续第 N 天是否仍然活跃。

平均访问时长、跳出率、搜索无结果率、加购率、支付成功率，都是行为日志里常见指标。

指标一定要有口径文档。比如 UV 是按 user_id 去重，还是 device_id 去重；支付转化率分母是点击支付按钮的人，还是提交订单的人。

漏斗分析

漏斗分析关注一组有顺序的行为。比如：

访问商品页 → 点击购买 → 提交订单 → 支付成功

做漏斗时需要定义时间窗口。用户今天看商品，三天后支付，是否算同一次漏斗，要提前约定。

还要定义去重规则。一个用户多次点击购买，是取第一次、最后一次，还是都算。

漏斗分析看起来简单，真正复杂的是事件定义、时间窗口和身份合并。

数据质量问题

行为日志最常见的问题不是数据库慢，而是数据不可信。

客户端可能重复上报，也可能因为网络失败丢事件。用户手机时间可能不准。不同版本 App 可能字段不一致。Bot 流量可能污染数据。埋点上线后也可能没有人验证。

因此行为日志系统需要数据质量监控。事件量突然下降、字段空值率升高、版本分布异常、核心事件缺失，都应该告警。

隐私与合规

不要采集不必要的敏感信息。手机号、身份证、精确地址、聊天内容等信息，如果不是分析必需，就不应该进入行为日志。

用户标识要尽量脱敏。数据访问要有权限控制。日志保留周期要明确。用户要求删除数据时，系统要有可执行方案。

小结

用户行为日志系统的核心不是 Kafka、Flink 或 ClickHouse，而是事件模型。

技术链路解决的是吞吐、延迟和查询效率。真正决定分析价值的，是埋点设计、字段标准、数据质量和指标口径。