AI产品Web流量监测与增长分析搭建教程

一、教程目标
本教程最终交付三样东西：一套口径明确的指标定义、一条从采集到看板的完整数据链路、一套可执行的异常排查手册。完成后，你可以回答以下问题：某产品本月访问量是多少、环比是涨还是跌；这个涨跌是真实用户行为变化，还是埋点、口径或机器流量造成的假象；哪些入口（对话页、模型体验页、文档页、编辑器类工具页）真正贡献了增量。

需要强调的是：增长分析的价值不在于”数字”，而在于”数字之间的可解释性”。当头部通用对话类产品出现环比小幅下滑、而集成在既有生产力生态中的模型类产品出现两位数增长时，如果没有统一口径与分维度下钻能力，这类结论只能停留在猜测层面。

二、适用读者与适用场景
适合三类读者：负责产品埋点与数据链路的开发者；负责数据质量、指标一致性与看板建设的运维/数据工程师；需要判断技术投入产出的技术负责人。

典型场景包括：AI 产品的月度增长复盘；新模型或新能力上线后的效果评估（例如图像生成能力、长上下文推理能力开放后带来的访问增量）；API 与智能体调用流量的成本归属分析；内部 AI 工具的活跃度与使用深度度量；以及构建行业观察类榜单时所需的口径设计。

三、前置准备
1）基础环境：可运行前端脚本的 Web 站点；可写入的日志或对象存储（业界通用做法是接入云厂商的对象存储与日志服务）；具备消息队列用于削峰；具备数据仓库或列式查询引擎用于聚合。
2）权限与账号：站点代码仓库的发布权限；域名与传输证书配置权限；数据仓库的读写权限；监控告警的接收渠道配置权限。若企业使用统一的身份认证与访问控制体系，需先申请对应资源的授权。
3）数据基础：明确站点结构清单（URL 路由、页面类型、是否单页应用）；明确用户标识策略（登录用户 ID、匿名设备标识，需做去标识化处理）。
4）基础知识：了解会话（session）切分逻辑、PV/UV/MAU 的区别、环比与同比的计算方式、机器人流量识别的基本思路。

四、指标体系与口径设计（先定口径，再写代码）
口径不统一是所有增长分析争议的根源。建议在动手采集前先固化下面这张表：

• 访问量（PV）：页面浏览事件总数，同一用户重复访问累计计数。
• 独立访客（UV/去重人数）：按日、按去标识化后的用户键去重。
• 会话数：用户连续行为序列的数量，默认 30 分钟无新事件即切分为新会话。
• 月活（MAU）：统计月内去重活跃用户，需明确”活跃”的最小事件定义（例如至少一次成功会话，而非任意页面加载）。
• 人均会话数、人均页面数、跳出率：衡量使用深度。
• 环比增速：本月指标相对上月的百分比变化，需明确是否按自然月、是否做日均化处理（2 月与 3 月天数不同，不日均化会产生系统性偏差）。

另外要区分两个统计层面：客户端埋点适合行为分析（点击、路径、停留），服务端日志适合可信计数（请求成功数、接口调用量）。关键总量指标建议以服务端为基准，用客户端埋点做行为下钻，两侧差异做常态化对账。

五、实施步骤
步骤 1：建立站点与事件清单
做什么：列出需要监测的站点标识、页面类型与关键事件（进入对话、发起生成请求、请求成功、请求失败、导出结果）。
为什么：站点标识（site_key）是所有下钻维度的主键，缺失会导致后续无法区分”总流量增长来自哪个入口”。
注意：事件命名一次性定义并纳入版本管理，避免不同团队各写一套命名。

步骤 2：设计前端采集方案
做什么：在页面统一初始化一个采集脚本，自动上报页面浏览，手动上报业务事件；页面关闭时使用浏览器提供的可靠发送接口，避免请求被中断。
为什么：异步与批量上报能显著降低对页面性能的影响；关闭页面时的可靠发送能减少会话尾部事件丢失。
注意：必须在初始化阶段处理”不采集”开关（用户同意管理、内网调试模式），并把采集域名与端点做成构建期注入的配置项，不要硬编码在业务代码里。

示意性代码（通用实现，域名与端点为占位符）：

<script>
(function () {
  if (!window.__ANALYTICS_ENABLED__) return;      // 由配置或用户同意状态控制
  var cfg = window.__ANALYTICS_CFG__;
  var queue = [];
  function push(type, payload) {
    queue.push(Object.assign({
      site: cfg.siteKey,
      type: type,
      ts: Date.now(),
      path: location.pathname,
      ref: document.referrer,
      sid: cfg.buildId                        // 埋点/前端版本号，用于问题回溯
    }, payload || {}));
    if (queue.length >= cfg.batchSize) flush(true);
  }
  function flush(useBeacon) {
    if (!queue.length) return;
    var body = JSON.stringify({ events: queue.splice(0, queue.length) });
    if (useBeacon && navigator.sendBeacon) {
      navigator.sendBeacon(cfg.collectEndpoint, body);
    } else {
      fetch(cfg.collectEndpoint, {
        method: 'POST', keepalive: true,
        headers: { 'Content-Type': 'application/json' },
        body: body
      }).catch(function () { /* 失败即丢弃，不阻塞主流程 */ });
    }
  }
  window.__track = push;
  push('page_view', {});
  setInterval(function () { flush(false); }, cfg.flushIntervalMs);
  document.addEventListener('visibilitychange', function () {
    if (document.visibilityState === 'hidden') flush(true);
  });
})();
</script>

步骤 3：搭建服务端采集与接入
做什么：采集服务只做三件事——校验、轻量落盘、投递消息队列；随后由消费端写入数据仓库。落盘同时保留原始明细与按小时聚合的中间表。
为什么：采集链路要短。任何在采集端做复杂计算的方案都会在流量高峰时成为瓶颈；消息队列负责削峰，保证后端写入速率可独立伸缩。
注意：采集服务需做字段白名单与长度限制，防止异常请求把日志打爆；写入要幂等（以事件唯一 ID 去重），因为重试不可避免。

步骤 4：数据清洗与去标识化
做什么：过滤机器人流量、剔除内部测试流量、去标识化用户标识、修正时区与日切。
为什么：这是”环比暴跌 30%”与”其实只是统计口径变化”的分水岭。
注意：机器人过滤建议同时使用三类信号——用户代理特征、请求频率分布、是否执行前端脚本（纯服务端可见但无前端事件的请求高度可疑）。用户标识一律使用加盐哈希，且盐值定期轮换，避免长期稳定的跨表关联。

步骤 5：会话切分与指标聚合
做什么：按用户与事件时间排序，用”间隔超过阈值即新会话”的规则打上会话序号，再按站点、日期、页面类型聚合。
为什么：人均指标与留存分析都依赖会话粒度，直接对 PV 做归因会严重高估。

-- 会话切分：默认 30 分钟无事件视为新会话
WITH base AS (
  SELECT user_key, event_time, page_type, is_bot
  FROM dwd_ai_web_event
  WHERE dt BETWEEN '${start_date}' AND '${end_date}'
    AND is_bot = 0 AND is_internal = 0
),
marked AS (
  SELECT *, LAG(event_time) OVER (PARTITION BY user_key ORDER BY event_time) AS prev_time
  FROM base
),
segmented AS (
  SELECT *, SUM(CASE WHEN prev_time IS NULL
      OR TIMESTAMPDIFF(MINUTE, prev_time, event_time) >= 30
      THEN 1 ELSE 0 END)
    OVER (PARTITION BY user_key ORDER BY event_time) AS session_seq
  FROM marked
)
SELECT CONCAT(user_key, '_', session_seq) AS session_id,
       MIN(event_time) AS session_start,
       MAX(event_time) AS session_end,
       COUNT(*) AS event_cnt
FROM segmented
GROUP BY 1;

步骤 6：计算环比并识别异常
做什么：生成站点粒度的日/月聚合表，计算环比，并用稳健统计方法做异常检测。
为什么：固定阈值（如”下跌 10% 就报警”）在流量体量差异大的站点上必然误报；基于中位数与绝对中位差的稳健 z 值能同时适应大小站点。

WITH m AS (
  SELECT DATE_FORMAT(stat_date, '%Y-%m') AS ym, site_key,
         SUM(pv) AS pv, COUNT(DISTINCT user_key) AS uv
  FROM dws_ai_site_daily GROUP BY 1, 2
)
SELECT ym, site_key, pv, uv,
  ROUND((pv - LAG(pv) OVER (PARTITION BY site_key ORDER BY ym)) * 100.0
        / NULLIF(LAG(pv) OVER (PARTITION BY site_key ORDER BY ym), 0), 1) AS pv_mom_pct
FROM m ORDER BY site_key, ym;

# 稳健异常判定伪代码（按站点独立计算）
series = last_n_days_daily_pv(site_key, 30)
med = median(series)
mad = median(abs(x - med) for x in series)
for x in last_7_days(series):
    rz = 0.6745 * (x - med) / max(mad, 1)
    if abs(rz) > 3.5:
        mark_candidate(site_key, x)
# 仅当异常连续持续 >= 3 天才升级为告警，单日抖动只记录不告警

步骤 7：分层看板与告警
做什么：看板分三层——总量层（PV/UV/MAU 与环比）、结构层（按页面类型、来源、地区、终端下钻）、明细层（异常时段的路径级明细）。告警区分”数据管道故障”与”业务指标异动”两类，前者优先。
为什么：增长问题必须先排除数据问题，告警分层能避免把管道故障误判为业务下滑。

步骤 8：把监测范围扩展到接口与智能体流量
做什么：为接口调用、模型请求、智能体任务建立独立的事件流，指标改为”调用次数、成功请求占比、平均处理时长、单位请求资源消耗”，并与站点访问量建立关联维度（同一用户键）。
为什么：当一个产品的负载从”页面聊天”转向”代码生成、长链推理、多步任务执行”时，仅靠浏览器标签页的访问量会系统性低估实际使用强度。这一点在做容量规划与成本归因时尤其重要。

六、配置说明（通用配置项）

• 采样率：小于 1 时对总量指标按比例放大，但比率类指标（跳出率、转化率）不受采样影响更大。高流量站点建议全量采集关键转化事件、对页面浏览做采样。
• 会话超时：默认 30 分钟。对话类产品若用户常长时间思考，可放宽到 60 分钟；过短会把一次深度使用拆成多会话，导致人均会话数虚高。
• 日切时区：统一使用一个时区（建议标准时间）并在所有层级一致，混用会直接导致日环比出现假峰假谷。
• 上报批量大小与间隔：过小增加请求开销，过大在页面快速关闭时丢数据；需与关闭时的可靠发送策略配合。
• 机器人过滤强度：过强会误杀自动化访问的正常用户，过弱会让总量虚高；建议先观察模式（只标记不剔除）一到两周再切换到强制剔除。
• 埋点版本号：随每次前端发布递增，是排查”某次发布后流量骤降”的第一手线索。

七、结果验证
1）采集自测：在调试模式下本地回显上报内容，确认事件字段完整、无重复、时间戳正确。
2）链路对账：以一天为周期，比对采集服务收到的事件数、消息队列消费数、数据仓库写入数，三者差异应稳定在很小的比例内；差异持续扩大说明消费端存在积压或丢弃。
3）口径交叉验证：服务端请求成功率与客户端”请求成功”事件数量做趋势比对，两条曲线趋势应一致；若客户端明显偏低，通常是脚本被拦截或路由变更导致漏报。
4）看板抽样核验：随机抽取一个站点一天的数据，与明细日志手工统计结果比对。
5）告警演练：人为构造一次指标异动，确认告警能在预期时间内送达，且不会因单日抖动误报。
6）外部差异说明：与外部监测机构的公开数字存在差异是正常现象，需在报告里写清差异原因（是否含应用内流量、是否剔除机器人、月活定义不同），而不是修改自己的口径去凑数。

八、常见问题与排查
1）某次前端发布后流量断崖式下跌：优先核对采集脚本是否被打包优化移除、初始化开关是否被配置误关、采集端点是否变更未同步到构建配置、路由改为单页应用后是否漏掉路由变更事件。排查顺序是”看埋点版本分布 → 看事件类型分布 → 看具体页面明细”。
2）UV 明显偏高：多为匿名标识过早重置（多域名共享、无痕模式、脚本被浏览器隐私插件拦截导致标识生成失败）。建议对标识生成失败的请求单独统计，作为数据质量指标纳入看板。
3）PV 正常但会话数异常偏高：会话超时设置过短，或心跳事件缺失导致长时间静默被切分。
4）月活环比与访问量环比方向相反：通常是偶发单页访客（如从内容页一次性进入）拉高了访问量但未形成有效会话。此时应把”有效会话”作为月活的最小定义。
5）总量增长但人均使用深度下降：说明增量来自低意向流量，需要结合来源与落地页维度判断投放或收录结构变化。
6）跨端数据对不上：应用内嵌页、桌面端封装壳、浏览器直访三类流量的上报能力不同，必须分别建模后再汇总，否则任何总量结论都不可信。
7）数据管道高峰积压：采集端不要在请求路径上做重计算，改为”校验后立刻入队”，把聚合压力放到离线或近实时计算层。

九、优化建议
性能方面：采集脚本异步加载、批量上报、关闭页面走可靠发送；看板查询一律走预聚合表，避免对明细表做实时全扫描。
安全合规方面：字段白名单、传输加密、用户标识加盐去标识化、按最小必要采集，敏感内容（用户输入的提示词原文等）不入库；数据仓库按角色做访问控制并保留审计记录。
稳定性方面：采集服务无状态化并可水平扩容，消息队列作为缓冲，消费端幂等写入，原始明细长期留存以便口径变更后重算历史数据。
可维护性方面：把指标口径写成随代码评审的文档，事件字典与埋点版本绑定；口径变更时同时提供新旧两套计算结果过渡一段时间，避免历史曲线断点。
成本方面：分层存储（原始明细短期热存、聚合结果长期留存）、按访问频率设置冷热分离、对低价值明细采样；接口与智能体调用这类高成本事件应按用户或租户维度归属，便于成本分摊与配额管理。

十、总结
本教程的核心结论是：AI 产品的流量分析必须先解决”口径与数据可信”，再谈”增长解释”。关键路径是四步——固化指标定义、建立客户端与服务端双通道采集、完成清洗与会话切分、输出分层看板与分层告警。当你要判断”头部产品为何放缓、生态内产品为何提速”这类问题时，正确的做法不是调整结论，而是用站点维度、页面类型维度、来源维度逐层下钻，并用埋点版本与链路对账排除数据因素。

后续可继续深入的方向：把监测范围从页面流量扩展到接口与智能体任务调用，建立访问量与算力消耗的关联模型；引入留存与队列分析，区分”新客涌入”与”真实习惯形成”；以及为模型能力上线建立标准化的效果评估流程，让每次能力开放都能对应到可验证的使用指标变化。