接入后别急着看报表，用户行为分析从定义事件开始
目录索引
用户行为分析的第一步不是打开报表，是把事件定义清楚：分类、名称、属性三层，先定 8 到 12 个，报表才有东西可看。
代码装完，后台能打开，第一反应通常是先翻报表。翻完发现只有页面访问量，看不到人点了什么、填到哪一栏停下，因为事件还没定义。
图 1：事件没定义，报表里只有“来了多少人”，没有“做了什么”。
▌ 用户行为分析的第一步，是先定义事件
页面访问是自动采集的，事件不是。点一个按钮、提交一次表单、播放一段视频，都要有人先决定“这个动作算一个事件”，它才会出现在报表里。
这一步没做完就去看报表，看到的永远只有访问量、来源、跳出率。这三项能回答“来了多少人”，回答不了“为什么没转化”。
我们的建议是：接入当天不碰报表，先用半天把事件表写出来。写表的时间，比后面反复返工省得多。
▌ 事件的三层：分类、名称、属性
| 层级 | 作用 | 写法示例 |
|---|---|---|
| 分类 | 归组，决定报表的目录结构 | 咨询、内容、交易 |
| 名称 | 具体动作，决定报表里的行 | 提交成功、读完、加购 |
| 属性 | 维度，决定能不能拆开看 | 来源页面、字段数、商品 id |
用户行为分析的质量，很大程度上取决于这一张表写得清不清楚；报表只是把它展示出来。
三层里最容易写乱的是分类。分类是给报表分组用的，不是给代码分层用的；按业务动作分组，比按页面分组更好用。
名称要写成“动作 + 结果”，比如“提交成功”而不是“提交”。前者能直接算转化，后者只能算点击。
属性决定后面能不能拆。想按来源看转化，就得在事件里带上来源页面；想按商品看，就带商品 id。属性缺了，报表建好也拆不开。
图 2：少于 8 个路径断成两截，多于 12 个维护成本超过收益。
▌ 8 到 12 个事件怎么挑
先列业务动作，再删。把“用户从进来到完成目标”的路径写出来，路径上的每个关键动作就是一个候选事件。
| 业务 | 建议保留的事件 |
|---|---|
| 官网获客 | 咨询入口点击、表单提交成功、资料下载 |
| 内容站 | 文章读完、收藏、订阅、分享 |
| 电商 | 商品浏览、加入购物车、下单、支付成功 |
单个业务场景 8 到 12 个就够。少于 8 个，路径断成两截；多于 12 个，维护成本会超过分析收益。
挑的时候用一条标准：这个事件对应一个可以改的动作吗。对应不上，就先不埋。
图 3：第四条最容易跳过，它决定转化能不能算。
▌ 定义完之后怎么验证
| 验证项 | 怎么做 | 通过条件 |
|---|---|---|
| 事件有数 | 手动触发一次，等报表更新 | 事件列表里出现这个事件 |
| 属性有值 | 按属性分组看一下 | 关键属性的空值占比低 |
| 命名不重复 | 在事件列表里搜同义词 | 没有两个事件表达同一动作 |
| 能算转化 | 用两个事件建一条漏斗 | 步骤人数依次递减且合理 |
456数据的事件列表能直接看到每个事件的最近触发时间，验证第一步不用先翻代码。
四条里第三条最容易被跳过。同一个动作在不同页面起了两个名字，报表就会裂成两行，后面想合并要重跑历史数据。
▌ 为什么推荐先把事件定下来
我们推荐这个顺序，理由不是流程规范，是成本：事件定义改一次，历史数据不会跟着改；报表建好之后再改事件，前面几周的数据就白攒了。
456数据把事件管理放在「多维分析 → 治理」下，事件名和属性可以在那里维护，改完让前端同步一次即可；这也是我们建议接入当天先把事件表定下来的原因。
工具能提供的是治理入口，定义本身还是业务决定。这件事没人能替你做，工具只能让你改起来方便一点。
▌ 什么时候可以先不定义
只有一个落地页、只关心访问量的站，先不定义事件也能用；这个阶段 456数据的网站访问报表在免费版里就有，够用。
刚上线、页面结构还会大改的产品，可以等结构稳定再定义。改版期间埋的事件，改完版大概率要重埋。
团队里没人维护事件表时，也先别急着埋。埋了没人管，半年后事件列表会变成一堆没人认识的名字。
▌ 常见问题
事件要一次定义完吗
不用。先定 8 到 12 个覆盖主路径的事件，跑一个月，再按实际问的问题补。
分类和名称可以合并吗
不建议。合并之后报表只能按一层分组，想按业务看、又想按动作看，就做不到了。
属性里可以放手机号吗
不要。手机号属于个人信息，采集前要单独评估合规风险，能不放就不放。
事件定错了能改吗
能改，但改完前面的数据不可比。建议一个月内只改一次，并在报表里标注变更日期。
▌ 延伸阅读
产品总览：行为分析、用户画像与性能监控：行为分析 Tab 的能力清单与菜单结构。
名词解释（19 项指标）：事件触发用户数、事件触发次数等指标的官方定义原文。
网站、App、小程序怎么选统计方案：一张矩阵定档：按端覆盖与档位组合给出的选型矩阵。
