埋点模型|如何科学地输出一份的埋点需求文档？( 二 ) 输出|字段|模型|文档|需求|科学

首先，需要梳理业务过程，然后针对细分的业务场景定义能够衡量业务目标的指标，确定埋点的内容和范围；之后就可以按照事件模型设计事件，以及事件下的属性了；比如，来看一个电商搜索的场景来看如何进行埋点设计。
下面用电商搜索场景为例，说明如何进行埋点设计：
1. 业务分析梳理业务流程，以及每个业务流程下的用户路径和各种细分场景。
一般思路是——根据用户在产品上具体的操步骤，定义用户行为路径；比如在电商搜索的场景中，核心操作步骤是用户发起搜索/ 点击搜索结果/购买商品，那么就可以把业务分解为「输入关键词搜索」、「点击返回搜索结果」、「购买商品」，在「输入关键词搜索」环节；可以通过输入的关键词，分析用户对不同商品的需求情况，在「点击返回搜索结果」环节，可以评估不同关键词运营状况是否健康；譬如，是否存在没有搜索结果返回的关键词，或者用户点击的搜索结果排在很后面等等。
2. 指标拆解完成业务拆解之后，需要结合业务分析目标思考，每个细分的业务过程可以有哪些指标来分析。
在电商搜索的场景中，常见的分析是视角是：

用户对不同商品的需求情况如何，相关的指标是「不同关键词的搜索次数/人数」；
不同关键词当前的健康度如何，相关的指标是「搜索结果点击人数/次数」、「搜索结果点击率」、「不同关键词返回结果数」、「搜索结果点击位置均值」等；
用户对商品的需求是否都能得到满足，相关的指标是「不同关键词返回结果数」、「关键词返回结果点击-成功购买的转化漏斗」，此时，我们就完成了指标定义。

3. 事件设计在上面的步骤中，我们定义出了「不同关键词的搜索次数/人数」、「搜索结果点击人数/次数」、「搜索结果点击率」、「不同关键词返回结果数」、「搜索结果点击位置均值」、「关键词返回结果点击-成功购买的转化漏斗」等要统计的指标。
事件设计，其实就是把指标中设计也行为提炼出来；回来电商搜索这个例子中，我们可以提炼出七个用户行为，分别是：「点击搜索按钮」、「返回搜索结果」、「点击搜索结果」、「浏览商品详情页」、「商品加入购物车」、「确认订单」、「支付订单」。
在实际的设计中，有一个重要的问题需要考虑：针对某个具体的行为是否需要设计单独的事件，比如「点击搜索按钮」这个行为是否可以用「APP 元素点击」这个事件采集，还是需要有一个单独的「点击搜索按钮」事件去采集？
在这个问题上，有两条经验分享：
1）对于重要的点击事件，建议单独设置事件采集，而不要使用「APP 元素点击」「Web 元素点击」等这样的全埋点事件。
重要的点击事件往往需要记录更全面、更精细的字段，需要根据具体的点击事件的类型以及个性化属性，进行归类采集；常见的点击事件有 Banner 位点击、ICON 点击、频道 TAB、功能重要操作点击等事件。
2）有两个相似的行为，如「信息流广告点击」和「Banner 广告位点击」这两个行为，由于要记录较多丰富的属性，已确定要设置单独的事件；但这两个事件采集的字段非常相似，都需要采集广告 id、广告名称、排序、所属页面等字段，是按照下面的 a 方案采集，还是 b 方案采集呢？
这里需要回到业务，如果在后续的分析中业务需要将信息流广告和 Banner 广告汇总起来看总的广告点击次数/人数；那需要按照 a 方案合并设计，如果后续业务上不会合并看数据，建议按照 b 方案分开设计（其实 a 方案也能满足分别统计两种广告的需求，不过查询要麻烦一些）。

文章插图
另外，在事件设计时还需要说明数据的采集时机以及在哪个端采集。
举个例子，我们设计了一个「信息流条目曝光」的埋点事件，如果不对采集时机加以说明，研发很有可能在信息流条目只在屏幕上露出 50% 时就采集上报数据，而业务需要的是信息流条目在屏幕上完全露出时才采集上报；于是，在事件设计时需要描述清楚在什么样的情况下会触发事件数据的采集。
从事件上报的触发逻辑上面来讲，可分为前端触发上报、前端获取后端汇总结果后上报、后端触发上报、后端获取前端属性后上报四个比较类别，如下图所示。

文章插图
以淘宝下单流程中的「购买成功」为例，详细介绍下单埋点事件的触发逻辑类型。