从设计到数据——写给非数据人的数据世界入门指南

供非专业人士学习交流，望专业人士勘察纠错。 

一. 一段经历，一点心得

一直追我博客的人想必是清楚我之前做交互设计，然后去轮岗过行业运营，然后突然就开始做产品经理了。我也觉得奇怪的是，上次发了一个招聘启事后，来加我微信的同学们，既有做交互的，也有做产品经理的，甚至还有在IBM做了5年BI数据分析师的……这样看来，我的博客逐渐成了一个交叉学科。

 

简单来说，也差不多如上图所示。

当时是一个新业务开拓，仅仅4个月的轮岗（非正式的轮岗，当时就是老大给了各个部门体验其他团队工作的机会，但是组织架构可以在轮岗结束后再恢复原岗位），结果成了职业历程上的分水岭。为什么呢？

行业运营除了日常的商家管理、活动策划以及选品外，当时的商业模式还需要我们介入整体的供应链管理。而虽然当时身处家居行业，供应链管理却是在不同行业之间有较大的共通性。所以后来又成立了一个横向的部门——供应链管理。于是从垂直行业里调出的部分同学加入这个横向部门。而供应链管理，离不开大量的数据分析工作，供应链整体效能如何？需要和BI部门通力合作，所以供应链管理部门合并到了BI部门。

于是我就“随波逐流”地成了BI部门的一员——虽然我们并不做具体的数据分析，更多是向分析师提需求。

 再后来，供应链整体效能的数据统计和分析，是靠分析师们每天出手工报表和报告发送给各部门管理人员的。发了一段时间后，分析师苦不堪言，接收方也过于被动，当他在邮件里看到某个数据异常时，无法自己主动地进行探索钻取，所以自然而然有了将供应链报告“产品化”的需求。

要求：短、平、快。

资源：极少。没有设计师、PD、以及充足的开发人员支持。

 原因很正常：大部分人都投入到了业务系统建设中（彼时，供应链管理系统、物流管理系统、认证系统、以及前台都处于开荒建设阶段）。

所以，因为我做过交互设计——会画DEMO；和PD接触时间长——多少知道PRD怎么写；又给分析师提过需求——知道数据大概怎么回事……

所以，我就“随波逐流”成了数据产品的产品经理。

插句后话，以后在晋升面试或者转岗面试时，当面试官问我怎么就突然从交互设计师转成数据产品经理时，最早我也是讲的随波逐流的故事……然后被挑战比较严重，后来换个说法：Why not?

有这个机会，大家都信任你，又不给你压力，又能学习到新领域的知识，和新的人打交道，同时还能继续沿用交互设计的技能知识，Why not? 然后对方就颔首了，所以讲故事的角度是多么重要。

说点这段故事中，让我真正坚定起来的两句话：

 一个老大说：“给你机会去试错，错了大不了重头再来。”

 另一个老大说：“设计师盯着皮肤看，产品经理要了解整体的经络组织和骨骼，更重要的是要知道数据作为血液如何在流通。你有机会深入皮肤之下看一下，再回来看皮肤感觉又不一样了。”

所以我是带着这个人体经络图的即视感忐忐忑忑接下了数据产品经理这个新的岗位的。

不用别人说，我也知道有两座大山需要翻：1. 数据 2. 产品经理。

二. 本文的目标

不指导就业，不提供数据分析解决方案，不承诺对任何人都必要有效。根据个人仅有的经验、心得，我只能：

1. 面向对数据分析、数据产品有兴趣但是又有点畏惧的交互设计师、产品经理

2. 希望能够让你们“减少对于数据世界的恐惧”，使用数据的语言“顺畅沟通”。

三. 欢迎进入数据的世界

 

还记得你学习游泳的经历吗？记得我当时就是怎么都不敢下水。

我的教练告诉我的最有用的一句话是：你会憋气吧？你试试在浅水区里什么都不要做，松开栏杆，憋住气，让自己沉下去。如果你受不了了，反正你一站就站起来了。

我一想，也对，反正浅水区嘛。于是第一次松开了栏杆。

奇怪的事情发生了。我居然不会沉入水底耶~甚至透过泳镜看别人的脚扑腾扑腾！原来水里的世界没有那么的可怕！

克服了这个对水的恐惧后，才开始慢慢学习各种动作，开始享受水的乐趣。

数据的世界对于不了解它的人而言，正如这神秘的水一样。

那么我提供的让你不怕“水”的心得有：两个词、一个立方体、一张流程图

你准备好了吗？

1. 两个词

先复习一下你可能也听过的两句话：  

• 如果你无法量化，那就无法很好管理。

• 无细分，不分析。

第一句话来自管理大师彼得德鲁克，第二句话则是分析界的金玉良言了。

这两句话里就隐含着我说的这两个词。

接下来，再来看一句话：成交10亿人民币！

肯定没有人单独说这样的话，一般情况，这句话前都要加上一些“定语”，比如“今年截至到7月份，全国蔬菜市场”，或“去年9月，女装市场”，或“过去N年，东三省猪肉市场”……等等。

这些语境里，也隐含着这两个词。

再来看一张图：

这是刚入门时，为了追求PPT的好看，做的一张概念图。虽然当时还没有体会到两个词的重要，但是从感觉上，我画了以上的图，有位前辈说，维度还不够。

哦，我后来才知道，中间的圈里，我大部分呈现的是度量，而下面的几个圈，我列了重要的一些维度。至于上面的几个圈里，应该是呈现的分析专题或功能。

至于你平时有机会接触到的各种数据可视化，报表，也基本上脱离不了这两个词，比如，若你去客服部门分析客户来电量（下图仅供演示，非真实场景数据）

1. 你按时间趋势来看总体来电量。当你发现某个月或某周来电量波动较大，你就需要添加别的“角度”来进一步细分。

2. 你按热线来细分来电量，看看来电拨打的什么热线。

3. 当你发现某个热线来电量波动异常后，你又需要进一步细分，看看此热线的来电是被什么接起公司承接的……

下面不卖关子了。有些人可能已经猜到了，我要分享的这两个词就是：维度+度量。

下图中，我将重点放到大道至简几个字，以及维度+度量上，而维度和度量下面分别放了所在家族的一些其他常用词汇，我稍后会解释。

我始终认为在这条路上，我有一个两词之师，当我比较迷茫的时候，他就像当时教我游泳的导师一样，告诉我：你不需要了解那么多，只要了解数据的世界没有那么复杂，知道有什么维度，看什么度量，然后怎么呈现出来即可。

对，他没有时间教我别的，也没有分享过任何文档给我，只告诉了我这句话，但是让我受益至今，因为那一刻，就是恍然大悟。所以我现在也分享给你们。

定义：

1. 度量：即Metrics, 指量化的数值。一般都有个名称，比如网页浏览次数，网页浏览时长，支付宝成交金额等等。平时，我们一般会叫成“指标”，但是在专业语境，你需要知道，指标和度量还是有些差异，比如某些场合，他们会用指标特指一些经过计算的度量结果，比如拿度量A（网站总浏览次数），除以度量B（网站总浏览人数），得到一个新的指标（网站人均浏览次数），用以衡量网站粘性。但是我建议你平时使用两者可以通用。

2. 维度：即Dimension。指我们平时看事物的角度。比如，同样是网站浏览次数（PV），我们可以从日期角度去看，也可以以流量来源去看（来自直接访问的、来自微博的、来自搜索的等），也可以以新老用户分群来看。更多的场景是同时以两个维度的组合去看，比如这样的图，就是同时结合了时间、来源两个维度对网站流量进行分析：

两者你知道如何清楚区分吗？

虽然从定义上，你可以看出明显不同，但是现实中，却还是有人喜欢乱用——把明明属于维度的东西写成“我要看什么指标”，或者喜欢用“我想从收藏人数这个维度去看”，虽然我属于强迫症，喜欢帮别人的需求纠错，被冠以扣字眼的“名号”，但是在这件事情，我一定要抠到底。

而且，你抠清楚了，以后你的世界也清晰很多。

区分的一个方法：维度，一定是有成员值的，且成员值是可以枚举出来的——不管它有多少，大不了你多花点时间去枚举，总之是一定可以枚举的，且会维持一定的稳定性。

比如，日期这个维度，几月几号一定是有限的，一年也就365天，如果是年这个维度，也是一样的。城市这个维度更好理解了吧？

其他你需要了解的：

1. 度量：

• 除了指标这个有着略略差异的俗称外，有时还会遇到衍生指标这个说法，比如拿指标A和指标B做运算得到的指标C就叫做衍生指标。此外，还要注意可累加以及不可累加的度量说法，比如网站UV（独立访问用户数），这个指标就是典型的不可累加的度量：

• 除了指标这个有着略略差异的俗称外，有时还会遇到衍生指标这个说法，比如拿指标A和指标B做运算得到的指标C就叫做衍生指标。此外，还要注意可累加以及不可累加的度量说法，比如网站UV（独立访问用户数），这个指标就是典型的不可累加的度量：

• 某网站1月1日UV=100个，1月2日UV=200个，但是这两天的UV不等于300个，因为1月2日的独立用户数里可能包含了1月1日的用户，所以如果要得到2天的UV，需要重新计算而不能直接相加。而像成交类的金额，不涉及到去重的问题，就叫可累加的度量。

2. 维度：

• 维度的层次：即Level。有些维度是独立并列的关系，比如城市维度和时间维度。但是有些维度之间有层次关系，比如省份维度和城市维度，行业维度和类目维度，年级维度和班级维度等。有层次关系的维度，则可用于“钻取”场景中，先汇总到比较粗的维度，当有需要的时候，可以层层钻取到更加明细的维度，此时，也会把这些维度叫做某维度类型的不同“粒度”——比如会有一个虚拟的维度类型曰地区维度，而把省份、城市、区叫做地区维的粒度。维度的层次根据不同的需求，可能会钻取到很细（Details）,那就是通常我们说的"明细数据"了。比如分析成交金额时，从行业维度，细分到一级类目乃至叶子类目，最后，钻取到某个独立的商品ID（不能再细了），商品ID就是最细小的层次维度。

这么说可能会把你绕晕，那么还是画个图吧（我真的适合当唐僧似的老师……o(╯□╰)o）

 如上图所示，左列也即维度，不管是国家、省份、城市，都是维度，但因为他们有层次关系，所以，有时会被描述为地区维度的不同粒度或层次（明白了吧）。而右侧就是每个维度的维度成员了，有时也被叫成维度值。在可累加的度量中，每一个维度值相加，应该等于上级维度的某成员值总和。比如若城市A只有三个区，这三个区的人口总数应该等于城市A的。 

• 维度的属性：用以描述维度的一些属性，比如上图中“城市”这个维度吧，它可能会有一些属性特征，比如城市类型：省会城市、地级市、县级市等，那么有一个分析需求，可能还会按不同城市类型汇总细分。这种情况，维度的属性会成为分析中的维度。

这时，你可能会明白，平时为什么那么多表单要填写各种字段，这些字段，都可能是分析时的维度哦~

码了这么多，休息一下，给你们放张图：

当时小贝和马云一碰面，无论在阿里还是网络上，都出现了一个两难的问题：到底是选谁当老公呢？（能有这个问题的妹子，你真想多了……），其实这里仔细分析，无非也是涉及到维度和度量两词：

• 维度：人啊。

• 维度成员：马云、小贝

• 度量：众位妹子和弟弟们无非就是按自己心目中的算法给两位成员计算颜值、财富，以及自己心目中的权重，衡量一个综合指数了……我可不敢随便填。

最后，发现两难的选择，只能得到一个结论是：左边的当老公，右边的当爸爸。

点评：做梦吧您。

总结一下：

两个词的应用：无论你听怎么复杂的需求，以及无论你有多么复杂的需求，请有倾向地提炼这两个词，因为这是你做数据产品、数据分析或者可视化设计的基础的基础：

翻了自己的电脑半天，终于翻出一个不敏感的文档，供参考，下图就是移动数据分析中的需求交付模版之一：左侧列举度量，右侧标注出此度量需要看的维度，有时还会注明维度之间是否要交叉组合查询。不展开。

2. 一个立方体

其实本文的精华就在两个词之间了。下面您看不看都成。

立方体在数据的世界里叫做Cube。我想为何有立方体这个概念，应该是它很形象地能够表达出多维的概念，至少有3维，如上图所示，成交100亿的金额，是一个大立方体的总量。如果按季度、行业、地区三个维度来分析，我们可以清楚地知道第三季度A地区女装行业有多少——也即我用橙色标注的那一个切块的量，是吗？

那如果是我要知道B地区女装行业四季度的成交总和呢？你怎么切给我？

空间感好的同学已经知道怎么切了，你知道吗？

这只是切块。我们还可以切片，比如我想要知道B地区所有行业的四个季度的成交总和，怎么切？我想要知道男装行业所有地区四个季度的成交总和怎么切？

具体怎么切，你们自己意会吧，篇幅有限，不展开。

现实分析场景中，恐怕不只三个维度，比如还要加上销售部门维度、销售渠道维度呢~ 那么立方体可就复杂了，空间感差一些的同学，就想想不出来这个立方体什么样子了吧，事实上，数据开发同学会用雪花模型或者星型模型去建设这些立方体。你只要有这个立方体的概念就可以了……数据分析就是像玩魔方一下，拨弄着这些立方体。

在网上找了一个包含了我刚才说的钻取、汇总的概念的立方体再给你们感受下，想要详细学习的同学可以搜索“数据立方体”继续研究。

我刚才举的那几个切块、切片的案例有毛用啊？

现实生活中，你提需求的时候，不可能让你画个立方体吧？是的，我们是以表格的方式去看数据的，比如第一个切块，是什么表格呢? 站在行业负责人，尤其是女装负责人的视角，可能是这样的一个报表：

 当然，如果是某地区销售经理，有可能是这样的：

所以就有各种数据透视分析的视角。

总结： 

数据分析就是在拨弄各种数据立方体，你可以切片、切块、钻取、汇总，你所玩的魔方每一块，就是一个具体的度量值，是什么数字，则是多种维度交叉后的结果。

工作实践中，数据产品经理会考虑做出更加方便易用的“立方体玩法”以供普通用户使用：

如，在分析客户来电的自动语音导航服务中，我们就可以按不同的维度去对比看用户在导航菜单里按键量，下图所示是“按菜单对比”的界面，在“对比按”中可以进行切换其他对比视角。

至于左侧的两个筛选，也即指筛选数据集合（切片或切块了），比如限定某几个热线和菜单去看。

3. 一张图片

了解了维度、度量两个词，又有了立方体之概念，让我们再来看数据是怎么产生，怎么被放到用户界面上供查询使用的。  

• 巧妇难为无米之炊。数据不是凭空产生的，当需求方提出想要什么样的数据分析的时候，首先要检视的是，TA需求中涉及到的维度是否确定被采集到？度量的计算成本是否高？比如若一个需求想要分析不同买家分层的留存，买家分层是一个新维度，需求方是按骨灰级、高级、新手等对买家进行分层。且什么叫骨灰级？系统里并未对买家进行打标记，且不同类目的骨灰级算法还不一样，加上算法定义本身也在磨合。这种情况下，我们应该和需求方一起推动业务系统完成打标，而不是自己接下这个需求，在数据仓库ETL环节完成。

• 了解ETL：这个是做数据工作绕不开的术语，E(抽取、清洗)——T（转换）——L（装载），抽取是从各个业务系统中抽取所需的数据，然后完成语义层、逻辑层的转换，比如不同系统中记录销售渠道这个维度，有的叫做saleschannel,有的叫做channel,需要转化为同一个概念。装载，也可以理解成抽取、清洗、转换好了，装载到另外一个空间里，供多维查询服务应用调用。
  

 

当然，则个领域，水很深，我只能简单描述一下，再深的也担心大家晕菜了——毕竟本文是写给非数据人的。（其实作者本人也讲不粗来了……哈哈）

四. 应用

我说了，我无法教你具体复杂的数据分析案例。我希望能够借助本文和你分享下如何建立起比较专业的数据分析思路——数据产品经理本身也应该可以是优秀的数据分析师。

1. 三部曲——建立分析框架

• 建立分析框架：了解业务、以及业务想要什么（目标）。

• 提交数据需求:  根据你的访谈、梳理，得到业务流程、业务愿景以及目标，那么就可以和需求方共同确认“看什么”以及“怎么看”。好的数据产品经理或者数据分析师，永远不是坐等需求方提出他要看什么度量和维度，而是要引导对方看更合适的东西以回答他关于目标是否达成的问题。

• 进行数据分析：使用多种维度，进行总体的、细分的、多维的分析，当发现问题时，能够使用这些维度的组合帮助用户找到影响原因。
  

一切都基于你有多了解业务：

下图是几年前的老图了，左侧是业务流程图（业务流程图怎么画），右侧是概念中的数字体系示意（可视化是为了更好和需求方沟通）。

 

PPT里因为存在具体业务的案例，不便分享，到此为止吧。如果有时间的话，我还是会编脱离具体业务的案例的……这就是写博客的苦逼之处，工作中都是工作的案例，为了写篇博客，还得自己再编一套有板有眼的故事……

2. 三部曲——提交数据需求

 

 故意放了张你可能看不清楚的图（o(╯□╰)o），所以别问我要大图了，谢谢~

左侧就是度量分类和度量，从标注了颜色底色开始的就是维度了，标了颜色的也即此指标需要被计算到所需的维度，灰色的表示不需要，黄色和绿色（以及上面的数字1、2），表示优先级不同，黄色的当然是高优先级了。比如黄色上我写的数字应该是1,也即第一优先级。

实际上，依据不同的场景，当然可以有很多简化，比如无需标注优先级之类的。

此外，还需要单独提供维度和度量的详细口径定义说明表格，这时最好和分析师一起，详细进行确认。

3. 三部曲——进行数据分析

 你提的需求不管是做成报表、还是做成具体可视化的界面，总之如果已经开发出来了，就来玩魔方吧。只是报表有可能你得导出来在EXCEL里玩魔方。（即使是可视化的界面，也依赖于对方设计得是否易用）

最简单的分析是逐级钻取，如：，

复杂的则需要多维交叉：

比如，当分析某个APP的Active users, 当我已经锁定某个省份有问题的时候，我们既可以继续钻取到城市去明晓细节，又可以交叉到品牌，看不同省份间品牌偏好的问题。比如是否小城市中安卓品牌的人更加活跃。

五. 留点作业：要记得思考哦

1. Detail页面的设计师被追责，怎么应对？

某日，负责搜索结果页（LIST）的设计师来找商品详情页（Detail），他好容易做了LIST页面的改版，而且结果也确实喜人，从List页面到Detailye页面的转化率确实提升了（比如原来100万的人来到List页面，只有40万继续点击到Detail,改版后，变成了50万）。但是不幸的是，总体从L到订单的转化率却没有提升，反而下降了。

 
请问，如果你是Detail的分析师，如何和List的分析师一起想办法分析什么原因？

2. 挂羊头卖狗肉的Banner，怎么用数据证明其反而有害无益？

有时为了爆眼球效应，你的老板会要求你做个华而不实的banner,比如明明活动页（Landing Page）里都是一些屌丝产品，却偏偏在banner上用屌丝的价格放一些高大上的产品图片。想要吸引人点击进去。而确实点击效果很好！过去放凤姐一晚，100个人里只有5个人点，现在放了林志玲一晚，100个人居然有99个人点击。老板很高兴，而且确实成交额似乎是比过去略微高那么一点点了。现在，除了用道德说辞说服老板不要这么做，还有别的方式吗？

六. 最后，唠叨几句

最后，分享给各位的心得是：

• 你现在也知道，数据本身需要经过分析师的定义、数据源系统的采集、数据开发的开发以及展现设计，任何一个环节，可能会产出错误的数据，所以数据本身未必100%靠谱。

• 此外，数据的解读，需要保持谨慎批判之心。比如同样是小明语文得了59分，如果你不了解上下文以及历史趋势的话，会认为小明没考好，有的人甚至会得出小明语文不好的结论。而要是了解他上个季度每次语文考试都只有30多分，又会得出小明虽然语文不好但是明显进步了。而要是了解到这个班级平均分数只有49分，你又会觉得小明简直太赞了！所以，单纯的一个数字本身没有任何意义，要窥一斑，更要知全貌。

• 此外，数据会被有心计的故意利用，而向你呈现部分事实（他不是在弯曲事实，而是只呈现对他有利的一面），数据本身有那么多维度以及层次，导致解读的方式完全可以被利用。

所以，要记得我本文的最后提点：

对于产品经理和分析师来讲，最针对的是我们基于对于业务的深入理解而产生的直觉。不要盲目被数据拉着走。只有有较好的直觉，我们才能有更合理的假设，有了这个合理的假设，才能够更好解读数据以及提数据的需求。而不是在各种数据的海洋里玩数据的游戏而浪费时间。