3、事件命名规范：让每个事件都有名有姓
埋点规范里，命名这件事看起来最不起眼，但坑最多。我见过太多团队，埋点埋了大半年，最后分析数据时发现「新增用户」和「用户新增」是两个不同的事件名——你说崩溃不崩溃？
命名规范的核心就一句话：让人一眼看懂，让机器不会混淆。说白了，就是给每个事件起个身份证号。
3.1 命名原则：动词+名词
我个人习惯的命名公式很简单：
事件名 = 动词 + 名词
动词表示用户做了什么，名词表示操作的对象是什么。
举个例子：
click_login_button—— 点击了登录按钮view_product_detail—— 查看了商品详情页submit_order—— 提交了订单share_article—— 分享了文章
为什么要这么定？你想想看，如果事件名叫 login_click，新来的同事第一反应可能是「登录点击」还是「点击登录」？虽然意思差不多，但一旦规模大了，这种歧义就会变成灾难。
小技巧：动词统一用英文原形，不要用过去式或第三人称单数。比如用 click 不用 clicked，用 view 不用 views。
常用的动词我整理了一张表：
| 动词 | 含义 | 适用场景 |
|---|---|---|
click |
点击 | 按钮、链接、图标 |
view |
浏览/查看 | 页面、详情、弹窗 |
submit |
提交 | 表单、订单、评论 |
share |
分享 | 内容、链接、图片 |
search |
搜索 | 关键词、筛选 |
login |
登录 | 账号登录、第三方登录 |
register |
注册 | 新用户注册 |
play |
播放 | 视频、音频 |
pause |
暂停 | 视频、音频 |
delete |
删除 | 内容、记录 |
3.2 事件层级分类
光有命名规则还不够。事件多了以后，你得有个分类体系把它们管起来。我一般把事件分成三个层级：
- 一级分类：按业务模块分，比如「用户」、「商品」、「订单」、「内容」。
- 二级分类：按行为类型分，比如「点击」、「浏览」、「提交」。
- 三级分类：按具体对象分，比如「登录按钮」、「商品详情页」、「订单表单」。
对应到事件名上，就是：
模块_行为_对象
user_click_login_button
product_view_detail
order_submit_form这样做的好处是什么？我举个例子。有一次我在排查一个数据异常，发现「商品详情页的浏览量突然暴涨」。如果事件名是 view_product_detail，我直接按模块筛选就能定位到问题。如果事件名是乱起的，比如 detail_show，你得翻半天文档才能知道它属于哪个模块。
下面这张图可以帮你理解事件命名的层级结构：
3.3 通用事件与业务事件
事件还可以按通用程度分成两类：
- 通用事件：所有页面都可能有的，比如页面浏览、页面停留时长、页面滚动。
- 业务事件：特定业务场景才有的，比如下单、支付、收藏、评论。
为什么要区分？因为通用事件可以做成公共组件，一次接入到处可用。业务事件则需要业务方自己定义。
通用事件命名示例：
page_view—— 页面浏览page_scroll—— 页面滚动page_duration—— 页面停留时长app_launch—— App 启动app_background—— App 进入后台
业务事件命名示例：
order_submit—— 提交订单payment_success—— 支付成功product_favorite—— 收藏商品review_submit—— 提交评论coupon_receive—— 领取优惠券
注意：通用事件不要加业务前缀。比如 page_view 就是 page_view，不要写成 product_page_view。业务前缀应该通过事件属性来传递，而不是写在事件名里。
3.4 命名示例：好的 vs 坏的
光讲理论不够，我直接上对比。下面这张表是我在实际项目中踩过的坑：
| 场景 | ❌ 坏命名 | ✅ 好命名 | 原因 |
|---|---|---|---|
| 点击登录按钮 | login_click |
click_login_button |
动词在前，符合阅读习惯 |
| 查看商品详情 | detail |
view_product_detail |
太模糊，不知道是查看还是点击 |
| 提交订单 | order |
submit_order |
缺少行为，不知道是提交还是取消 |
| 分享文章 | share_article_wechat |
share_article |
渠道信息应放在属性里 |
| 搜索商品 | search |
search_product |
缺少对象，不知道搜的是什么 |
| 播放视频 | video_play_click |
play_video |
动词重复，click 和 play 取一个就行 |
我曾经在一个项目里看到过 click_click_button 这种命名——嗯，你没看错，click 出现了两次。当时我就跟团队说，命名规范不是用来限制你们的，是用来救你们的。
避坑指南：
- 不要用中文拼音，比如
dianji_denglu—— 团队里如果有外国人或者未来要国际化，这就是灾难。 - 不要用缩写，除非是公认的，比如
btn代替button、img代替image。 - 不要用数字结尾，比如
click_button_1、click_button_2—— 页面改版后数字一变，历史数据就废了。 - 不要用特殊字符，比如
click@button、click#button—— 有些数据处理框架会报错。
命名规范这件事，前期花 10 分钟定好，后期能省 10 个小时。我见过太多团队因为命名不规范，最后数据对不上、分析做不了、报表出不来。嗯，别让你的团队也踩这个坑。