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

上半部分文章主要围绕指标，包括选定关键指标（主要指标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奶茶之外，也可以前后交叉对比下，比如我们把支付提交成功的前端打点和服务器收到支付成功请求的打点做个对比，误差如果稳定在百分之几的话，那么基本上没有问题啦。

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

*除了基本信息不需要赘述外（包括用户手机型号、平台、页面id等等），在每次用户提交的时候我们还会记录一个Query_id，用这个id可以去服务端的日志中查看本次搜索的详细情况（相当于后端打点），包括各种用户本次搜索的各种输入信息和我们输出给用户的信息（比如到底展示了哪些商品等等），用于后续搜索策略的优化。

总之，打点要有详有略，既能保证用户的每一个步骤的重要信息都要能有效提取到，又要善于巧用单独的字段来减轻后续数据分析的工作量。

另外，打点设计完之后，别忘了和相关同事（运营、BI等）确认是否能满足所有想看的指标，不同岗位关心的指标会有侧重点不同，大家要确保万无一失哦～

二、 科学设计实验

有了打点之后，我们可以统计到一些功能的详细数据，用来验证这个功能/项目对关键指标是否真的有帮助，或者是否还有提升的空间。

影响关键指标的因素是很多的，比如节假日、淡旺季、广告投放等等各种情况，所以我们还需要对想要分析的项目设计“实验”来获取更精准的数据，常见的有以下几种方式：

1. A/B测试

这类测试比较适合数据随时间波动较大的垂直类目，比如快消、服装品牌等。

A组就是空白组——原方案，B组是实验组——优化后的方案，这样做为了要排除季节、突发事件、新的商品、宣传活动等等各种情况对产品数据造成的波动。需要注意两点：

• 确保流量切分的时候尽量是均等的，一段时间内，A组和B组的UV/PV几乎相同，这个误差如果接近10%，实验的可信度就会大大降低，说明在分流量的时候有bug。
• 确保流量切分的时候不存在任何用户画像上明显的差异。比如A组女性更多，B组男性更多，就会影响实验结果。很多时候程序生成的“随机”其实是伪随机，所以一定要警惕切的时候并没有做到真正的随机。

如果试验结果看上去比较异常，我们可以做AA实验来确定下数据的准确性，即A组和B组都用原方案，来看下数据是否相同。

2. 灰度测试

灰度发布和A/B测试的原理相同的，但是流量不会均匀分配，一般是切某个比例的流量给到B组，比如5%，10%等。比较适合量级大、有影响力的核心页面，比如淘宝首页改版就会小范围先切一部分流量做灰度测试，这也很适合淘宝这样强运营的App。

运营可以通过灰度测试的结果对策略进行调整，避免直接全量上线影响整个App的指标。这种方案适合有一定研发能力的平台，因为对流量的切分提出了更高的要求，所以大厂用得更多一些。

3. 直接发版

直接进行发布新功能/新版本，分别看老版本和新版本的数据，计算某个固定时间段内平均值的提升。直接发版适合数据比较稳定的平台，且对发布的产品功能很有信心。

比如产品之神张小龙就很少搞什么A/B测试、灰度测试啥的，很多改版就是直接上（比如微信7.0神马的），当然我们都不是产品之神，如果不能确保这段时间数据比较稳定的话，还是乖乖做AB或者灰度先～

如果是通过更新客户端来进行版本发布（服务端发布、小程序等不用考虑），要注意等新版本覆盖大部分用户了之后再看数据会比较准，因为先更新的用户往往是对平台比较忠诚的用户，只看这部分用户，数据会偏高。

比如我们发现新版本发布后两周，80%的用户都更新完了，那么就可以对比新版本发布前老版本1个月数据的均值，和新版本发布之后第3周到第7周数据的均值（也是1个月），来进行对比。

其实像微信出的“炸shi”之类的小彩蛋，其实很多时候是为了去催促用户更新到新版本～

三、分析数据结果

经历了设计打点和实验，又等待了一下版本更新覆盖率之后，我们终于取到了数据，然而结果往往充满了惊喜（吓）。就算数据非常符合预期，在汇报的时候有数据和图表的那几页往往需要费劲去解释。下面就教大家比较实用的几招，从此汇报数据无烦恼。

1. 排除干扰项

说到汇报数据，往往是数据跌了惨兮兮，数据涨了又要赶紧解释原因，不然等到下周环比跌的时候又要解释了。

记得之前学姐遇到过几个月DAU疯涨，当时分析了半天没找到原因（当然现在知道啦），当时老板打趣说唯一的变化就是前任老板离职了，可以说是甜蜜的负担了。

数据总是有这么多干扰项，像玩剧本杀一样，我们会发现很多看上去可疑的线索，其中大部分都是干扰项，要排除这些才能找到真正的“凶手”。

比如学姐的一个童鞋小超因为好玩做了一个扔手机的App（不建议大家下载，很费手机），这个月突然发现App中广告的曝光量跌了三分之一，收入也随之跌了。

仔细一看，发现不是这个月跌了，而是上个月有几天数据猛涨。

再进一步拆解，发现是某个安卓商店的下载量在那几天激增，于是发现自己的App在那几天被这个安卓商店推荐了一下下。排除这几天后，数据看上去就这么夸张了。

大家在分析数据时，最直接的就是先按照时间画出数据曲线，看看有没有异常的点，把异常点排除之后再去看数据。

定位了时间段（点）之后，就像锁定了“杀人凶器”，接下来只要找到是谁使用的就行了。

我们可以进一步拆解（不知道怎么拆解的可以看文章的上半部分），看是否有天气、城市、渠道、广告、销售、其他产品功能、运营活动等等各因素的影响，当然这些因素和业务有关，如果你完全没有头绪，可能需要更进一步去了解业务了（比如问问相关部门的同事）。

技术原因也会影响到产品数据，比如某个服务器在某天的超时的访问特别多，那自然会影响产品的转化率了。

如果这些因素都没有变化，我们可以更跳脱去考虑，比如是否有政策、人口、经济是否对整个行业的大盘产生了影响，从而进一步影响到了自己的业务。

2. 选择最直观的图表

自己好不容易推理出了“真凶”，但是一起玩剧本杀的小伙伴竟然没听懂你的推理，还反手投了你？

这就和分析完数据之后，复盘汇报时同事不能理解这些数据一样苦恼。到底选择什么样的图表来表达数据才能做到清晰、高效？

打开Excel我们会发现有N种图表（截图有点丑大家不要介意），咱就讲几种常用的：

（1）柱形图&条形图

柱形图的一般用于表达某个指标随着时间（或者某个变量）的变化，比如每个季度的销售额、MAU均值等。

如果变量的文案比较长，我们也可以用横过来的条形图去呈现（柱子之间文字太多挤不下），比如首页每个模块的点击率。

总之，柱状图更强调趋势变化，条形图更强调比较（左图的单位是万，忘记标注了，下同）。

左图为柱形图，右图为条形图

（2）柱形图+折线图

折线图和柱形图类似，也强调趋势变化。

一般用于更细的数据，比如分天、分小时的数据，MAU按照每个季度平均一下还能用柱形图，但是如果过去一个季度DAU的数据，那用柱状图肯定就画不下了，这时一般就用折线图了（比如上面一章提到的分天曝光图）。

既可以表达绝对数值，又可以表达出趋势，学姐个人还蛮喜欢的。

比如两年内每个季度的MAU均值（柱状）和其年同比（曲线），这样我们不仅可以看出每个季度数值和变化趋势，也可以看出年度的变化趋势。

（3）饼图

强调占比。比如我们要统计不同路径下单量的占比，这时候就可以用饼图了。很多童鞋在这个时候还是用普通的柱形图/条形图，这样不如饼图直观。

(4）漏斗图

顾名思义在表达漏斗的时候比较好用。比如对比新用户和老用户（或者不同渠道、平台等）在打开App→商品详情页→下单成功每个漏斗的UV，不过转化率需要自己标注下，学姐觉得这图和直接用表格的直观程度其实也差不多。

如果是表达两类用户转化漏斗的对比，倒还不如用两个条形图拼一起（左边这个需要选中两个坐标轴然后对刻度线选择逆向类别）。

稍微复杂一些的图表其实也就是一些基本图表的组合，比如百分比柱形图，有邻居的柱状图等（官方名字是簇状柱形图？好拗口），大家可以根据需求去选取。

比如我们要表达每个季度的运营成本，和各项成本占营收的比例时（比如市场营销成本、研发成本、行政管理成本），就可以用前者，强调趋势+占比；表达兄弟部门每个季度销售额PK的时候，就可以用后者，强调趋势+对比。

摘自B站财报

兄弟部门业绩PK图表举例

选择图表类型有点像 “交互”，那么学姐再分享几个作图的小技巧，相当于图表的“视觉”，可以有效提升沟通效率：

（1）适当标注

默认的图表设计很高级，完全没有数字，但是我们为了要汇报的效率，还是要把关键的数据标注上去，比如交易额、DAU、同比等。

另外，文字也要尽量标得清晰，比如饼图的默认样式经常是把图例标注在饼图下方，这样看起来很累，而且投屏的颜色有变化或者图例的颜色很像，很容易对错，可以选择文字直接在饼上的样式。

（2）强调重点

如果某个数据很出彩或者需要重点关注，我们可以把相应的数字加粗加大，比如饼图的某块饼就可以单独放大，比如柱子的颜色改一改，就能成功引起大家（老板）的注意，摘自B站财报（每季度增值服务营收），猛男粉太醒目了叭。

摘自B站财报

（3）坐标轴范围合适
默认的坐标轴经常会最小值不是零，而且坐标值最大值比我们数据的最大值大很多。

好的坐标轴应该是从零标起，并且最大值只是略大于我们数据的最大值，这样不容易放大数据波动，并且又能在把图表的柱形或者条形展示得比较清晰。

如果有特殊情况要用某个非零的数字作为坐标轴的起点，一定要非常谨慎地标注清楚。

（4）备注口径

每个公司都对不同指标都有不同的定义和叫法，一般比较明确的指标我们不需要额外备注，有些用得少的指标我们还是要把计算口径标得很清楚，包括数字从哪里取来的、时间段、版本，计算公式等等。

来，学姐给一个图表的Before & After效果图，当然如果不需要强调2020年的数据就不需要像学姐这样把柱子的颜色改成紫色了（低调一点～）。

左图为默认图表，右图为优化后

四、持续监控——数据产品的类型及其适用场景

其实从打点到分析结果之间，还有一个步骤是使用数据产品取数。

不同的数据产品的适用场景不同，这几年“数据产品经理”这个概念也蛮火的，可见其重要性。虽然我们不是专业的数据产品和BI，不过为了日常数据分析工作可以顺利进行，我们需要对一些指标进行重点监控，所以也需要了解数据产品的基础知识。

常见的数据产品有这几种类型：

（1）SQL语句

想怎么查数就可以怎么查，适合低频个性化需求，比如某个新功能上线之后，往往会把数据看得详细一些，以便更全面了解功能的使用情况。

缺点是容易存在安全隐患，比如有一些机密、敏感的表格不适合给全部产品开放权限，比如公司内部人员的薪资、年龄，用户的电话号码、其他部门的营收等等。

所以在大公司往往会花精力去搭建一套比较完整的权限体系，避免泄漏商业机密。

有些产品童鞋不太会写SQL，学姐建议大家可以买本大学的SQL教科书看看，跳过建数据库这一块，直接学习一些常规的查询就好了（基本的Select from，join之类），这样方便自己直接去查数据。

（2）取数工具

就是把某些中频使用的SQL查询语句固化下来。产品可以自己输入日期范围、类目等去查询交易额等。

如果不懂SQL的产品可以找BI或者BA帮忙写一个取数工具，自己定义一些可以输入的字段就行了。

（3）可视化后台

适合一些中高频监控的过程指标、常见的路径漏斗等，在灵活度方面稍微欠缺一些，但是胜在可以输出图表，易操作、直观，是大家比较常用的。

除了大厂是自研的数据品台之外，很多公司用的都是第三方提供的可视化数据后台。

（4）自动化报表

适合高频监控的关键结果指标和过程指标，一般会用表格或图表的形式每日自动发送至邮箱或IM。

包含环比、同比、MTD（本月到今天为止）等，方便大家及时发现数据波动，避免大家做月报、周报的时候看到想半天不知道问题出在哪儿。

当然，这种日报模版调整频率会更低一些，因为监控的都是最关键的数据。

关键指标以每日为维度监控只能发现一些产品、运营、销售相关的波动（比如跌了百分之十之类的），如果遇到一些技术性的问题，可能数据一落千丈，等到第二天才发现就已经让公司损失几个亿了。

所以一般还会对关键指标有实时监控，比如过去一小时内，订单量比上周同期跌掉一半，就会报警发到手机上，这样及时发现线上bug。

作者：海贝学姐；公众号：海贝学姐

本文由 @海贝学姐 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议