32 | 互联网运营数据指标与可视化监控

数据分析是大数据应用的一个主要场景，通过数据分析指标监控企业运营状态，及时调整运营和产品策略，是大数据技术的关键价值之一。互联网企业大数据平台上运行的绝大多数大数据计算都是关于数据分析的，各种统计、关联分析、汇总报告，都需要大数据平台来完成。下面给你讲一个我曾经遇到过的真实案例。老板跟技术部说，我们要加强监控。技术部以为老板对程序运行监控不满意，这也是情理之中，当对技术人员说监控的时候，他们通常理解的监控就是程序运行期监控，包括操作系统监控和应用程序监控。所以技术部专门挖了做监控的专家，成立了监控运维开发团队，花了半年时间做了一个漂亮的技术运维监控系统。老板看了以后大惊，这是什么？你要的监控啊！啊？老板蒙掉了。老板其实想要的是运营监控，就是我下面要列举的那些运营数据指标，他需要全面快速了解这些指标，以发现公司运营中出现的问题。而技术部却给了他一个监控系统响应时间、执行超时、CPU 利用率的监控系统。从公司角度看，运营数据是公司运行发展的管理基础，既可以通过运营数据了解公司目前发展的状况，又可以通过调节这些指标对公司进行管理，即数据驱动运营。而运营数据的获得，需要在应用程序中大量埋点采集数据，从数据库、日志和其他第三方采集数据，对数据清洗、转换、存储，利用 SQL 进行数据统计、汇总、分析，才能最后得到需要的运营数据报告。而这一切，都需要大数据平台的支持。

互联网运营常用数据指标

不同的互联网行业关注不同的运营数据，细化来看，复杂的互联网产品关注的运营指标成百上千。但是有一些指标是我们最常用的，这些指标基本反映了运营的核心状态。

1. 新增用户数

新增用户数是网站增长性的关键指标，指新增加的访问网站的用户数（或者新下载 App 的用户数），对于一个处于爆发期的网站，新增用户数会在短期内出现倍增的走势，是网站的战略机遇期，很多大型网站都经历过一个甚至多个短期内用户暴增的阶段。新增用户数有日新增用户数、周新增用户数、月新增用户数等几种统计口径。

2. 用户留存率

新增的用户并不一定总是对网站（App）满意，在使用网站（App）后感到不满意，可能会注销账户（卸载 App），这些辛苦获取来的用户就流失掉了。网站把经过一段时间依然没有流失的用户称作留存用户，留存用户数比当期新增用户数就是用户留存率。

用户留存率 = 留存用户数 / 当期新增用户数

 

计算留存有时间窗口，即和当期数据比，3 天前新增用户留存的，称作 3 日留存；相应的，还有 5 日留存、7 日留存等。新增用户可以通过广告、促销、病毒营销等手段获取，但是要让用户留下来，就必须要使产品有实打实的价值。用户留存率是反映用户体验和产品价值的一个重要指标，一般说来，3 日留存率能做到 40% 以上就算不错了。和用户留存率对应的是用户流失率。

用户流失率 = 1 - 用户留存率

3. 活跃用户数

用户下载注册，但是很少打开产品，表示产品缺乏黏性和吸引力。活跃用户数表示打开使用产品的用户数，根据统计口径不同，有日活跃用户数、月活跃用户数等。提升活跃是网站运营的重要目标，各类 App 常用推送优惠促销消息给用户的手段促使用户打开产品。

4. PV

打开产品就算活跃，打开以后是否频繁操作，就用 PV 这个指标衡量，用户每次点击，每个页面跳转，被称为一个 PV（Page View）。PV 是网页访问统计的重要指标，在移动 App 上，需要进行一些变通来进行统计。

5. GMV

GMV 即成交总金额（Gross Merchandise Volume），是电商网站统计营业额（流水）、反映网站营收能力的重要指标。和 GMV 配合使用的还有订单量（用户下单总量）、客单价（单个订单的平均价格）等。

6. 转化率

转化率是指在电商网站产生购买行为的用户与访问用户之比。

转化率 = 有购买行为的用户数 / 总访问用户数

用户从进入网站（App）到最后购买成功，可能需要经过复杂的访问路径，每个环节都有可能会离开：进入首页想了想没什么要买的，然后离开；搜索结果看了看不想买，然后离开；进入商品详情页面，看看评价、看看图片、看看价格，然后离开；放入购物车后又想了想自己的钱包，然后离开；支付的时候发现不支持自己喜欢的支付方式，然后离开…一个用户从进入网站到支付，完成一笔真正的消费，中间会有很大概率流失，网站必须要想尽各种办法：个性化推荐、打折促销、免运费、送红包、分期支付，以留住用户，提高转化率。以上是一些具有普适性的网站运营数据指标，具体到不同的网站根据自身特点，会有自己的指标。比如百度可能会关注“广告点击率”这样的指标，游戏公司可能会关注“付费玩家数”这样的指标。每个产品都应该根据自身特点寻找能够反映自身运营状况的数据指标。为了便于分析决策，这些指标通常会以图表的方式展示，即数据可视化。数据可视化图表与数据监控

数据可视化图表与数据监控

数据以图表方式展示，可以更直观展示和发现数据的规律，互联网运营常用可视化图表有如下几种。

1. 折线图

折线图是用的最多的可视化图表之一，通常横轴为时间，用于展示在时间维度上的数据变化规律，正向指标（比如日活跃用户数）斜率向上，负向指标（比如用户流失率）斜率向下，都表示网站运营日趋良好，公司发展欣欣向荣。

2. 散点图

数据分析的时候，散点图可以有效帮助分析师快速发现数据分布上的规律与趋势，可谓肉眼聚类算法。

3. 热力图

热力图用以分析网站页面被用户访问的热点区域，以更好进行页面布局和视觉展示。

在地图上展示的热力图则表示了该地区的拥堵和聚集状态，方便用户进行出行规划。

4. 漏斗图

漏斗图可谓是网站数据分析中最重要的图表，表示在用户的整个访问路径中每一步的转化率。当重要的营收指标（GMV、利润、订单量）发生异常的时候，就必须要对整个的漏斗图进行分析，判断是网站的入口流量发生了问题，还是中间某一步的转化发生了问题；是内容的问题还是系统的问题，需要逐个进行分析排查。除了发现提升网站运营效率的关键点与方法，分析找出异常问题的根源也是数据分析最重要的工作之一。

此外还有柱状图、饼图等，也经常用于数据分析和展示。可视化图形在数据分析时可以帮助分析师更准确、更快速做出趋势预判并发现问题，在汇报工作时使用图表更有说服力，决策时也更有依据和信心。俗话说得好，“一图胜千言”，多掌握一些图表技巧可以使工作中很多事情事半功倍。以上示例用的图表都来自于ECharts。https://echarts.apache.org/zh/index.html

ECharts 百度开源的一个前端可视化图表组件，使用这个组件，只需要几行代码，就可以将运营数据以炫酷的方式可视化展示出来。小结大数据技术最终落地必须要为企业带来实际价值，数据分析是其中最主要的应用场景之一。分析结果是最终的成果展示，在此之前，数据的采集、清洗、转换、存储、计算、分析，需要大量的工作。既然已经做了这么多工作，如何将最终的工作成果包装得更加直观、有科技感，技术人员需要换位思考，从用户角度、非技术角度去思考，争取让自己的工作更得到认可，实现更大价值。很多互联网公司都有监控大屏，一个目的是做展示用，在公司显眼的位置放一个大屏幕，显示主要的运营指标和实时的业务发生情况，给公众和参观者展示直观的公司商业运营情况。比如天猫每年双十一的时候，都会通过大屏幕直播实时购物数据。

监控大屏的另一个目标就是实时展示业务运营状况，让我们对自己的工作成绩一目了然。如果数据突然出现波动，相关人员也可以快速响应，排查是技术问题还是运营市场问题，实现快速分析、快速解决。思考题对于今天文章开头提到的案例，如果换作你，老板跟你说，我们需要一个更强大、快速的监控系统的时候，你该如何回应？

33 | 一个电商网站订单下降的数据分析案例

企业运营的数据可以让管理者、运营人员、技术人员全面、快速了解企业的各项业务运行的状况，并发现公司可能出现的经营问题，进而能通过这些指标进行详细分析，最后定位问题的原因，并找到解决的办法。今天我们一起通过一个案例，来看看如何通过数据分析追踪并解决问题。

数据分析案例

X 网站是一家主营母婴用品的电商网站，网站运营多年，是该领域的领头者之一，各项数据指标相对比较稳定。运营人员发现从 8 月 15 日开始，网站的订单量连续四天明显下跌。由于受节假日、促销、竞争对手活动等影响，日订单量有所起伏是正常现象，所以前两天（8.15、8.16）运营人员并没有太在意。但是，8 月 18 号早晨发现 8 月 17 号的订单量并没有恢复到正常水平，运营人员开始尝试寻找原因：是否有负面报道被扩散，是否竞争对手在做活动，是否某类商品缺货、价格异常，但是并没有找到原因。并且第二天发现订单量依然没有恢复正常，于是将问题提交给数据分析团队，作为最高优先级成立数据分析专项小组进行分析。

你从上图可以看到，8 月 15 日开始订单量明显下滑。数据分析师第一反应是网站新增用户出现问题，因为历史上出现过类似比例的订单量下跌，当时查找到的原因是，网站的主要广告推广渠道没有及时续费，广告被下架，新增用户量明显下滑导致订单量下降。数据分析师拉取了同期的新增用户量数据，发现新增用户并没有明显下降，如下图所示。

拉出同期的日活数据查看，发现日活数据也没有明显下降，便做出基本判断：用户在访问网站的过程中，转化出了问题。和一般的电商网站类似，X 网站的常规转化过程也是：用户打开 App，搜索关键词查找想要的商品，浏览商品搜索结果列表，点击某个商品，查看该商品的详细信息，如果有购买意向，可能会进一步咨询客服人员，然后放入购物车，最后对购物车所有商品进行支付，产生有效订单。X 网站的转化漏斗如下。

如果定义打开 App 为活跃，那么网站的整体转化就是活跃到订单的转化，公式为：

订单活跃转化率 = 日订单量 / 打开用户数

显然从 15 号开始，这个转化率开始下降，但转化过程有多个环节，那么具体是哪个环节出了问题呢？数据分析师对转化过程每个环节计算转化率。例如：

搜索打开转化率 = 搜索用户数 / 打开用户数

以此类推，每个环节都可以计算其转化率，将这些转化率的近期历史数据绘制在一张折线图上，就可以看到各个环节转化率的同期对比视图。

由于比例关系，图中可能不太明显，但是还是可以看出，有明显降幅的是咨询详情转化率（最下方折线），降幅接近 10%。调查客服也没有发现异常情况，进一步对咨询信息分类统计后发现，新用户的咨询量几乎为 0，明显不合常理。数据分析师自己注册了一个新用户然后发起咨询，没有得到回复。查询后台，发现咨询信息没有到达客服。于是将问题提交给技术部门调查，工程师查看 8 月 15 日当天发布记录，发现有消息队列 SDK 更新，而咨询信息是通过消息队列发给客服的。进一步调查发现是程序 bug，新用户信息构建不完整，导致消息发送异常。最后紧急修复 bug 发布上线，第二天订单量恢复正常。

>该案例为虚构案例，仅用于数据分析过程演示。

数据分析方法

辩证唯物主义告诉我们，这个世界是普遍联系的，任何事物都不是孤立存在的。所以当出现运营数据异常的时候，引起异常的原因可能有很多，越是根本性的问题，越是有更多引起问题的可能，如何进行数据分析，其实并不是一件简单的事。数据分析中，有一种金字塔分析方法。它是说，任何一个问题，都可能有三到五个引起的原因，而每个原因，又可能有三到五个引起的子原因，由此延伸，组成一个金字塔状的结构。我们可以根据这个金字塔结构对数据进行分析，寻找引起问题的真正原因。上面案例中一开始运营人员自己寻找订单量下降原因的时候，其实就用了金字塔分析方法。

金字塔分析方法可以全面评估引起问题的各种原因，但是也可能会陷入到太过全面，无从下手或者分析代价太大的境况。所以要根据经验和分析，寻找主要原因链路。绝大多数互联网产品的主要原因链路就在转化漏斗图上，上面案例中，数据分析师的分析过程，基本就集中在转化漏斗上。我曾经看过某独角兽互联网公司的数据运营指导文件，对于几个关键业务指标的异常必须要及时通知高管层，并在限定时间内分析异常原因。而指导分析的链路点，基本都在转化漏斗图上，只不过因为入口渠道众多，这样的分析链路也有很多条。这种金字塔方法不仅可以用于数据分析过程，在很多地方都适用，任何事情都可以归纳出一个中心点，然后几个分支点，每个分支点又有几个子分支。构建起这样一个金字塔，对于你要表达的核心观点，或者要学习知识，都可以有一个清晰的脉络，不管是和别人交流，还是自己思考学习，都很有帮助。上面画的金字塔分析图其实就是思维导图，我的大数据专栏的知识点也可以用金字塔方法描述。

人如何进行高效的思考，一方面是天分，一方面可以通过训练提高。我见过最厉害的人，他的思考过程如飞鸿掠影，不留痕迹；讨论问题的时候，往往只描述清楚问题，还没展开讨论，他就能直指问题的根源，其他人再争论半天，才发现确实如他所言。还有一种人，他会详细分析各种可能的原因，排查、分析、否定各种可能，最后找到问题的结症。因为过程严谨、思路清晰，所以通常也能解决真正的问题。前一种，我想大概主要靠天分，而后一种，其实就是使用金字塔方法。但是在实际中，我却经常见到第三种情况：没有前一种的天分，也不愿付出后一种的努力，思考过程天马行空，抓不住重点，找不到突破口，越想越乱，越思考越糊涂。其实，金字塔方法并不难掌握，只要用心学习、训练，每个人都可以学会这种思考方法。小结数据分析是大数据最主要的应用场景，很多企业所谓的大数据其实就是大数据分析，而大数据分析也确实能够对企业管理和运营起到积极的推进作用。而企业的管理、产品、技术过程中的各种决策、外部市场环境的变化，也都会在数据上反映出来。关注数据分析，抓住数据，就能抓住企业运行的关键。而企业在运营过程中出现的问题，也可以通过数据分析定位，发现引起问题的原因，并从根本上解决问题。前面专栏有同学留言说“我在公司做大数据多年，现在大数据平台已经稳定，数据量和业务都没有太大变化，工作重复，也没有什么进步，不知道下一步该怎么走”。我建议技术人员可以有更开阔的视野，不要仅仅给自己定位就是一个写代码的，比如也可以尝试去做一些数据分析，拥有数据思维、产品思维、商业思维，然后不管你还是想继续写代码，还是就此发现了自己新的天赋点，你的思路和人生之路都会更加开阔。思考题学习和工作计划也可用思维导图来完成，总目标、子目标，可以逐级分解，最后每个小目标都可以用几周甚至几天完成。这样，当绝大多数小目标完成了，今年的大目标也就完成了。在专栏的“新年寄语”中，很多同学都留言写下自己的新年目标和期望，你能否用思维导图将这个目标分解成一个金字塔结构呢？

 

34 | A/B测试与灰度发布必知必会

在网站和 App 的产品设计中，经常会遇到关于哪种产品设计方案更优的思考和讨论：按钮大一点好还是小一点好；页面复杂一点好还是简单一点好；这种蓝色好还是另一种蓝色好；新的推荐算法是不是真的效果好…这种讨论会出现在运营人员和产品经理之间，也会出现在产品经理和工程师之间，有时候甚至会出现在公司最高层，成为公司生死存亡的战略决策。在 Facebook 的发展历史上，曾经多次试图对首页进行重大改版，甚至有时候是扎克伯格亲自发起的改版方案，但是最终所有的重大改版方案都被放弃了，多年来 Facebook 基本保持了一贯的首页布局和风格。相对应的是，一直被认为抄袭 Facebook 的人人网在 Facebook 多次改版举棋不定的时候，毅然进行了重大的首页改版，摆脱了长期被诟病的抄袭指责。但是讽刺的是，事后回头再看，伴随着人人网改版的是用户的快速流失，并最后导致了人人网的没落，而 Facebook 的守旧却保证了 Facebook 的持续发展。让 Facebook 放弃改版决定的，正是 Facebook 的 A/B 测试。Facebook 开发出新的首页布局版本后，并没有立即向所有用户发布，而是随机选择了向大约 1% 的用户发布，即这 1% 的用户看到的首页是新版首页，而其他用户看到的还是原来的首页。过一段时间后观察两部分用户的数据指标，看新版本的数据指标是否好于旧版本。事实上 Facebook 观察到的结果可不乐观，新版本的用户数据指标呈下跌状态。扎克伯格不甘心，要求继续放大新版测试用户的比例，运营团队一度将新版测试用户的比例放大到 16%，但是数据显示新版并不受用户欢迎，数据指标很糟糕。最后扎克伯格决定放弃新版，首页维持原来布局。A/B 测试是大型互联网应用的常用手段。如果说设计是主观的，那么数据是客观的，与其争执哪种设计更好、哪种方案更受用户欢迎，不如通过 A/B 测试让数据说话。如果人人网当初认真做 A/B 测试，也许不会贸然改版；据说今日头条为了论证两条新闻之间的分割究竟应该用多宽的距离，同样是做了数百组 A/B 测试。

所以 A/B 测试是更精细化的数据运营手段，通过 A/B 测试实现数据驱动运营，驱动产品设计，是大数据从幕后走到台前的重要一步。

A/B 测试的过程

A/B 测试将每一次测试当作一个实验。通过 A/B 测试系统的配置，将用户随机分成两组（或者多组），每组用户访问不同版本的页面或者执行不同的处理逻辑，即运行实验。通常将原来产品特性当作一组，即原始组；新开发的产品特性当作另一组，即测试组。经过一段时间（几天甚至几周）以后，对 A/B 测试实验进行分析，观察两组用户的数据指标，使用新特性的测试组是否好于作为对比的原始组，如果效果比较好，那么这个新开发的特性就会在下次产品发布的时候正式发布出去，供所有用户使用；如果效果不好，这个特性就会被放弃，实验结束。

对于一个大型网站，通常都会开发很多新产品特性，其中很多特性需要进行 A/B 测试，所以在进行流量分配的时候，每个特性只会分配到比较小的一个流量进行测试，比如 1%。但是由于大型网站总用户量比较大，即使是 1% 的用户，实验得到的数据也具有代表性了。Facebook 拥有几十亿用户，如果 A/B 测试的新特性对用户不友好，那么即使只测试 1% 的用户，也有几千万用户受到影响。所以，在进行 A/B 测试时对实验流量和特性的选择也要谨慎对待。

A/B 测试的系统架构

A/B 测试系统最重要的是能够根据用户 ID（或者设备 ID）将实验配置参数分发给应用程序，应用程序根据配置参数决定给用户展示的界面和执行的业务逻辑，如下图。

在实验管理模块里进行用户分组，比如测试组、原始组，并指定每个分组用户占总用户的百分比；流量分配模块根据某种 Hash 算法将用户（设备）分配到某个实验组中；一个实验可以有多个参数，每个组有不同的参数值。移动 App 在启动后，定时和 A/B 测试系统通信，根据自身用户 ID 或者设备 ID 获取自己参与的 A/B 测试实验的配置项，根据配置项执行不同的代码，体验不同的应用特性。应用服务器和 A/B 测试系统在同一个数据中心，获取实验配置的方式可以更灵活。移动 App 和应用服务器上报实验数据其实就是传统的数据采集，但是在有 A/B 测试的情况下，数据采集上报的时候需要将 A/B 测试实验 ID 和分组 ID 也上报，然后在数据分析的时候，才能够将同一个实验的不同分组数据分别统计，得到 A/B 测试的实验数据报告。

灰度发布

经过 A/B 测试验证过的功能特性，就可以发布到正式的产品版本中，向所有用户开放。但是有时候在 A/B 测试中表现不错的特性，正式版本发布后效果却不好。此外，A/B 测试的时候，每个功能都应该是独立（正交）的，正式发布的时候，所有的特性都会在同一个版本中一起发布，这些特性之间可能会有某种冲突，导致发布后的数据不理想。解决这些问题的手段是灰度发布，即不是一次将新版本发布给全部用户，而是一批一批逐渐发布给用户。在这个过程中，监控产品的各项数据指标，看是否符合预期，如果数据表现不理想，就停止灰度发布，甚至进行灰度回滚，让所有用户都恢复到以前的版本，进一步观察分析数据指标。灰度发布系统可以用 A/B 测试系统来承担，创建一个名叫灰度发布的实验即可，这个实验包含这次要发布的所有特性的参数，然后逐步增加测试组的用户数量，直到占比达到总用户量的 100%，即为灰度发布完成。灰度发布的过程也叫作灰度放量，灰度放量是一种谨慎的产品运营手段。对于 Android 移动 App 产品而言，因为国内存在很多个应用下载市场，所以即使没有 A/B 测试系统，也可以利用应用市场实现灰度发布。即在发布产品新版本的时候，不是一次在所有应用市场同时发布，而是有选择地逐个市场发布。每发布一批市场，观察几天数据指标，如果没有问题，继续发布下一批市场。

小结

A/B 测试的目的依然是为了数据分析，因此通常被当作大数据平台的一个部分，由大数据平台团队主导，联合业务开发团队和大数据分析团队合作开发 A/B 测试系统。A/B 测试系统囊括了前端业务埋点、后端数据采集与存储、大数据计算与分析、后台运营管理、运维发布管理等一个互联网企业几乎全部的技术业务体系，因此开发 A/B 测试系统有一定难度。但是一个良好运行的 A/B 测试系统对企业的价值也是极大的，甚至可以支撑起整个公司的运营管理，我们下期会详细讨论。

思考题

A/B 测试需要在前端 App 根据实验分组展示不同界面、运行不同业务逻辑，你有没有比较好的设计方案或者技术架构，可以更灵活、对应用更少侵入地实现这一功能？