编辑导语：数据分析是推进业务项目正常进行的必要步骤之一，其中，包含了监控、观察、分析等步骤。那么在这些步骤中，有哪些方面是需要注意的？相应的，数据后台设计又应该如何操作？本篇文章里，作者就数据分析与数据后台设计思路做了梳理和阐述，一起来看一下。

许多年以后，面对诸多的数字时，我一定会想起老师教我假设检验的那个遥远的夏天。

模仿《百年孤独》回忆了一下大学学习试验统计设计课程，彼时的我对于统计学、试验设计等枯燥的课程满不在意，草草学习混完学分，以致于在本科毕业做毕业设计时又不得不恶补做实验、监控数据、观察分析，分析数据的知识，撰写完论文感叹总算脱离了苦海。

但是人生总是有很多“宿命”一般的轮回，当我毕业以后以为脱离了苦海，不用再和枯燥的数字和统计学打交道，然而工作后的数字依然是我离不开的东西。当开发人员每每质疑我，让我拿出数据以及分析结论来证明我的观点以及需求可靠性时，我就和《百年孤独》里的奥雷利亚诺上校一样陷入回忆怀疑过去的选择。

记得做毕业设计实验时，每次紧紧地盯着实验数据，生怕数据波动实验出现异常。实验结束后整理收集好的数据，每过一段时间就要对着一长串跨日的数据想有没有问题，最后靠着人工整理成的Excel“数据后台”再进行深入分析整理，我至今都还记得使用假设检验流程，其中用正交试验方法论证了结论的显著性。勉强完成了一篇看似科学的论文，就这么糊涂的毕业了。

而几年后工作受挫的某一天，想起曾经也这么“专业”地做过数据分析，为什么现在反倒面对数据只能望数生叹了。

于是我想着通过我写毕业论文的这个小故事，分享一些关于数据分析以及设计数据后台的思路，不谈具体的方法，从思考方向上分享一些经验，帮助诸君找到解决问题的思路与方向带来启发。

首先谈谈数据分析的方向。

我将数据分析按照执行顺序分为监控、观察以及分析三个部分，可以理解为监控数据是观察数据的基础，观察数据是分析数据的来源，分析数据是一次数据分析行为的结果。那么就让我们从监控数据开始。

一、监控

平时我们经常说看数据，其实看数据就是监控数据了。监控数据还没有到观察或者分析数据过程，监控的目的在于发现当前的实验或者产品发展是否存在问题或者观察效果。监控数据最大的意义在于及时发现问题以及及时调整，避免问题的产生。

之所以说监控是数据分析最初的过程，是因为数据分析的目的在于解决问题，而当前并没有明确的问题目标需要解决的时候，监控便是最经常进行的一个数据管理环节，此时监控更加偏重于解决隐患。

以上的概念比较枯燥与抽象，不妨看看以下两个例子来感受一下监控的意义。

游戏是目前我们经常接触的产品了，作为游戏的开发者而言，监控同时在线人数，可以帮助开发者及时了解游戏的运行情况以及评估当前服务器等资源的压力情况。

监控同时在线人数，需要细粒度的时间，快速响应的数据计算以便帮助分析者高效且直观地了解游戏同时在线玩家的人数，并做好应对措施。

SLB（负载均衡）是网络服务中常见的功能，对于运维或者服务端开发工程师而言，监控SLB是保证自身服务正常的必须步骤。

与上一例中游戏同时在线人数监控一样，SLB的监控需要极细的时间力度，且非常快速的数据计算，以便运维及服务端工程师及时的了解当前情况，避免服务产生异常。

监控数据是整个数据分析环节的基础，所有的想法均来源于每一次监控获取的信息。对于监控数据，需要达到以下几个要求方能保证监控的质量与效率：

1. 数据计算要高时效性；
2. 数据时间粒度小；
3. 数据指标精简，核心；
4. 以可视化图表体现。

前两点在举例过程中已有说明，细粒度的时间与快速的计算相应可以及时及客观的响应。由于监控是一个高频的行为，我们不可能针对实验或者产品运行中的每个关注指标都进行监控，所以监控数据时，根据目的必须挑选最为核心、重要的指标监控。

为了保证监控的效率，像我毕业设计时一样依靠人工记录数据的方式十分低效，因为单纯的数字很难直观地反应出数据的变化，因此好的可视化图表可以非常有效地帮助分析者发现问题或者评估效果。

监控数据作为数据分析的基础，是一个看起来技术含量不高但频繁的行为，这个看似枯燥的行为需要对目标、数据极其敏感与了解，方能真正地发现问题以及客观的评估效果。

监控的关键在于让我们知道，存在问题吗？

二、观察

接着聊聊观察数据。

监控数据更多在于发现问题与评估效果，由于监控数据更多聚焦于某一天的某个时段，时间周期很短，在大多数实验以及产品运行过程中，监控的数据偏少且时间短，无法作为有效且合理的参考，此时我们需要更多的数据指标、更长周期的数据来对比、评估，这个观察数据的行为建立在监控的基础上。

我们当然可以不监控直接观察数据，监控的确并不是观察的充分条件。但是少了监控，我们会缺少更加实时、及时以及详细的数据参考来支持判断。因为观察数据的目的与作用在于通过多指标、长时间的数据对比、观察数据起伏等变化来定位发现问题或是分析是否存在问题、是否按照预期发展，相对于监控的数据更加宏观的观察数据更加消耗精力，但监控依然是一个非常重要的行为。

以我亲身经历的一个小故事为例子。

曾经我所负责的游戏连续两天用户数都差不多，但是两天的用户时长却有显著差别。由于这两天并没有关注实际情况，在过了将近十天后回顾分析时一时无法得出有效的观点。

当时的我与同伴排除了产品出现异常、产品两天内有更新导致功能不同等会造成两天存在显著变化的情况。当时负责监控用户增长的同伴提供了一个线索，在后一天中由于游戏政策问题会有部分用户出现实名认证的过程，导致玩家进入游戏后被实名认证窗口卡在初始无法进入游戏。

随后我们查询了这两天的同时在线人数曲线，发现第二天曲线比前一天要明显低很多，而且从实名认证开始就出现了显著的下滑。因此我们得出了以下几个观点。

虽然用户进入了游戏，但是有部分用户未实名认证，导致他们无法进行游戏，有部分人因为各种原因未及时实名认证选择了退出游戏，因此造成了同时在线人数的下滑。

两天统计到的用户数量差别不大，是因为用户都进入了游戏，但是后一天的部分用户因为实名认证的原因很快就退出了游戏，造成这一天用户的平均时长下滑。

这是一个简单的例子，其实当时的我们完全可以凭借因为实名认证导致用户无法登录进而造成用户退出无法游戏来解释时长的下滑，但是这个观点本身就需要一些数据来支持。

此时我们监控同时在线人数就能为这个观点提供一定的支持。所以观察数据是建立在监控数据的基础之上。从观察数据的过程中，我们得出了一些观点从而找到执行策略的思路以及依据就是这个过程最大的意义。

观察数据需要较长时间的数据、较多的数据指标进行综合对比、评估方能针对一个问题得出合理的观点。

指标数值的变化之所以能反应问题，是因为这个指标是目标问题具有显著性影响的因素。很多的问题分析时，是需要确认多个因素的影响能力方能得出问题结论，所以观察数据时对于数据的要求也更高，观察时数据当满足以下几个要求时可为观察过程提供足够的支持：

1. 数据粒度以日为主，时间区间长；
2. 数据指标多维度、多角度；
3. 数据主要以表格体现，图片为辅。​

日粒度以及更大粒度的数据是为了观察时有更丰富的数据便于对比，比如互联网产品中日留存、周留存与月留存能反应产品在不同时间维度下的留存能力。

数据指标多维度多角度更多体现在需要足够数量的核心指标帮助观察数据时进行对比。由于前两点的要求，此时可视化的图相比监控数据过程重要性降低，此时数据表格可以更加便利的展示数据，当然表格+图是更好的选择。

同样举两个例子。

上图是友盟机型分析的示例图，其中提供了新增用户与启动次数两个核心指标，用以分析不同机型的新用户在游戏中的表现，进而分析不同机型用户的质量。这是一类以聚焦日粒度为主亦可跨日分析的多指标数据。

上图是友盟整体趋势的示例图，其中提供了多个体现用户数量、留存率、时长、启动次数等与用户行为直接相关的指标帮助分析者观察数据。

与上一个例子不同点在于，虽然都是多指标观察，但是这个例子是聚焦于跨时间对比分析的数据，因为活跃、新增用户数作为一个数值容易受推广、活动、节假日等因素直接影响，此时不同日期的数值对比意义并不大，这时候加上留存、时长等综合型的指标，通过不同时间的综合对比观察，就可以更加便捷且客观地得出观点。

以上两个例子分别代表了聚焦于某天内多个影响因素以及聚焦于长时间多个影响因素的观察行为，对于不同的观察数据行为，在数据的呈现以及表现上也有不同。

观察的关键则在于让我知道，问题是什么。

三、分析

最后到了分析数据环节。

我并没有讲分析数据的方法或者工具的打算，本文的目的依然是分享一些我的数据分析思路以及根据思路而衍生的数据后台设计经验，通过思路可以帮助大家思考找到解决问题的方向与启发。所以在分析数据这个环节依然谈的还是从监控到观察最后到分析这个过程的一些看法。

当我们观察数据以后，此时脑海中已经收获了不少的信息，将这些信息进行整合根据目标进行思考的过程我称之为分析。

分析的目的与意义在于发现问题或者是验证结论，这是两件事。如果目标是发现问题，那么从众多的数据指标中、从多维度多角度的数据中发现问题，是一个主动且存在未知性的行为。而如果目标是验证结论，那么问题是清晰的，我们需要的是从数据中找到证据，这是一个相对被动且已知的行为。

当问题已知的情况下，不论是找到问题的影响因素还是已知影响因素来确认对问题的影响，都已经有了非常明确的目标，此时分析数据的意义就是找到支撑问题解决方法的依据或是解决方法的思路。

因为分析数据的目标在于找到解决方法，所以分析数据时对于数据的要求比观察数据更高，根据分析数据的行为，要求更为直接：

1. 足够的数据指标作为基础用于分析；
2. 足量的数据（时间粒度、时间长度）作为依据；
3. 使用一定的科学方法得出合理结论。

足够的指标以及足量的数据是为了保证在使用分析方法时有足够的内容得出客观的结论，否则在缺少支持的情况得出的结论依然值得质疑。

分析这个环节考验的是分析者对于数据的掌握程度、对于问题的明确程度以及对于分析方法的了解程度。很多时候不必过于偏重于方法的账号，对于日常中的很多问题，对问题的理解到位加上对于数据的高度理解加上简单的方法也可以得出有效的结论。

分析方法建立在对于统计学、概率统计等数据科学的基础上，不在结合问题与目标的基础上盲目追求掌握方法，并不会对数据分析有太好的帮助。缺乏监控和观察的过程，直接拿到数据也未必能有合理的判断，因为缺少长时间观察监控数据造成对数据的理解，很容易被先入为主的想法影响从发现问题变成验证先入为主的想法。分析的过程已经脱离了数据后台，此时需要靠扎实的态度与数据科学知识帮助自己。

结合分析这部分，我仅以我个人的经验总结了几条数据分析与数据后台的想法：

1. 通过多种监控来观察数据，通过观察数据得出分析思路，通过分析得出结论；
2. 看数据的不同行为，提升效率的方式不同，需要后台提供不同的功能来满足；
3. 后台更多的是为监控和观察提高效率，分析依赖于数据分析者本身的主观行为、能力。

最后还想分享的是，多学、多讨论，数据分析这件事通过讨论交流得来的知识与信息，往往比掌握一个看似高端而不常用的分析方法来的实在。

分析的关键在于让我知道，该做什么。

第二大部分谈谈数据后台的设计思路。

在了解了数据分析的过程以及各过程的目标、关键至后，针对不同过程，数据后台在功能的支持上也有针对性与特殊性。

在监控数据与观察数据过程中，后台可以通过图、表格高效的展示数据，帮助分析者在看数据时思考获取信息，而分析数据则需要分析者脱离后台的限制根据目标问题进行分析，此时便已经脱离后台了。可以说数据后台奠定了分析数据的基石，因为所有思考分析都来源于数据后台的每一个指标、每一张图以及每一个表格，分析过程依赖于分析者而非后台。

如今的数据类产品已经发展成为监控观察以后台为主，分析思考以工具为主的模式。数据后台提供的是原材料，而像PowerBI、FineBI以及tableau这样的商业智能工具成为了分析数据的利器。数据后台更多在于满足监控与观察，而对于分析过程而言便捷的提供数据获取功能即可，之后的事情则需要交给具有强大分析功能的各类工具。

那么还是从监控数据开始。

在前文举例说明监控数据的要求时，游戏的同时在线人数与阿里云SLB监控两个例子突出了可视化图、细时间粒度的特点，但这只是针对了范围很小的一些数据指标。

以一个电商类产品为例，我需要实时了解交易金额、交易笔数、同时在线人数等指标时，就需要一个更为综合的监控界面帮助分析者快速了解情况，此时在后台的设计上则不能简单的根据需求用可视化图的方式罗列指标展示，因为不同指标在监控对比时时间粒度上不一样。比如同时在线人数可以精细到分钟粒度，而交易金额则可以到小时粒度。

根据例子中这种情况，在后台的设计上，监控环节需要根据需求针对性的设计，这里推荐的设计思路是使用个性化可定制的监控面板。

监控面板可以由后台开发者事先设计好可提供的指标、图表由分析者进行选择组合成自己需要的样子，可以理解为当一个Excle中放了非常多的数据，你可以自己排版各种数据与图表，然后在一个sheet中看自己关注的内容。

这里以友盟的分析看板为例。

这类看板的特点是可以先定义好所需的各类指标以及图表，然后由分析者自己进行组合，即可满足分析个性化的监控需求，同时还可以将不同时间粒度、不同类型指标根据各自特点设计成不同的图或者表，从而满足不同角色的监控数据需求。

监控类后台的特点在于尽量将需要关注的内容放在一个菜单页面中，便于分析者快速获取信息，不需要切换至不同的菜单。图加表格的组合，可以充分发挥各自特点，对于数值趋势的变化通过趋势图或者柱状图体现，辅以直接展示数值的表格，更加直观的了解数据。

接下去的观察数据环节在后台设计的思路上则有许多需要关注的重点。

1）图为主和图表结合的后台页面设计思路

首先看几个来自Talkingdata以及GameAnalytics的示例，两个后台均选择了游戏版Demo。

首先对于游戏而言，开发者、运营者首要关注的重点均为用户、收入，具体的指标即为用户数量、留存、时长、收入、ARPU、ARPPU等指标。这都是典型的多指标组合的观察需求。

由于游戏类产品需要观察的数据众多，所以需要进行分类，一般来说会区分用户类，包含但不限于活跃用户数、新增用户数、启动次数、用户时长、用户留存等指标，而收入类指标则包含但不限于内购收入、付费人数、付费次数、ARPU（每用户人均付费金额）、ARPPU（每付费用户人均付费金额）、首付用户数等指标，因为指标分类清晰且内容众多，所以将其分类成不同的菜单有利于根据目标问题针对性的分析。

这种菜单的分类的原则就是各个指标之间的关联性。在示例的三个后台中，均采用了图为主的展示方式，在talkingdata后台中则还有切换图和表的模式，但是优先展示的依然是图。

这种后台设计思路的原因在于观察数据时，每个指标都分别配上可视化的图可以更直接的表现数据的变化起伏、对比多和少。每个指标都有独立的图展示，非常有效的为观察数据提供了直观的数据展示，这个比起表格有着非常直接的效率优势。

多图的组合可以快速的收获各个指标的信息，以talkingdata示例图为例，不论是跨日的趋势分析、还是同日内的各年龄层收入分析，都可以快速地看到趋势、多少，不同类型指标通过不同图的组合，很容易突出各自关注的重点。收入使用趋势图，可以了解到近期收入的稳定性，而各年龄层收入则是集中在一天，可以快速了解对比不同年龄的付费能力，这都是图的优势。

以图为主的设计思路优势非常容易感受到，但是缺陷也非常明显，当分析者需要多指标综合对比观察时，这个设计思路下分散的指标则难以将数据聚合起来，此时观察数据时就较为麻烦。这种情况下图加表组合的后台页面思路便十分有效的解决了这个问题。

针对这个设计思路，请看来自友盟与天幕的示例图。

同样与前一个例子一样，两个后台数据针对指标进行了分类而分成了不同菜单，每个菜单中又是多个指标排列的情况。

友盟与天幕的后台都采用了上图下表的设计思路，上图的思路与前文以图为主的设计思路类似，都是通过可视化图直观、高效展示数据的特点直接的为分析者提供数据。

前文也谈到图的缺点在于无法同时展示多个指标在一个图中，每张图能获取的指标有限且多指标同时放在一个页面里图太多且不好整合，此时友盟与天幕的示例中下方罗列了多个指标的表格则有效地解决了这个问题。

上面的图可以切换展示下方不同的指标，且可根据指标的特点设计为突出分析思路的趋势图、柱状图或是其他可视化图，下方则可以将这个菜单中需要分析的指标排列开，便于分析者更加全面的综合对比分析。

为什么会有这两种常见的设计？似乎二者用起来并没有很大的区别。

从用户界面的设计角度来说，以图为主的思路更容易吸引眼球，图加表的模式相对枯燥。从使用者体验来说，区别则很大。以图为主的模式，将各个指标用图的方式展示，并分散开，和监控数据非常类似。每个指标通过图都可以快速的获取到超过数值带来的多或者少的信息。

以前文GameAnalytics示例图为例，收入分析中通过图不仅快速了解了当前收入、付费人数次数、ARPU等数值，还看到了这几个指标的发展趋势，用图快速的提供了每个指标数值加变化两种信息。下图天幕示例图同样展示了类似的收入指标，但是采用的是上图下表的组合。

这里的图只展示了一个指标，分析者需要通过表格方能快速获取各个指标数值信息。

这种设计思路下的对于分析者的思考而言，更多提供的是相比分散的图更加综合的多指标对比信息。分析者可以快速地从表格选择众多指标，与不同时间的同指标进行对比，而分析某个指标之时可以切换上方的图来分析具体指标。从单个指标的分析效率上来说弱于以图为主的方式，但是想要更加全面的分析时，表格的优势就非常明显了。

二者最大的区别在于获取数据信息时，关注点集中于某个指标的程度多还是少，一次想要获取的指标数量多与少，综合对比的程度强与弱。

区别可以说清楚，但是真正在设计做选择时，并没有明确的边界用以选择。

对于以上区别，在实际设计中还是要根据使用者的习惯以及产品本身来选择。比如说像阿里云一样的运维工程师常用的数据后台，监控需求是远大于观察与分析数据需求的，此时除了监控数据的界面设计需要图，日常观察的一些数据也可以多以图为主，在日常观察过程中便于从变化中发现隐患。

像游戏或是常见的资讯、工具类软件的数据后台，通常会是不同类型的指标罗列综合分析，此时轮流把每个指标的图看过去，反倒不如通过表格来展示。

观察数据与监控数据最大的不同在于数据内容更多，数据指标数量更多，日常分析时对于数据内容需求的多和少即是判断后台页面设计的基础准备，多则以图加表为主，少则以图为主。

判断标准不唯一，关键还是在于设计者需要充分考虑分析者对于数据信息量的获取需求进行判断。

2）数据和表格

日常在表格中展示的数据一般有两种，一种是以时间维度展示，另一种则是以某个分析对象为目标展示，具体看一看以下的例子。

阿里云支出的示例图中展示的是某个月各项服务的支出，talkingdata渠道分析展示的是某时间段内各个渠道的新增用户、收入、留存等指标。在分析的目标重要性优于时间时，此时数据的分析角度优先时当前的目标其次才是时间。

就阿里云支出例子而言，此时关注当月各项服务的支出，是优于各项服务在各月的支出；talkingdata的这个例子中，关注渠道用户质量优于各个渠道每天的用户数据。

这个以表格为主的设计，是为了满足非常具体的分析需求而产生的。在上一部分中谈到了图加表的设计思路，这时提供了非常综合的数据信息，多出现在以时间优先的数据中。而当时间不再是第一关注重点时，此时直接体现数据方面，图则是辅助，表格成为了重点。

像上面两个例子一样，这种情况非常具体，出现在观察数据的重点在于某个具体的问题，表格中不再是聚焦时间加指标的列表，而是关注分析目标加指标的列表，此时多以表格的方式直接展示数据，就算有可视化的图，也不再是常见的趋势图或者柱状图，而是饼状图或者直方图，用来展示当前分析目标中各个因素的组成以及组成数值的多少，这样偏重分析结果的图反倒不重要。

这里体现了两种不同的数据分析思路，前一点中谈到的后台设计思路多以基于时间维度来分析，而这一点中则是反过来，基于具体的分析目标之后才是时间维度，所以最后在数据的呈现上前者是时间序列的表格，后者时间成为了数据的一个属性，表格是目标的组成因素。

两种分析思路决定了后台不同的设计。反过来后台不同的设计对于使用的分析者而言带来的功能效果也不一样，前者突出通过时间来对比分析，后者弱化时间，突出对比同一个目标下的不同因素。

3）分析

分析数据的环节是数据分析整个过程中最重要的过程，这个过程脱离了后台带给分析者的内容，依赖于分析者自身的思考。从后台设计的来说，除了前文谈到的思路之后，针对分析这个环节只需要考虑做好数据导出功能，可满足分析者方便的自行组合整理数据即可。

洋洋洒洒数千字下来，最后做几句总结。

1. 分析应该脱离于后台的束缚，以问题为核心进行思考；
2. 如果是用数据验证猜想，在使用数据分析方法的同时注意数据足够多、指标足够丰富；
3. 如果是通过数据发现问题，在对比、观察的同时注意无特殊情况下的异常起伏；
4. 如果是使用数据得出一些结论，小心先入为主的限制，尽量从数据的变化中总结行为，根据行为阐述结论，尽可能减少主观的影响。

以上是笔者自己数据分析的一些经验之谈，比较抽象，但是笔者希望的是更带给更多人启发而不是问题的答案。如果笔者的经验之谈能真的为你带来有用的启发，不胜荣幸；如果这通篇毫无实操性可言，多是通识性的内容让你无所收获，那么请你莫吝惜言语，给予二三建议，笔者不胜感激。

本文由 @问梦孤独 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议