📚 课程目录第3章流量与活跃度数据采集

3. 流量与活跃度数据采集

流量与活跃度分析的第一步不是建模，而是把“用户做了什么”稳定、完整、可追溯地记录下来。采集链路一旦失真，后续的漏斗、留存、归因都会变成“垃圾进、垃圾出”。本节围绕五类采集手段展开：埋点方案决定采什么，日志采集决定怎么落地，SDK上报决定客户端如何送达，服务端记录决定关键业务事实如何兜底，数据质量校验决定数据能不能被信任。

一、核心原理：一次用户行为如何变成一条可用数据

无论 Web 还是 APP，一次可分析的行为事件通常由四部分组成：Who（用户标识）、When（时间）、Where（页面/模块/位置）、What（动作与参数）。埋点方案负责定义这四要素的语义，SDK 负责在端上组装并上报，日志采集负责接收与落盘，服务端记录负责补齐订单、支付等强一致事实，质量校验则对全链路做一致性、完整性和时效性检查。

关键认知：客户端采集是“尽力而为”，服务端记录是“事实为准”。活跃度可以依赖客户端，但涉及金额、订单、权益的流量归因，必须以服务端记录为基准做校准。

二、埋点方案：从“想采”到“可采”

埋点方案不是罗列事件名，而是一份可执行的契约。推荐采用“事件模型 + 属性字典 + 上报时机”的三段式设计。

事件模型：采用“对象_动作”命名，如 page_view、button_click、order_submit，避免 click1 这类无语义命名。
属性字典：公共属性（用户ID、设备ID、会话ID、渠道、版本）与业务属性（商品ID、页面来源、活动位）分离管理，防止字段爆炸。
上报时机：曝光类用可见性触发，点击类用交互触发，支付类用服务端回调触发，避免“用户没看到也算曝光”。

埋点方案落地时，建议维护一份埋点登记表，把事件、触发条件、属性、负责人、验收状态固化下来，作为开发、测试、数据分析三方共同依据。

采集方式	典型数据	优势	主要风险
客户端埋点	点击、曝光、页面停留	粒度细、可解释交互	漏报、版本覆盖不全
日志采集	Nginx、网关、容器日志	全量、可回溯	格式杂乱、解析成本高
SDK上报	APP/小程序行为事件	统一协议、批量发送	弱网丢失、耗电与隐私
服务端记录	订单、支付、登录	准确、可审计	缺少前端上下文

三、日志采集与 SDK 上报：把数据送出去

日志采集常见链路是“采集器 → 消息队列 → 消费落盘”。以 Nginx 访问日志为例，先定义结构化格式，再交给采集器解析：

log_format analytics '$remote_addr|$time_iso8601|$request_method|$request_uri|'
                     '$status|$body_bytes_sent|$http_user_agent|$http_referer';
access_log /var/log/nginx/analytics.log analytics;

采集器侧通常配置解析规则与输出目标，例如将日志按行读取、按分隔符切分、写入 Kafka：

inputs:
  - type: filestream
    paths: [/var/log/nginx/analytics.log]
processors:
  - dissect:
      tokenizer: "%{ip}|%{ts}|%{method}|%{uri}|%{status}|%{bytes}|%{ua}|%{referer}"
output:
  kafka:
    hosts: ["kafka-1:9092"]
    topic: "web_traffic_raw"

SDK 上报则要解决三件事：批量（合并事件减少请求）、重试（弱网下本地缓存后补发）、去重（用事件ID保证幂等）。一个典型的上报参数如下：

{
  "app_id": "mall_app",
  "device_id": "d8f3...a1",
  "user_id": "u_10293",
  "session_id": "s_20240611_01",
  "events": [
    {"event": "page_view", "page": "home", "ts": 1718064000123},
    {"event": "button_click", "page": "home", "element": "banner_2", "ts": 1718064001456}
  ],
  "sdk_version": "2.4.1"
}

SDK 上报建议设置“前台实时 + 后台批量”的双通道：关键转化事件立即上报，普通曝光事件合并后延迟上报，兼顾时效与性能。

四、服务端记录与数据质量校验

服务端记录的核心价值是“事实锚点”。用户登录、下单、支付、退款等动作，应在服务端生成带唯一业务ID的记录，并与客户端事件通过 trace_id 或 session_id 关联。这样即使客户端漏报，也能通过服务端反推真实活跃与转化。

数据质量校验建议覆盖五个维度：

完整性：必填字段缺失率、事件量环比突降告警。
一致性：客户端订单事件与服务端订单表数量对账。
准确性：时间戳是否在合理区间、状态码是否合法。
唯一性：按事件ID去重，识别重复上报。
时效性：端到端延迟是否超过 SLA，如 5 分钟内可查。

常见误区：只看“总事件量”判断数据健康。总量正常但某渠道、某版本、某机型缺失，会直接导致分群分析结论错误。校验必须下钻到维度。

五、案例复盘：一次“活跃度虚高”的排查

某电商 APP 发现日活突然上涨 18%，但订单量未变。排查发现：新版本 SDK 在页面切换时重复触发 page_view，且未做去重。修复方式是引入 page_id + session_id 作为幂等键，并在服务端按会话聚合去重。复盘结论有三点：埋点方案要定义“同一页面多次进入”的语义；SDK 要有去重机制；质量校验要监控“人均事件数”这类比率指标，而不只是总量。

总结来看，采集体系的设计原则是：埋点有契约、日志有结构、上报有保障、服务端有锚点、校验有下钻。把这五件事做扎实，流量与活跃度分析才有可靠的地基。