编辑导语：在进行数据分析之前，需要先进行一些阶段性的准备工作，先拆解好指标，再进行后续做功能与打点取数。作者从怎么分析数据结果、怎么作出直观的图表和指标的持续监控分享如何设计打点和实验。

上半部分文章主要围绕指标，包括选定关键指标（主要指标VS次要指标），从关键结果指标拆解出过程指标，并定下阶段性目标。

这些是数据分析的基础工作，在没有做好之前，不建议直接就开始做功能、打点取数等等。如果这部分已经做好了，那么可以看接下来的文章（如果没有建议戳上半篇）。

接下来讲一下有了指标之后到底怎么去设计打点和实验，包括怎么分析数据结果、怎么作出直观的图表和指标的持续监控，还是比较实用的技能。

打点和实验是同步设计的，因为这两者会互相影响。有些童鞋对DAU、交易额、转化率等大指标监控比较重视，但是拆分到某个页面、某个功能的打点就设计得大条了一些，导致经常要等数据结果出来了，才发现还需要补一些打点。

所谓巧妇难为无米之炊，如果打点没打好，连数据源都没有，数据分析能力再强也没用。

打点分为前端（客户端）打点和后端（服务端）打点两种。

先介绍常用的前端打点，这类打点主要是用来记录用户行为的，也就是当用户和你的页面产生了交互之后（比如点击了某个按钮或者打开了某个页面），本地产生一条包含很多字段的信息（相当于xls的一行），等到一定的时间之后上传到服务器上，然后通过数据清洗、入库等等，就能提取出来进行数据分析了。

前端打点必须包含的字段类型（相当于xls的表头）有以下三大类：

1. 基础信息

比如用户的渠道、平台、操作系统、手机型号、用户身份唯一标识（uuid、token）、页面id等等，以便后续做一些基本的分析。

也可以再进一步，根据业务特性加上一些字段：比如一个LBS的App可以把城市、经纬度也加到基础信息中，比如一个交易平台可以把用户浏览商品的sku id或下单的order id带上，只要用户有和商品id、下单相关的操作，这两个字段就都可以记录上。

这么做的好处是不需要产品/运营每次额外提需求，默认每条打点都会带上这些字段，这样不容易漏。

2. 事件信息

事件也就是用户的一次操作行为，是前端打点中最重要的部分。

首先，我们要给每个事件起一个唯一的名称。

比如用户和banner发生了一些不得不说的交互（比如点击），这个事件可以叫“banner”，有些公司用的是随机生成的字符比如“5x_aswed”，看上去像是猫咪在键盘上随便按的，也有些公司用的是中文名称比如“中通”（不是快递，是中间通栏的意思），这个不打紧，只要是唯一标示都可以。

其次，我们需要（一个字段）记录这次操作的类型。

一般来说有这4种：页面/模块加载→模块展示（加载完毕）→模块点击→提交成功。

比如用户打开某电商App首页，这时候首页已经开始加载了（1），过了0.01秒之后首页的banner加载完毕且第一帧展示在用户的面前（2），然后过了2妙轮播到第二帧（3），用户点击第二帧（4）。

这其中（1）就是加载事件，（2）、（3）都是展示事件，而（4）是点击事件。

这时候（4）的UV/（3）的UV才是第二帧banner的UV转化率，而不是（4）/（1）或者（4）/（2），因为发生（1）和（2）事件时，这一帧banner根本没有展示在用户的面前。

截图摘自淘宝App

那么提交事件是什么时候记录的呢？

因为点击banner之后会直接进入活动landing页面，所以不需要记录提交。

但在某些情况下，比如用户在某件衣服的商品详情页点击了“领券购买”，弹出了选颜色和选尺码的半窗，此时用户再点击半窗上的的“领券购买”（5），会出现一个请选择尺码的提示，选好了之后，再点击“领券购买”（6），这才“购买”的这个行为成功地提交了，此时系统还会进行一个自动领券的操作，然后推进到下一个页面（7）。

所以这时候（5）是点击事件（点击了，但是没有成功提交），（6）才是提交事件。如果选择颜色、尺码的样式没设计好，就会导致点击→提交的转化率不佳，所以只记录点击显然是不够的。

截图摘自淘宝App

那么有些童鞋可能会问，那直接看下一个页面的UV，也就是（7）的展示量不就行了吗？

其实也不然，如果网络不佳会导致用户没有推进到下一个页面（特别是在双十一的时候，网络挤爆了），所以从上个页面提交（6）→下个页面加载（7），当中还可能漏掉一部分用户。

因此在这种情况下，提交的事件类型就很有必要了。当然，这种情况相对复杂，大部分时候我们记录页面的展示、模块的展示和点击，是够用的。

最后，除了事件名称、事件类型，我们要记录一些事件相关的附加信息。

比如刚刚说的banner的第几帧，如果每一帧都作为一个独立事件重新命名，那就非常麻烦了（比如banner_1,banner_2……万一有10个banner呢）。

这时候我们再加上一个字段index，在banner展示和点击的时候都记录下一个额外的数字，比如1、2、3等，用来记录第X帧（当然程序员小哥哥/小姐姐可能会和你说从0标起）。

如果banner在某段时间里面是不固定的，或者千人千面的，比如小明在第一帧看到了减脂餐的banner，小刚在第一帧看到了连衣裙的banner，那我们可以再记录一个字段title，把banner的活动名称记录下来，那么小明点击banner就会产生事件名称“banner”，事件类型“click”（点击），index“1”，title“减脂餐”这四个字段了。

3. 归因信息

只记录基本信息和事件信息，还是没有办法统计出在文章上半部分提到的——根据路径（比如首页不同的模块）去拆解访购率（下单UV/模块访问UV），因为我们知道用户下单的前一个页面是商品详情页，再前一个页面可能是商品列表页，但并不知道用户到底是不是从首页的哪个入口进来的。

当然，你可以去近似，比如点击过banner的用户在X分钟内访问了商品详情页，但是这个时间是很难把控的，导致不够精准。

这时候我们需要加上一个归因信息的字段，也就是标识出用户的关键行为到底是通过哪个路径产生的。

比如我们可以把某橘色电商App的模块简单分为搜索框、icon位、运营位、轮播banner、猜你喜欢等，那么我们需要一个字段来记录本次购买到底是哪个模块带来的。

原理其实也很简单，就是在用户从每个模块点击到下一个路径的时候带上这个字段就行了，比如用户在点击了banner之后可能会进到各种类似的页面，不管是活动页、商品详情页还是店铺页，只要用户产生任何交互（只在关键的页面记录也可以），我们就把用户“banner”这个信息记录在归因的字段上，直至最后下单。

如果用户在下单前，又回退到了其他首页的模块，比如点击了搜索框，那么同理，我们只需要在这个时候把“搜索框”之后的任何用户行为（直至下单）都在归因字段记录下“搜索框”就行了。

这样，我们就可以分析出，首页各个模块的访购率到底是什么水平了。

前端的打点介绍得差不多了，后端打点一般是在服务器的一些技术打点，比如用来统计95线、98线、端到端响应速度等性能，一般策略产品会接触得多一点（比如搜索产品），原理也是类似的，在用户和服务端发生交互的时候做记录。

如果前端打点的数据取出来非常难以置信，但是研发小哥哥/小姐姐又觉得“我这里是好的”，那么除了请喝TA奶茶之外，也可以前后交叉对比下，比如我们把支付提交成功的前端打点和服务器收到支付成功请求的打点做个对比，误差如果稳定在百分之几的话，那么基本上没有问题啦。

讲了这么多，学姐再举一个栗子加深印象吧，看一个列表页功能打点的文档，为了阅读方便，打点就都用中文写了。