一、埋点设计——规范、链路设计
1.1 埋点拆解
回到最初的表格，梳理了一些业务的数据需求。但显然，有些是不适合使用埋点方式采集统计的。就以“我的1212”为例，实际这个页面很多功能是与“登录”用户绑定的。
所以后续分析，十分关联实体账户的金额、交易笔数等需求，将不参与埋点设计。
1.2 埋点规范
既然开始设计埋点，就需要先建立规范。就好比需求文档明确一些全局样式一样，埋点也需要定义一下规范。因为提交埋点需求、执行埋点开发都是多人协同的，我们需要建立规范好便于管理维护。通常地，我们需要注意模块分类、命名规范、具体定义等等，做这些是方便于管理，以及不同的人都能快速解读。
- 版本记录：主要是记录文档从建立到完成的过程，包括内容、时间、操作者等，这个跟需求文档一样，好让其他人知道这个过程的历史变化；
- 模块分类：一般埋点都会分模块整理，因为项目一大，不同的业务就会独立管理，这样分工也更明确些。而分类的标准主要看团队习惯或业务性质，有些是基于整个链路做模块分类，比如整个购买到支付路径等。有些则基于前端页面分类。
- 命名规范：一般埋点都是遵循一定的命名格式，这样的好处除了便于管理之外，其次就是在大家后续进行数据统计分析的时候，能清楚了解对应哪个位置，快速关联起来。大多数埋点的命名都是不同的字符组成，中英文、数字或者特殊字符都可以，主要取决于业务习惯。但是在这里建议设定一些特殊的命名规则，比如0131&DDXY，这样能够仅限于少范围人清楚里面的意思（即所谓波斯密码），保证一定的安全性
- 状态：即指当前埋点的状态，包括新增、删除还是修改。因为随着活动迭代，有些埋点已经不需要了，可以进行删除，而有些因为需求变更，就需要更改埋点的一些信息。
- 埋点定义：每个埋点都需要注明定义，这样开发者才能知道你到底想如何埋点，毕竟仅从埋点名称别人是不知道你想获取哪些数据。所以这时候就需要定义这个埋点的行为是什么样的，比如进入一个页面，点击某个按钮等等；
- 平台类型：由于前端平台有多种，不是所有埋点都一样的，所以就要基于IOS、安卓、H5等分类记录，当然也有完全按照独立的表格文档整理。
- 属性/扩展字段：因为埋点不仅仅满足某个用户行为的获取，也可以基于这个行为顺带获取一些业务关注的数据，前提是能拿到，比如一个登录用户点击首页，除了埋一个点击首页的事件，还可以收集一个“userid“的参数，此时点击的时候就会把当前登录用户的账号ID也上传进去。这样就可以知道，区分是哪些游客和登录用户在点击首页。
- 日期：就是每个埋点的最新时间，基于状态的变化而定
1.3 埋点梳理
到了这里，就可以差不多进行埋点方面的输出了，在这里仍旧按照业务需求分模块一一来整理。
1.3.1 活动整体
首先，先从活动整体来做设计，因为这些涉及基础指标。
（1）活动用户
在这里有个特征，就是特别区分了内部和外部,目的主要是想区分多少是因为此次活动吸引APP游客/登录用户参与的，以及多少完全拉新进来。那么该如何统计区分呢，通常这时候埋点就可以设计“channelid”的属性，本身活动页面在平台上线是个链接，通过链接配置一个“channelid=APP“，那么当用户触发埋点时，则带着这样的标识去统计。
（2）分享
可以关注到，整个活动的每个页面都是有分享功能的，所以外部引流空间是很大。但是点击分享，选择渠道，完成分享，才是一个真正连贯的路径操作，所以埋点就需要针对这几个路径进行埋点设计。
另外，由于有几个的明确渠道（微信、QQ等）。通常情况针对这4个分享途径，开发都会提前配置这个带有渠道属性的不同值，这样分享出去的页面，当用户打开，就可以知道是哪些渠道来源。像微信，就会配置成“https://pinduoduo……/channelid=weixin”，那么用户分享出去就会一直带有这个微信渠道标识的链接，埋点就可以采集这样的信息。
1.3.2 主会场
作为此次活动首页也是最重要的页面，其中涉及的需求会相对更多更关键。
（1）整体页面
通常情况下，主模块下的一级页面都会做一个整体的数据分析，这时候关注页面的PV和UV就十分关键。而这里值得注意的是，“主会场”页面访问有可能会存在比点击底部tab更多，因为活动默认进入的首页即主会场，即用户只要打开从一级入口进入则无论如何都会先曝光主会场。
（2）秒杀万人团
万人团的重要性这里不多说了，总之我们对于这块的埋点设计就需要精细到诸多的可触控埋点。
而这里分别展示了3个“入口”展示团购商品，而由于这些位置明确重要且有限可数，所以在埋点设计可以进行具体位置埋点，即进行第1、2、3号位埋点。为什么做这样的设计呢。因为万人团不同时间段展示的团购商品都是不同，这是无法预测的，所以如果埋点成“点击耳机xx团购”，能埋得了1个埋不了第2个，所以干脆进行位置模块形式埋点。
位置形式确定了，其次我们不妨再回想刚刚提及的内容，这个位置很重要，转化率极高，再联系下业务对商品交易链路的关注需求，那么我们就很清楚，这里需要对用户接下来操作的每个步骤（点击、拼单、支付等）都有梳理逐一埋点，最终形成一个可转化分析的漏斗型埋点路径。
同时，我们也可以增加一些属性类型，比如“product”、“price”等，了解用户对哪些商品十分感兴趣，对价格的敏感度有多高。
（3）品类频道
这个模块在主会场位于最后位置，且展示了此次参与双12活动的全品类商品，所以各类商品的曝光、点击和转化等数据都是琢磨不定的。因为种类太多，曝光位置靠后，是否能触达用户、以及用户能否从中快速筛选感兴趣商品都无从得知。那么我们就可以对页面的固定区域进行特殊埋点，以加强数据监测。
所以在这里对用户的浏览路径做了埋点设计。主要从品类选项栏、停留区域、停留时长等方面做了特定条件的埋点定义。
在这里值得关注的是，为什么会增加了“停留时长”的限制，因为一般用户滑动过程中，都多少会浏览到这些商品内容，这是无效数据居多，只要用户真正聚焦并停留一段时间，才真正代表感兴趣，这才是有意义的曝光。
所以在这里进行停留时长的限制，只有满足条件才算是真正的曝光。而至于如何界定时长的长度，则主要以业务和平台用户总体习惯为主，并没有标准，1s也可以，10s都可以。
1.3.3 我的1212
这样页面接近于APP的个人中心页，通常情况下反而是打开相对较少的页面，除非发生购买交易，需要登录或查看订单之类的行为，基本是很少被用户打开。另外，由于这里有登录态和未登录态，所以有些埋点是需要注意在登录情况下才会发生的。
（1）登录
还记得前面提及到用户转化链路的场景吗？这里登录模块就十分关键了。因为这是整个埋点路径中验证目标达成的最后一环。所以这里分别对一级页面的“登录点击-登录页面访问-成功登录”做了关键链路埋点监测。
同时还收集了用户中途离开及登录异常的两种转化失败的情况，便于后续可以进行二次唤醒转化，挽留流失用户。
另外，这里还有一个关键的属性“usertape”，主要是收集用户注册登录的类型，并统计不同类型下的转化表现。从此次活动可知，拼多多提供了3种方式，分别是微信、QQ、手机号。而微信和QQ由于是采用腾讯开放接口，获取授权信息会多一些，比如性别、地域、昵称等，这是便于做深度的用户画像。
（2）补贴金额
大多数情况下，在登录态之后，有些与账户关联的数据用后台来记录更为精准，比如红包个数、金额等等，因为领取了之后，但是用户不曾在此页面触发任何埋点，是无法准确获取这些数据的。所以这样的功能页面，在埋点设计方面主要关注页面的点击和浏览情况。这些核心的数据需要借助后台方面进行记录。
但是因为后台以用户账户作为存储对象的，那么又如何与埋点的设备账户关联呢？这时候埋点中的一个属性就很重要了，“userid”，当假设用户在登录态，埋点设计了需要上传该账户的userid，那么久可以知道这一系列的行为路径不仅仅是这名设备用户，还知道对应上后台记录的“user用户”
1.4 埋点准则
我们在设计埋点的时候，多遵循一些原则，避免入坑。
- 注意渠道的来源追踪，有效甄别用户的转化和质量表现
- 反复测试验证，避免遗留
- 业务导向为主，多与业务沟通，充分了解对平台规则的使用
- 注意跨设备口径的一致性，善用userid
- 不是所有埋点都需要埋，需要兼顾性能和价值等
- 利用好埋点属性，可以进行更深度分析
- 模拟用户行为路径，去设计关键的核心埋点
- 埋点注意加密存储，以密钥方式进行上报
- 埋点只是数据采集的一种方式，需要结合多种技术特点协同实现
- 一般数据最终呈现BI报表，需要先在测试环境模拟是否符合业务需求，而不是以单个触发点来验证。
- 上产线后，数据持续跟踪，发现并不理想或者不符合业务诉求，需要及时调优更改方案
好了，一份基本的埋点方案差不多成型，剩下的就是交给研发去实现。
二、最后总结
- 一份合格的埋点方案，需要结合业务诉求、产品技术能力、数据分析等方面综合输出，而不是单方面的想当然；
- 多建立核心用户路径模型，有利于快速搭建关键埋点，便于后续的数据分析工作；
- 人无完人，再详尽的方案也难免会有错留，作为一名数据分析从业者，需要走进“用户”，努力还原用户的真实场景，这样对埋点设计是有十分帮助的。
- 以上只是一些基本的埋点方法，要想运用得十分到位，还需要结合业务场景的实际情况，制定更为复杂的方案。
关于埋点涉及的场景十分多，不同的场景有不同的埋点设计，以及需要关注如何达成业务需求。本文主要从通识性针对大众场景去埋点设计，以此篇文章更适合于精细化运营的案例场景学习。
后续有机会分享更多埋点设计个案，包括流失挽留、渠道效果、产品迭代优化等。