App 埋点不是记录点击，而是建立诊断系统

埋点不是把每个按钮都打上 tag

我不把埋点理解成给 App 装摄像头。摄像头会让人误以为看见了一切，但产品决策真正需要的是诊断：用户在哪一步没有得到预期价值，原因可能是什么，下一步该改哪里。

最常见的失败做法，是上线前临时问研发能不能把所有点击都打一下。结果事件很多，命名不统一，漏了曝光和失败状态，最后只能看按钮点击量。点击量上涨不一定是好事，可能是用户反复找不到入口；转化率下降也不一定是坏事，可能是入口变准了，低意愿用户被过滤掉了。埋点要先服务问题，而不是先服务报表。

一个框架：问题树 -> 行为链路 -> 事件合同 -> 诊断动作

1. 先写问题树，不先写事件名

我会先问：这个阶段产品最需要判断什么？是新用户能不能完成首次价值，是老用户有没有持续回来，还是付费链路是否有明显摩擦？

把问题拆成三层：

• 结果问题：我们希望什么结果变好，比如完成、留存、付费、分享。
• 行为问题：用户需要经过哪些关键行为才可能产生结果。
• 原因问题：如果行为没有发生，可能是没看到、不理解、不信任、不会用、性能失败，还是价值不够。

只有能连接到决策的问题，才值得埋点。

2. 再画行为链路

一条功能链路通常可以拆成：曝光、理解、尝试、成功、再次使用。对应事件不必多，但要覆盖状态。

常见基础事件包括：screen_view、feature_exposure、feature_click、task_success、error_show、payment_result。属性比事件更重要，至少要考虑 entry、source、screen、module、status、error_code、app_version、os、network、latency_bucket、experiment_id。

事件描述动作，属性描述上下文。不要把每个入口都做成一个事件，否则后面很难比较。

3. 写成事件合同

事件合同至少包含：事件名、触发时机、上报端、必填属性、可选属性、去重规则、负责人、验证方法、废弃条件。

客户端适合记录用户行为，比如点击、滑动、曝光、停留。服务端更适合确认业务结果，比如支付成功、会员权益发放、任务结算。只用客户端判断支付成功，是我会避免的设计；网络失败、回调延迟、用户切后台都会让数据变脏。

4. 上线前先验证数据可信

我宁愿少看几个指标，也不愿看一堆不可信的图。上线前至少要做四件事：用测试账号跑完整链路；检查必填属性是否为空；对关键结果用服务端日志交叉验证；确认重复上报、延迟上报和版本兼容的处理方式。

埋点检查清单

• 这个事件对应哪个产品问题？指标变化后谁做什么决定？
• 有没有分母？只看点击，没有曝光，无法判断转化。
• 是否覆盖取消、失败、超时、返回、空状态这些终止状态？
• 是否能按入口、版本、设备、网络、渠道、实验分组？
• 成功事件代表用户获得了价值，还是只是点了一个按钮？
• 事件名是否稳定，是否避免跟随 UI 文案变化？
• 是否避免采集手机号、邮箱、精确定位等不必要个人信息？
• 关键结果是否由服务端确认？
• 是否有数据健康看板：缺失率、重复率、延迟、异常峰值？
• 这个埋点如果三个月没人看，是否可以下线？

分析数据：从结果倒推，不从点击量开始

我看数据一般按六个视角走，顺序不能乱。

第一，看漏斗。漏斗能告诉我们损失发生在哪一步，但最大流失点不一定是最该改的点。比如某一步本来就是意愿筛选，它掉人是合理的。要结合产品意图判断。

第二，做分群。新用户和老用户、自然流量和投放流量、低端设备和高端设备、不同语言或地区，行为可能完全不同。但分群不是越细越好，只有当不同分群对应不同动作时才值得保留。

第三，看 cohort。功能首次成功后，用户是否在后续周期回来，往往比首次点击更能说明价值。只看当天转化，容易把短期刺激误判成长期增长。

第四，看频次和深度。平均值经常掩盖问题。少数重度用户可能把均值拉高，但大多数用户只用一次。这里要看分布，而不是只看均值。

第五，把性能和错误放进产品分析。页面慢、录音失败、支付回调异常、权限被拒，不是纯技术问题，都会直接影响产品结果。

第六，看路径和反馈。数据能告诉我哪里异常，但不一定告诉我为什么。路径回放、搜索词、客服反馈、应用商店评论、小范围可用性测试，都可以帮助解释原因。

用五层诊断定位问题

当某个指标不好，我会按下面五层排查：

1. 触达问题：用户没有看到。检查入口位置、曝光率、通知权限、推荐规则。
2. 动机问题：看到了但不想点。检查文案、利益表达、目标人群是否匹配。
3. 理解问题：点了但很快退出。检查界面层级、术语、预期管理和引导。
4. 能力问题：愿意做但做不成。检查表单、权限、网络、性能、错误码、支付流程。
5. 价值问题：做成了但不回来。检查结果质量、奖励反馈、内容供给和使用频率。

这套顺序的好处是不会一上来就改 UI。很多团队看到转化低就改按钮颜色，其实问题可能在入口错误、权限失败或功能本身不够有价值。

示例：语言学习 App 的跟读功能

下面是示例，不代表任何真实项目或真实数据。

假设一个语言学习 App 有跟读功能，我会设计这些关键事件：lesson_enter、shadowing_exposure、shadowing_start、permission_result、record_complete、score_result、retry_click、next_lesson。

如果 shadowing_exposure 很高，但 shadowing_start 低，优先检查入口文案、功能价值和出现时机。如果 shadowing_start 不低，但 record_complete 低，重点查麦克风权限、录音时长、网络和崩溃。如果 record_complete 正常，但 score_result 失败多，要查语音评测服务、超时和错误提示。如果评分成功后用户没有继续下一课或次日没有回来，问题可能不是流程，而是反馈没有形成学习动力。

这个示例的关键不在事件数量，而在每个断点都能对应一个可执行动作。

仪表盘应该少一点

一个健康的核心看板，我通常只放四类东西：一个阶段目标，三到五个前置指标，一个质量指标，一个数据健康模块。看板不是为了展示工作量，而是为了减少争论。

团队分工也要清楚：产品负责问题和口径，研发负责事件合同和上报质量，测试负责验证链路，运营或数据同学负责固定节奏的分析。如果团队很小，一个人可以兼多个角色，但文档和口径不能省。

我会这样落地

第一步，写一页埋点方案，只包含当前最重要的业务问题、核心链路和决策场景。第二步，定事件命名和属性规范。第三步，把事件合同写进需求，不要放在上线前补。第四步，灰度期间验证数据，不可信就先不进核心看板。第五步，每周看一次数据，只讨论异常、原因假设和下一步动作。

埋点的价值不是证明自己做对了，而是更早发现自己错在哪里。没有决策绑定的数据，最终都会变成噪音。

PaxLee