事件和属性是什么？

事件和属性

浏览量告诉你大家去了哪里，事件告诉你大家做了什么：开始试用、播放视频、用了筛选、付了款。每个事件都有名称、时间、做这件事的人或设备，以及一组属性：

track('purchase', { order_id: 'A1042', value: 129, currency: 'CNY', items: 3, coupon: 'SPRING' })

属性分两种。事件属性描述这一次发生（这笔订单的金额）；用户属性描述这个人，跨事件保留（他的套餐、注册日期、所在地区）。

一个事件加属性，而不是一堆事件

埋点最常见的错误，是每种变化都建一个事件：click_buy_red、click_buy_blue、click_buy_footer。之后做报表要一个个手动加进去，新出的变体还会漏掉。

正确的做法是动作只命名一次，变化放进属性：click_buy，加上 color 和 position。一个好用的判断：如果两个事件总是要放在一起分析，它们就该是一个事件。事件数量控制在几十个，而不是几百个，细节交给属性。

命名规范

• 对象 + 动作，统一一种风格。order_paid、trial_started，或者 Order Paid，但不要两种混用。
• 命名业务结果，不命名界面。写发生了什么（signup_completed），而不是哪个按钮（blue_cta_click）；按钮会改，业务事件不会。
• 属性类型固定。金额永远是数字，币种永远是三位字母代码。类型混用，求和和筛选都会出错。
• 名称和自由文本属性里不放个人信息。邮箱、手机号不属于事件属性。

TapCub 里的事件和属性

事件可以从网页脚本（tapcub.track()）、自动采集、App 和小程序 SDK、服务端 SDK 进到 TapCub，全部落在同一个事件库里，所以后端发的注册事件和浏览器发的点击事件可以放进同一个漏斗。

每个事件名都可以登记成事件定义，带显示名、分类和声明的属性，埋点方案会拿真实数据和这些声明对照。属性治理可以屏蔽某个属性、只放行白名单里的属性、隔离取值过多的属性，或者把校验不通过的事件放进隔离区，而不是把坏数据存进去。看起来像个人信息的属性会被剥离，并记为一条数据质量告警。

常见误区

• 什么都埋。几百个没人用的事件，会让重要的那几个很难找。
• 各端名字不一样。网页叫 signup、App 叫 sign_up、服务端叫 SignUp，就是三个事件。
• 取值过多的属性。把带参数的完整网址、时间戳当属性，按它拆分就没有意义了。
• 页面一加载就发事件。每个页面自动发出的事件，记录不到任何行为。

延伸阅读：事件埋点怎么做和表单分析。