PostHog 的核心原理

“事件驱动的数据采集 + 本地部署的分析系统 + 全栈可观测能力”

下面是对 PostHog 工作原理的详细拆解，从 架构层次 到 数据流转流程，并涵盖其核心模块。

---

架构总览

PostHog 通常由以下几个关键组件构成：

用户前端 → PostHog JS SDK / API → Ingestion Pipeline → Kafka（事件队列）
                    ↓
         PostgreSQL / ClickHouse（事件存储）
                    ↓
       后端处理服务 + 插件系统 + 分析引擎
                    ↓
              Web UI / API 输出结果

---

数据采集流程（事件驱动）

1. 事件采集

• 前端页面通过 posthog.js SDK 或移动端 SDK 自动采集：
• 点击事件、表单提交、页面访问、滚动等
• 或手动埋点调用 posthog.capture('event_name', properties)
• 服务端也可以通过 API 发送自定义事件（如注册成功、订单支付等）

2. 数据上报

• 所有事件被统一发送到 PostHog 的 事件摄取服务（Ingestion Service）
• 摄取服务做基础清洗和格式规范后，将事件写入 Kafka 或直接传送到 ClickHouse

---

数据存储与处理

3. 事件入库

• 默认使用 ClickHouse 存储事件数据（高性能列式数据库）
• 用户信息、元数据等保存在 PostgreSQL 中

4. 处理与插件

•插件系统可以在事件流转过程中执行任意逻辑：
• 增强属性（如 IP 转换为城市）
• 发送 webhook
• 写入外部系统（如 S3、BigQuery）

5. 分析与建模

•后端使用 ClickHouse 的 SQL 引擎进行：
• 漏斗分析
• 路径分析
• 用户分群
• 转化率计算
• 实验组/对照组差异分析

---

前端可视化与查询

6. 展示结果

• PostHog 的 Web UI 是基于 React 构建的前端仪表盘
• 所有数据支持：
• 图表展示（折线图、饼图、漏斗图等）
• 动态筛选
• 下载导出或 API 访问

7. Session Replay（会话回放）

•SDK 会自动记录用户 DOM 操作行为，存储成压缩帧数据
• 后端解码回放 DOM 和鼠标轨迹，实现完整操作还原

---

关键原理总结

原理	说明
事件驱动架构	一切以用户事件为基本单位采集和分析
ClickHouse 存储引擎	高并发、高吞吐、支持复杂分析
Kafka 消息流（可选）	提高系统解耦与扩展性
插件处理链	类似中间件机制，可拦截或增强事件流
自托管架构	用户控制所有数据，符合 GDPR/合规要求
Session Replay 编码	使用 DOM diff + 滚动轨迹压缩算法

---

模块级别图（简化）

[PostHog SDKs]
     ↓
[Ingestion Service] --→ [Plugin System] → [ClickHouse]
     ↓
[Analysis Engine]
     ↓
[Web UI / API]