分析与监控

这个类别解决什么问题

让你知道用户实际做了什么、在哪一步放弃、以及线上什么时候出了问题。

什么时候需要

最晚在第一次把产品交付给真实用户时。更早接入的成本通常更低。

选择时看哪些指标

这些是评估这类服务时通用的判断维度，不针对任何具体厂商。

• 是否使用 Cookie（影响隐私合规与同意提示）
• 数据保留期限与导出能力
• 错误监控是否区分前后端
• 告警方式
• 采样与用量计费

中国开发者特别需要考虑什么

分析脚本的加载速度会直接影响页面性能；面向中国大陆用户时，境外脚本的加载失败可能拖慢首屏。

这一层的成本结构

分析层的成本分三块。一是事件量，按月计入的埋点事件通常分档计价，超出档位后单价下降但存在最低消费；二是数据保留期限，长保留一般只在更高档位提供；三是错误监控的错误事件量，可用采样压低。自托管方案把订阅费换成服务器与运维时间，服务器是固定成本，而升级、备份和扩容消耗的是你的工时。容易被推高的是事件量，因为「每个按钮都埋一个点」会在几个月内把用量抬高一个数量级。

常见误区

• 一上来埋几十个事件，却没人事先写清要看哪几个数。先定义三个关键指标，围绕它们埋点，其余指标等真的需要时再补上。
• 用产品分析替代错误监控。分析脚本看不到 500 报错、慢接口和队列堆积，两类工具职责不同，缺掉一个就会长期摸黑排查问题。
• 不量脚本体积就接入。第三方脚本加载慢或失败会拖住首屏，先测一次接入前后的加载时间差，再决定把它放在页面的哪个位置。

从零开始的上手顺序

1. 先写下一句你要回答的问题，例如「注册页到付费页在哪一步流失」。没有对应问题的仪表盘不会有人打开。
2. 接入一个轻量分析脚本，只打通注册、关键动作和付费三个事件，先看转化漏斗，不要一次全部铺开。
3. 同一天接入错误监控，前后端各接一处，人为制造一个报错，确认从出错到收到告警的整条链路真的通。
4. 把告警发到你每天都会看的渠道，另外设一个每日汇总邮件，避免只盯实时告警而错过长期趋势。

在不同业务模式中的作用

常见问题