在接手一款内部数据产品以后，由于业务拓展的原因，开始了一般统计型产品向BI产品转型的过程。在近1.5年的产品单款产品设计中，我一直在思考『如何能让用户有效的触达数据』。这篇文章是我对这个问题的浅层思考。

文章涉及三个问题：

• 数据触达的概念
• 常见的数据触达模式
• 我在探索的解决方案

数据触达的概念

在我看来，数据是一种特殊内容的体现，更多的是通过量化的形式体现用户对于实体/虚拟事物的感知；由于个体间的感知差异较大，所以产生了统计口径的概念，以对可感知差异进行统一的衡量，并且产生了对比的概念，以强化差异性的概念。举个例子：『对于客服服务水平的满意程度』一般来说会有1-5分的衡量标准，但4.5分和5分的满意度差异究竟在哪里，其实是一个很难说清楚的概念，为了在产品设计和运营的过程中出现类似的问题，我们可能会使用更加可量化的标准进行4.5和5分的评级标准确定（比如千单投诉率等）；

而数据触达所指的就是：

• 如何用可感知的数据表达方式去描述差异性
• 用户如何快速获取并高效解读该类差异；

问题一涉及的是评估标准的建设，暂时不在本文章中讨论，主要想对问题二做一下讨论：也就是在一个数据产品中，我们如何让用户快速获取并高效解读产品的变化。

常见的数据触达模式

在市面上的数据分析产品中，在数据触达模式上大致可以分为两类：（1）有限度的专题内分析 （2）通用的分析工具，对此分别做以下解读：

有限度的专题内分析

多体现于80%头部用户的通用统计型平台（如百度统计）和垂类型的统计平台（如主打转换率分析的Growing IO）；该类型的平台的特点是：会将数据按照特定的『专题』进行专题下的拆解，提供通用、有限度的数据呈现以及涨跌呈现，但是不对涨跌的原因进行分析及收益分析，用户只能通过有限的几个角度进行泛数据分析的查看，并得到相对表层的分析结果，再辅助A/B TEST等实验进行思想的认证。

通用的分析工具

更多的出现在To B领域，以BI工具为主要的代表作，强调的是基础层面的建设，即给出可能的分析包（例如对比、拆纬度、显著性分析等），列举出所有基础的分析模式，但不提供任何的分析组合；之所以在企业界用的比较广泛是因为企业界有非常明确的业务核心，需要相对灵活的场景去应对可能发生的商业变化，以多角度判断部门或决策者对于决策的正确程度。

以上的情况，不针对决策，更多的还是利用『搜索』导向思维所做的产品，即对于有明确描述的分析问题进行分析，那么问题来了，对于探索期的业务和现在更多的分析场景，出现了两种非常常见的分析情景：

1. 只能对于问题本事的现象进行描述，而并不确定问题的核心是什么，也就是说可能连『正确』的问题都问不出来 ；
2. 可能连问题表象本身都不能很好的描述，只有最终的目标，没有路径；

问题二涉及到复杂的分析决策过程，暂时不做讨论，重点说明问题一。 那么问题一是一类什么样子的问题？ 我理解更多的会出现在『产品或业务提升』或者『产品或问题收益分析上』，也就是为什么有问题？为什么能成功？ 不怀疑的是市面上确实有非常多的分析框架出现，但针对相对抽象的问题来说还是很难有一套比较完整的分析体系，通过产品的形式落地。

举个稍微通俗一点的例子：为什么XX产品的DAU会在1月份有明显的降低？更进一步的问法是为什么XX产品的DAU会，在做过某一次线上运营活动以后，反而降低的更快？ 以上的问题解释，更多的是大家讨论的『数据分析框架』的建立过程，但这个过程我们有没有可能通过产品的方式，配合已有的数据触达类产品进行落地？而不是仅仅停留在只给分析基础，自由组合分析方法的模式上？我的答案是，可行，但有非常严苛的前提条件。

我在探索的解决方案

以上需求的出现，更多的像『知识引擎』的一种变体，即用户只知道表象，而我们呈现的是逻辑上最可能出现的关联原因和可能有的后续结果。在分析框架建立的前提，它的产品落地方案只合适在内部决策时，在相对成熟的业务，应用在相对成熟的问题下，比如『为什么销售额会降低？』『为什么DAU会下降？』而处理的方式是，将所有的决策路径进行『穷举』，给出最可能的问题原因，再由人工做最后的判断；从产品的角度来说，我可以理解为是对分析方法的打包，以适用于某一类分析专题，并在数据产品端提供分析决策的专题。那么做到这一点需要产品同学提供什么？我认为是如下几点：

• 基于对业务的理解，对业务问题进行外部原因和内部原因的拆解和列举
• 搭建每个原因树下正常或异常的判定标准（比如我们团队曾经做过，用梯度回归模型做预警）
• 根据业务本身的权重，对相关的原因进行权重赋予（比如知道某个渠道的占比就是很低，那这个渠道就算有业绩上绝对值的大幅提升，如果占比还是不怎么变化，其实对整体问题或收益的贡献值自然不会太大）
• 对以上结点，根据异常和权重进行问题原因可能性的判断
• 列举出最可能的影响因素
• 人工最终判断最终的结论
• 产品的设计和落地

需要注意的是以上内部原因和外部原因，产品中能稳定设定的因子，只占到80%，剩下的20%突发性原因需要进行人工的调权或者特定模式的设定（比如节假日、比如运营活动、比如突发性事件），以上模式下分析方法的设定，需要叠加消息衰减模型和相关系数，以做分析专题准召的调整。

小结

数据触达的形式已经随着业务复杂性的增加，变得相对艰难，更多的分析人员和决策者面临只知道业务表象，很难完全判断出表象原因的情况；特别是对于初级业务人员和运营者来说，对于没有完整分析框架的时候，甚至连原因都很难获取。

传统的数据触达模式是：给予通用的分析工具，进行自由的组合和可能原因的人工判断；或者根据有限的专题，进行原因的筛选，并不是一个直接触达数据的模式，需要进行较多的分析框架和决策树的搭建。而未来，我认为数据产品的同学需要真正去关注真正的影响因素，并在大数据的背景下，尽可能的穷举所有影响该业务的因素，并根据模型的搭建和准召的不断调整，给出较为可能的影响因子排序，以协助用户对于分析框架的建立和最终原因的判断。

在这里想特别说明的是，数据触达的优化并不能真正代替真正的分析人员最终的判断和决策，它更多的只是弥补初级业务人员对分析框架建立上的障碍，和高级人员在人工归因时的思维漏洞。由于创建成本比较高，它一定是基于业务团队所需，高效解决高净值问题时才会出现，而并非是一个可以完全对80%头部用户开放的事情，这可能是和很多做外部产品并因此获得商业变现不太一致情况，需要特别加以区分。

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