2017年2月22日云栖TechDay29期，阿里云交互设计师、用户体验研究专员行休/雩烜和大家一起谈谈设计师如何玩数据。本文主要从为什么要做MERIDIAN开始讲起，接下来分析了面对云产品售卖过程中设计师的复杂思考，包括核心算法的改变等，接着还介绍了微观力量，并解释了 Markov Chain Model，最后畅想了售卖线的诗和远方。
以下是精彩内容整理：
当面对一个复杂系统的设计挑战时，设计师除了利用自己的理性逻辑和感性同理来抽丝剥茧，还能如何利用千千万万用户的真实数据来辅助自己的决策？我们将分享自己在设计数据产品化上的思考和探索。
当我们碰到一些特定的业务场景以及一些问题以后，为了想办法解决问题，最后想尽办法做了阿拉丁产品，如果大家跟我们一样专注做网站设计的话，可以看到在网站设计的时候，一般都会导入一些分析工具，我们在团队内部使用的产品叫阿拉丁，可以分析一些运营上、业务上的用户链路。可以看到，如果我们今天有整个业务指标，就可以分析一日时间的波动，如果想看一下用户从哪里到哪里，进来的人走到哪一步，分别产生什么样的行为，大部分整个分析如上图所示。
为什么今天要做MERIDIAN呢？
做这个产品主要的原因在于现有的分析工具，像GA工具基本上没有办法解决我们的问题。我们是着重于网站的设计，让用户体验可以变的更好。既然要做这件事情，势必要了解用户在网站里面的行为，而原本我们用的工具在做用户行为，包括每一个用户走进来这个链路之间其实是没有办法做到更清晰的分析，所以我们把自己产品的定位，跟阿拉丁的定位做了一点区隔，我们做的东西叫做自动化全链路分析，对比平常常用的分析工具自定义链路监控有什么差别呢？
阿拉丁是手动设置漏斗，一般市面上做的一些分析是，我的用户来到A站，又到了B页面，B页面到了C页面，它是要手动设置的，设置好以后它会自己搜集数据，那我们想要做到不要手动去设置，我们可不可以通过一些算法方式去归纳用户最常走的这条路，最常走的地方就是我们优化的重点。如果我今天是手动设置，那就是按照我心中所想的去设置，而不是去按整个网站里面真正用户行为去设置的，在这部分我们针对链路部分想要做的是全网上的路径，它可以做无限多的展开。那能不能做到多一点点分析呢？我们去看单一的用户在里面真正做了什么事情，最后可不可以看他的访问，或者没有访问的这些人去了哪里，透过这种方式去看能不能分析真正用户行为。现在整个产品进展阶段是拿了我们的售卖线，因为我们在阿里云是卖云服务器，拿售卖线作为我们整个试点，为什么拿售卖线作为分析用户路径的试点呢？
为什么做MERIDIAN?
设计师玩数据是现在比较大的趋势，我们在做一个B类复杂的售卖产品的时候，是怎么样产生一个想法，又是怎样去推动实施呢？那么缘起，开始我们为什么要做这个系统呢？
如何去买一台ECS如图，大家可以看到去我们首页以后，来到我们的售卖页，去做一个选配，一个非常熟练的用户做这些操作，在这漫长的快1分钟里面，用户只是在做一件事情，就是选择一个符合他要求配置的服务器，其中会有很复杂的一些操作选配项。
守恒的复杂
当我一开始去接受做售卖线的时候，作为一个新的设计师，我是不太清楚怎么去卖一台云服务器的，但是我知道它是一个非常复杂的东西，跟普通卖一件衣服不一样。卖一件衣服的时候，可能要考虑颜色、尺寸，但是要卖一台云服务器的时候，要考虑的东西很多，比如为什么要选那个镜像，根据业务的实际场景，根据需求去定义一个适合你的清单，再根据清单去上面选配。
它其实是有一个非常严密的约束逻辑，比如选择它的机会方式会影响到可以选择地域等。具体有多复杂呢？我们整个页面行动点的数量有200多个。上图用D3的可同化引擎，把所有连夜上下布的关系点出来以后，绘制这样一个图。数据可视化以后，其实并没有任何用途，唯一用处就是可以看出我们的点击链路之间是非常复杂，是互相依赖的一个关系。
操作步数中位值就是一个用户来到我的售卖页去进行买一个东西选配的时候，会有多少步，这里可能几十步吧，也就是说我要点几十次才能完成一个选配。面对这样一个页面的时候，设计师角色就很奇怪了。
是老师也是学生
首先我们是一个老师，为什么是老师？当我去做新版售卖页改版的时候，PD给我一个3600字的文档，告诉我在售卖页上需要提示用户的东西，要把一个小论文放在页面里面让用户去读，一个小白用户可能要读这么多字才清楚究竟怎么去选这个东西，这些提示文案被分散在40多个问号或者TIPS或者说明里面去触发给用户；我们也是一个学生，面对这样一个产品，我做不到比用户更加了解这个产品，因为我们的用户是很多种多样的，他可能是一个工程师，可能是一个运维，可能是一个站长，他只是需要一个小服务器把一些数据存储一下，他们的需求是完全不一样的，我无法同时去洞察他们的需求，同时，我们的产品功能也是极其复杂的，我去买这个产品的时候不是因为它的用户体验有多么好，而是它是刚需，它的产品形态严格依赖于它的产品业务逻辑，因为我们后台逻辑的配置，你无法做摄取的判定。所以作为设计师无法完全从用户的层面上去简化一个产品，因为它的复杂性是天生在那里的，复杂性一旦减掉，可能带来对用户本身的伤害。
从同理，到出离
面对这样一个产品，设计师本来不太好去做一些常规C类产品改动的时候，也就是说当同理心缺席，我们如何理解用户？同时作为一个设计师，很难去做大范围改动的时候，我们还能干什么呢。
这时候我就换了一个思路，一开始接受售卖线以后做的第一件事情就是要建立一个以前没有的东西，就是泛ECS售卖监测链路的建立。我们售卖不是只有一个页面，它有很多途径，以前只是很简单监控一下下单比例是多少，但没有一个复杂的链路转化，把这个问题细分出来以后大概画了上图，这是我们售卖相关最主要的几条链路，黄线部分是简单配置或者推荐配置售卖，红线是我们主要售卖线路还有一些后台售卖线路。
转化陷阱
知其然不知其所以然
当转化率在⼀定范畴内正常波动时，并没有多少有效信息。
画出图以后发现链路太多了，而这个链路如果人工手动去维护的成本非常大，因为我们基于的是买点，买点一变掉，所有的数据都废掉。我也陷入过转化陷井，我现在知道每一条链路的转化率，但好像什么事情都做不了。如图是我们售卖线可能转化率的一个波动图，其实很简单，双十一阿里云做了大促，所以当天的转化率会有一个非常高的峰值，这个图告诉我们，前面数据是平缓，后面数据也是平缓的，双十一有了一个峰值。当我们发现这种数据建立出来以后，得到了异常数据结果都是显而易见，当你不需要这个数据报告别人也知道的时候，这个数据转化链路建立起来又有什么用呢？
没⼈买云服务器是为了装点衣橱
当设计对转化率影响权重较小时，关注转化率的意义在哪？
买云服务器是刚需，刚需就意味着，老板让你买你就得买，公司要用就得用，没有人买云服务器是因为云服务器漂亮。我们的设计如果不触及到根本用户体验的改变，设计层面改变很难影响它的转化率。所以当设计对它的转化率影响权重比较小的时候，关注转化率的意义又在什么地方，这是当时最困扰的问题。
针对以上两个问题，我们提出保安猜想。既然想要分析我们的转化率目标，就要把所有的相关因素都抽象出来，抽象出来就是一个保安常问的几个问题，你是谁、从哪儿来、到哪儿去和做什么。而我们以前只知道它做了多少、多少人做了，但不知道这些细节，那我肯定要找到原数据，去把这些东西抽象出来，这也是为什么有了阿拉丁以外还需要MERIDIAN。总结起来四句话：
- 为了看到不同用户在不同渠道的转化差异
- 为了洞察复杂页面的庞杂用户行为
- 为了将问题从问题路径中剥离
- 为了全链路分析的自动化
核心算法的改变
核心算法的改变其实就是做用户的分层和来源热点，包括把200步的用户路径铺出来。我们可以按照用户的筛选把每个用户的点击路径排列出来，每一条横线就是用户来到我们网站里面的每一步法的路径。而传统的转化漏斗，比如说阿拉丁，他去计算转化路径的时候，只关注你的起点、中间点和最终的结果，然后把这些东西统计出来变成转化率，中间的东西其实是丢掉了，来源和去向可能都丢掉了。基于这个思路，我觉得每个用户都很重要，想象每个用户都是头发丝，我们叫做扎辫子模型，并不是说掐头去尾，把转化率分析出来就好了，而是把每一个节点像扎辫子一样扎出来，就知道我的来源是哪个地方，有多少用户都在干嘛，它最终流失的去向。
微观的力量
算法搭出来以后跑了几遍数据会发现额外的收获，叫做微观的力量。我发现突然具有一个能力，能够看到每一个用户的点击。如图，第一位用户来到页面以后，先选择了实例，然后在镜像市场之间选了一个镜像，又添了一个数据盘，又选了一下镜像；第二位用户在购买的地方，本来是选了一堆东西，选择了一个镜像，然后点了立即购买，由于镜像策略原因，能够让他必须在登录前就可以看到购买页，立即购买然后自动跳到了登录页，登录后回到了售卖页，这时候他本来填的一些密码因为没有时间开发，所有输入状态都丢掉了，所以他不得不重新输入密码，重新选择镜像然后再点立即购买。
所谓微观力量就是，我坐在办公室点几下鼠标，再做几下筛选，就可以精确把用户某一个类型，来源于某一个渠道，可能是某一个来源的某一个城市用MAC的用户都拉出来，然后再加几个维度，去看他的每一步真实的点击是怎么样的。设计师就可以在不打扰用户的情况下，在完全真实用户环境下去筛选任何维度用户，看他真实点击行为，这就是一个上帝的视角。我们目前在开发当中，在数据层面上已经跑通了，但是每次都要手动跑一下，所以现在目的是把它工具化。
路径间的幽灵
最后一个问题，我们现在到极宏观，已经能够设任何链路去看它大体的转化率，我们也能够看极微观，我们可以设几个具体条件把所有用户筛选出来，看每一步具体转化。如图，下面蓝色就是售卖页，我把每一个按钮上面点击做了一个统计，然后把它串联起来，做了一个转化路径图，这就变成复杂页面热点图。我们发现点击最高的按钮，不是立即购买，也不是切换，而是我们之前用来做实例切换的弹框确定按钮，这个确定按钮只有一个功能，就是把弹框关掉做确定，但是它被点击最多。而用户又有频繁在实例里面做切换做比较这样一个需求。老版页面设计上，因为页面太过于复杂，所以交互出了一个方案在弹框里面去做实例的选择，但是把这个数据拉出来发现，这一步操作完全是重复的，而且会阻碍用户对比价这样一个需求切换，所以把这个数据拉上去以后就可以劝说他们，在改版的时候把实例拉出来，最后数据也很理想，我们整个用户在操作大页面的时候，点击的次数是明显下降了，虽然转化率还是没有上升。
所以我们想了未来想要做的东西，我们叫路径幽灵。我们现在知道最极宏观的东西转化比例，也知道了极微观的东西一个用户的路径，但是这些路径和路径之间有什么东西呢？又变成了典型用户的典型路径。因为我们用户很多，一个页面可能一天就有几千个UV过来看，几千个用户过来买，不可能每天坐在一个地方看这个用户在干嘛，一定要有一个东西能够把它抽象总结出来一个范式，而这个范式就是典型用户，也就是设计师手工去做的东西。
Markov Chain Model
我们可以看到整个全站链路究竟怎么走的，也可以从中抽取一条去看那个用户操作行为，发现他在整个网站以及在体验上面有什么样的问题。这当中缺少的是用户路径的归纳。今天有1千个用户就会有1千种点击行为，这些点击行为能不能做出一些归纳呢？
我们现在尝试的是Markov Chain Model，它有一个好处，在整个点击行为里面我们常常会碰到这样的问题，一般来说我们看数据表一条一条横横竖竖画的很好，每个数据都塞在里面，如果这是一个访问，访问里面每一格把数据塞好，一个访问把数据塞好，我们就碰到一个问题，有些人来这个网页点一次就跳了，他根本不想来，有些人点了好几次一直频繁看，看了很多很多页面，所以他的数据变的很长。我们在这个当中会遇到一些问题，没有办法长成一个方的表格，这就要通过Markov Chain Model的算法基本上可以把这个问题解决掉。
再者，一个用户买和不买，页面之间是有一些联动关系的，可能最后购买的按钮之后透够这个页面，假设有13个页面，最后可以做到购买行为可能是3，4，7，11，这4个页面才有办法去购买，其他页面都是说明，是不一样的功能。所以页面之间会有一些顺序性，我们透过中间很多层次，可以透过Markov Chain Model模型去解决。
它把用户做了归纳，这里面放了几千条数据进去。我们当时在上新版售卖线的时候，同时又稍微做分流，所以有一部分会在新版，有一部分在旧版，你可以看到这中间用户的操作行为是有链路回圈。这表示，这个页面上在某一些点击按钮中用户会一直绕圈，他会有一些操作上面的困扰或者有一些东西必须要去参考，所以他会一直在这个地方绕。通过链路回圈，我们就可以发现用户真正在操作上面是不是碰到了一些问题，以便我们去缩小范围解决问题。
诗和远方
一开始在做售卖线就是卖云服务器，显然买之前都要看小论文，小论文以外可能还要看很多乱七八糟的东西，所以我们打算把整个售卖体系都拿进来做。我们希望慢慢扩展到全站，我能不能透过一些数据去做预测，例如经过了某一站点的用户，他接下来就会买什么样的产品。数据量太大时就要套一点机器学习的算法，中间我们还会尝试一些其他的方式，把一些数据里面的讯息做一个简化或者做一些归类，尝试一些机器学习其他算法，看哪个用起来比较好用。然后在可视化的角度上，能不能透过D3或者是processing去把页面弄的好看、好用。
行休：毕业于湖南大学与米兰理工大学。现负责阿里云官网、售卖、设计创新等业务线体验设计。
马妤瑄：毕业于台湾政治大学。专注于数据及商业分析，拥有涵盖组织行为、战略营销等多领域分析经验。现负责阿里云用户研究相关的数据分析方法导入及研究。
