本文适于新人阅读，作者简略说明了用户属性、事件、埋点的定义与使用方法。
用户属性、事件、埋点是产品工作中常见的名词，但是对于新接触这些概念的同学来说，其实并不特别好理解。接下来想用下面的内容，将这些概念说明白。
一、生活案例
假设你是一家便利店的老板，有三个固定的客户，他们每周都会到你的店铺里购买一些东西，然后你想多赚一些钱，接下来你会怎么做呢？
经过思考，你觉得用户的消费金额是一个重要的参考指标，于是开始记录每位用户的消费金额，一周后得到了如下账单:
从账单中可以明显的看出用户三的消费水平最高，其次是用户二与用户一。
然后，你根据用户的消费记录，制定了一套评判消费水平高低的标准，如下所示:
根据刚才的标准，这三位用户的消费水平如下表所示：
而且有了这套标准，你不仅能够衡量当前三位用户的消费水平，还能衡量未来的潜在用户，你会根据用户不同的消费水平制定不同的销售策略与服务标准，提升便利店的流水与利润。
经过上述操作，你在心中为每个用户都贴上了标签：消费水平，而标签的具体值则由用户每周的消费行为决定，例如用户周甲周一消费了90元，那对应的消费水平为低，若周二用户甲又消费了250元，则甲的消费水平就变成了高。
标签的值由特定的行为决定，与其他行为无关，消费水平高低由购买行为决定，与寻找商品、投诉等行为无关。而这些行为则是后文中事件 概念的雏形。
上述过程还能挖掘出很多信息，例如用户的消费水平的高低虽然只与购买行为有关，但消费水平的值一旦确定了，之后该用户的其他行为都会体现出这个标签值。例如，消费水平高的用户在排队时，店家可能会优先让他们先结算（俗称VIP窗口），消费水平高的用户在咨询店家时，受到的态度与服务大概率也是最好的。
另外，对于一个用户来讲，标签的最新值才最有意义。正如上文中的用户甲，一旦消费水平由低变成了高，那之前低消费水平的标签值基本上就没多少参考价值了。
通过便利店销售的案例，引出了『用户属性』与『事件』的概念，这里可以简单地将用户属性理解为用户标签，而事件就是用户行为。
用户属性是用户状态与标签的记录，由指定的事件赋值/更新，属性的最新值会伴随着之后的所有事件发送至统计平台。用户属性的定义来源不同，由统计平台定义的属性被称为固定属性，由我们定义的用户属性被称为自定义属性。
2.1 自定义属性
自定义属性是我们为用户设定的标签，多数情况下，标签值由特定行为决定，案例中我们定义了『消费水平』标签，有高、中、低三个值，用户每周消费超过300，会为自己贴上了『高』的标签，小于100，会自己贴上了『低』的标签。
有些『自定义属性』的值一旦确定就不再改变，例如用户编号属性，编号值取决于用户的注册顺序，用户一旦完成注册行为，其编号就确定不变了。
这种不受用户行为改变的自定义属性还有『AB分组』，『新老用户』等。
2.2 固定属性
固定属性是用户自身固有标签，例如性别、出生地、年龄、学历等，这类标签一旦确定，基本上终身不变或者变更速度极慢，它们由『统计平台』自动搜集。
再次强调『自定义属性』与『行为』之间的关系：自定义属性由我们自己定义，例如『消费水平』，属性值由特定的行为决定。例如，决定『消费水平』高低的是『购买』行为，而且『消费水平』的值会随着购买行为变化。一旦用户属性被赋值，该用户属性值会被之后的其他行为所体现。
三、事件表示用户行为
事件在使用软件/网站过程中，事件是用户具体操作的记录，例如按钮的点击、页面的显示。而我们往往使用一个或多个事件来表用户行为。
3.1 网络购买案例
以网络商城购买行为为例，购买行为的步骤可以简单概述为：选中商品→提交订单→付款→确认订单。
而每个步骤包含的具体操作如下所示：
选中商品：进入到商品列表页→点击某个商品选项→进入到该商品的详情页
提交订单：点击『提交订单按钮』
付款：弹出『支付弹窗』→点击『立即支付按钮』
确认订单：进入到订单详情页→点击『订单确认按钮』
我们可以根据需求，使用事件记录上述流程中所有操作或部分操作。
3.2 事件发送机制
在实际工作中，产品经理会定义事件名称与触发时机，然后交付给开发，示例表格如下
开发的同学在看到这张表格之后，会在代码中写入对应的逻辑，用户在使用商城的过程中，『支付弹窗』弹出时，名为pay_pop_show字符串会通过网络发送到统计平台；点击『立即支付』按钮时，名为pay_btn_click的字符串也会发送至统计平台。
将事件逻辑写入代码的过程，也被称之为『埋点』。
3.3 键值对
在刚才的表格中，除了事件名，pay_btn_click事件还带有一个键值对，其中key（键）为amount，value（值）为本次购买的金额。因为我们不仅要记录『立即支付』按钮的点击操作，还需要记录用户每次支付时的具体金额，所以键值对是对事件的额外补充。一个事件可以带有多个键值对，如果我们还想知道用户每次购买的商品种类，我们还可以为事件pay_btn_click增加key为species，value为种类名称的键值对。
前面提到过『自定义属性』与『行为』之间的关系，这里给出更加精准的描述：
自定义用户属性的具体值由指定的（一个或多个）事件决定，例如最开始的『消费水平』的高、中、低，由pay_btn_click事件决定，某个用户本周pay_btn_click事件的amount值累加小于100时，该用户的『消费水平』值为低，若超过300，则为高。
每个事件被发送到统计平台的时候，都会将当前用户所有的属性值一并发送到统计平台中。所以用户属性是随着事件一起发送到统计平台的，如果没有事件发送，用户属性将没有任何的意义，因为统计平台根本无法搜集到属性信息。
下图展示的是数据从被定义到最终分析的所有过程：
四、模拟案例
假设你是某网络商城的负责人，想通过发放优惠券的形式促进用户消费，目前优惠券有两种方案。
方案1：满1000送100元
方案2：满200送20元
具体形式如下图所示，在活动期间，领奖券只会在用户第一次付款的时候弹出。
你想知道哪个方案更好些，所以你会经历以下几个步骤做出判断。
1. 明确统计指标
但从方案的受欢迎程度来说，可以选择『奖券领取率』作为衡量指标。
2. 拆解指标
奖券领取率=领取按钮的点击次数/弹窗弹出次数
因为需要对比两组方案的优劣，这里选择做AB分组实验，所以需要自定义用户属性：用户分组（user_group），其中A组使用方案1，B使用方案2。
由于用户属性由具体的事件进行赋值，所以使用『商城首页首次展示事件（first_main_pv）』决定用户的分组，商城首页首次展示的时间（最小单位为秒）为奇数，则为A组，若为偶数，则为B组。例如，用户首次进入商城首页的时间为19:25:25，则为A组，如果时间为19:25:26，则为B组。
除此之外，还需要定义弹窗的展示事件（pop_show）与领取按钮的点击事件（pop_click）。
统一汇总为如下文档：
4. 数据分析
假设最终的数据如下所示：
5. 结论
则通过奖券的领取率可知，方案2的效果更好，所以做优惠券活动的时候建议使用方案2。
6. 备注
上述案例只是为了更好地说明事件、用户属性的使用而编造的，不具备实施价值。
五、小结
这篇文章简略说明了用户属性、事件、埋点的定义与使用方法，对于新人应该会有一定的启发。
在下一篇文章中，会把实际埋点过程中需要注意的事项进行罗列与汇总，让每个人都能设计出高质量的埋点方案。
