本文作者结合数据分析产品从可视化升级到智能化的一个实践案例，对“今天订单量为什么下降了”这一问题展开了分析探究，并对过程中存在的问题和解决方法进行了总结，与大家分享。

提到数据产品，大家经常会想到的可能是tableau、growing io、神策数据、诸葛IO等商业化数据产品，也可能是企业内部的报表工具、提取工具等数据平台产品，或者是A/B-test、用户画像、埋点系统等数据应用产品，以及面向业务的各类数据可视化、Dashboard等数据分析产品。

今天我为大家分享下数据分析产品从可视化升级到智能化的一个实践案例。

在企业发展初期，最需要的其实是报表工具和提取工具等平台型数据产品，面向分析师和开发团队，实现数据的提取和加工过程，业务侧也基本上只看几个核心指标。发展到一定阶段，才会有数据可视化分析产品的需求，或采购tableau、BDP、网易有数等商业化产品，或自研分业务主题的Dashboard数据产品。

从基础的报表工具进化到数据可视化产品后，在用户体验上有了极大地提升，数据统一、及时性也可以通过数据产品的反推方式，逐步得到保证。但如何更好地提升业务团队的数据分析水平，还是会存在一些问题和提升空间。举例来讲：

• 问题一：方法论不统一和水平参差不齐。有了各类Dashboard，但还是无法保证每个业务同学都能按照预想的思路去使用数据产品，也无法确保业务同学能够自我探索新的分析思路，以及每位同学分析水平的高低。
• 问题二：分析过程仍旧很繁琐耗时。各类Dashboard虽然以自动化的形式提供了数据，并且不需要再进行数据处理，有一定的可视化分析能力，但遇到问题后的分析过程并不能减少，还是需要进行大量的多维度多角度下钻分析，时间效率上还有待提升。

那如何来解决这个问题呢？答案是数据分析产品的分析智能化。我以各大企业业务团队和分析师团队经常会遇到的问题「今天订单量为什么下降了」，来分享下数据产品应该如何快速、高效、直接地回答业绩波动的问题，并且以产品的方式统一方法论、拉齐分析水平。

分析智能化的两大核心：分析方法抽象化+产品自动化

1. 分析方法抽象化

「今天订单量为什么下降了」，是高频出现在每天早上与老板的对话里。一般情况下，都会由数据分析师进行跑SQL、整理数据、进行问题拆解分析，最后给老板一个回复。效率高的情况下，大概需要花1个小时的时间，效率低、或者赶上数仓计算排队压力时，可能要花费半天甚至一天的时间，来回答这个问题。

对于这个问题，分析方法一般都会有相对固定的思路和过程，在此举一个例子作为参考，分析方法可抽象为三个部分：

1. 波动情况如何？是否属于正常波动？
2. 影响范围的细分，哪些城市、哪些时段、哪些类型的业务波动影响最大？
3. 是什么原因引起的？应该如何解决？

（1）波动的情况和异常判断

一般情况下，波动的情况可以用环同比的数值和比例进行衡量，比如昨天的订单量周同比下降了7.36%。日环比下降了2.48%。异常判断是一个更难的问题，可以借鉴三个方法：

a. 阈值法：根据业务经验设定阈值，比如波动范围[-1%, 1%]属于平稳，在[-3%, -1%)和(-1%, -3%]属于略微波动，超过±3%的波动属于大幅波动，并判定为业务异常；

b. 回归预测：根据时序进行订单量的回归预测，通过对历史数据的拟合，预测出昨天数据的数值范围，比如在置信度95%时的置信区间，如果超出置信区间，则认为是异常波动；

c. 同级城市排序或相似城市对比法：对于业务的局部单元，比如全国开展的业务，判断成都市业务的波动是否异常，可以通过找到与成都市相似的对标城市或者同级城市，判断相似或同级城市订单量的波动差异，如果大家都普遍下降，则认为城市角度的业务单元未发生异常。

波动的异常分析，在数学和统计学中还有非常多的方法可以使用，大家可自行检索，在此不做赘述。

（2）影响范围的细分

有了波动情况的判断，就需要进一步下钻分析波动影响的范围，根据业务场景的不同，会有不同的下钻方式。比如常见的时空角度，分析哪些城市的业务波动对全国影响最大，哪些时段的业务波动对全天影响最大，哪些下钻维度的波动最全局影响最大。这里会涉及一个「影响最大」的量化逻辑，方法有很多，以城市维度下钻举例，这里列举2个简单规则：

a.绝对值影响度：将各城市订单量波动值的绝对值进行降序排列，取TOP5或TOP10进行展示，并辅助以各城市的波动比例；

b.降序累计波动幅度：将各城市的订单量进行降序排列，用帕累托图法分析出拐点阈值，求出累计占比前80%或前90%（阈值）的城市，然后对这些城市的波动幅度进行排序，排序规则与全局波动保持同向，即全国如果同比下降，则波动幅度升序排列，下降最多的城市排在前面，反之把上涨最多的城市排在前面。

影响范围的下钻分析，核心点是「下钻维度」和「影响最大的量化逻辑」，在此基础上「下钻维度」还可以叠加，进行多层下钻，「影响最大的量化逻辑」还可以增加更为复杂的加权计算等规则，甚至是算法规则。

（3）原因定位和解决方案

归因分析方法和逻辑有很多成熟的经验，但仍然是一个很难的数学和业务问题，大多都只能提供信息参考，后面会专门写一篇归因分析的文章进行介绍，这里给大家列举一种简单易懂的业务拆解逻辑，不能算归因模型，但足够实用，适合业务落地。

基于业务场景的指标拆解

以携程酒店业务为例，核心目标和指标是「消费间夜数」，从「消费间夜数」出发，从相加或相乘的两个思路进行相关指标的拆解，如下图：

假设酒店的消费间夜数突然上涨13%，属于异常上涨，其中北京市的上涨影响度最大，时段上没有明显的波动。那北京市的消费间夜数上涨，又是什么影响的呢？

可以从图中的指标拆解脑图来分析，先看 消费间夜数 = 当天（购买）消费间夜数 + 预约消费间夜数，可以发现是当天购买影响的，还是预约消费影响的，如七夕、情人节等酒店本地消费爆满的场景，或者旅游季异地人群预约消费爆满的场景。

进一步可以观察销售间夜数和履约率，是否出现大幅波动，再进一步还可以分析购买用户数和人均购买间夜数的波动，观察是否出现旅游季的旅游团大单情况。

这就是基于业务场景的指标拆解思路，例子不一定严谨和准确，大家可以根据自己公司的业务场景进行更实用、严谨的拆解，而拆解的目标一定不只是看看而已，最终还是要落到抓手上，如何去解决问题，从哪些方面去解决问题。

2. 产品自动化

有了抽象化的分析方法后，就需要用自动化的产品来承载，将数据分析进行产品化之后，才能用产品中内含的分析方法实现统一方法论、拉齐分析水平的目标。

那应该如何来设计自动进行数据分析的产品呢？整体分三步：首先是针对数据分析内容和信息的可视化展现，其次产品整体交互流程需要遵循数据分析的过程和逻辑，最后还需要考虑两个原则：

1）便于迭代，实现结构化和可扩展；

2）易于理解，符合人的认知习惯。

今天着重为大家分享要考虑的两个原则。

原则一：便于迭代，实现结构化和可扩展

业务时刻在变，分析方法也需要紧跟业务去迭代，但产品开发的成本又很高，所以能否实现结构化的产品设计，支持分析方法论的快速迭代和扩展，是产品设计需要考虑的第一因素。

这里列举一个简单的产品框架：

产品框架与抽象化的分析方法紧密映射，由「波动和异常判断结论区」+「多维下钻分析区」+「归因分析区」三部分组成。前两部分的问题结合紧密，建议放到一个页面中进行布局，让用户可以快速get到「我的业绩怎么样」「波动如何」「是否是正常波动」「哪些城市、哪些类型的波动和影响最大」。

归因分析的部分单独一个页面布局，因为归因分析的逻辑一般比较复杂，可视化展现的形式也很多样，所以要有足够大的空间进行产品设计，与用户进行交互。

原则二：易于理解，符合人的认知习惯

这一点有两个方面：

一是要结论先行，进行结构化表达，这一点在上面结构化设计中也有体现，即先让用户看到整体结论，再看到细分影响，最后看原因和解决方案切入点；

二是措辞上要把数据化的描述变成业务逻辑的描述，比如用置信区间来判定波动是否异常，不能写「昨天的数值落在置信区间外，属于异常数值」，而要直接写「昨天的订单量周同比 +7.62%，属于异常上涨，请关注」，这一点在指数化等复杂判断方法中需要尤为注意。

结语

数据分析产品从数据可视化到分析智能化，对于回答「订单量为什么下降了」这类问题，其核心是分析方法的抽象化，对于数据产品经理而言，不一定要完全自研方法论+产品设计，更好的选择是跟资深业务同学、数据分析师、算法工程师一起合作，产品经理更多地负责定义用户问题、定义产品目标和思路，以及提出产品结构化要求等。

作者：Probes，微信公众号：Data To Value，致力于数据产品领域的分享和交流，用数据创造价值。

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

题图来自Unsplash，基于CC0协议