用这个方法，就能做好面向老板的数据分析

数据分析的痛点

越来越多的产品决策依据数据分析的结果，而数据分析的效率却真真是各个团队的痛。

一起来聊聊数据分析的一些想法。

不知道大家经历过这样的事情没有：老板或者运营部门突然要看看某个数据，可能是一个频率，也可以是一个转化率。但因为之前没有这个需求，现在看不了。然后紧急开发，一周以后才能够看到。可是，这时候老板是否还需要这个数据，已经不确定了。

01BI工具之痒

这个小的案例，其实就是一个数据分析的案例。数据分析，或者叫做BI，是一个很宽泛的概念。这个问题在实际过程中比较难以解决，例如，有的表格需要做成固定的，需要定期的查看，所有就有了报表系统；有的分析就是一次性的，得到结论之后就不再使用了，所以这里需要一个强大的BI工具。这个BI的工具的主要任务是尽可能方便将统计的需求转变为报表。

这个BI工具我们在之前的文章里，有过探讨《如何做好面向老板的数据分析》不过因为种种原因，目前这套工具还没有开源，给自己挖了一个大坑，这个工具大家可以先用metastore之类的工具代替一下。这篇文章想说说数据分析的另一个重要的点：数据。我开篇提到的小例子，其本质是没有数据造成的——巧妇难为无米之炊。数据这块相比较BI工具这块，更有挑战：

数据的准备往往是滞后的

业务数据库表结构的设计，往往很难支持统计的分析

下面详细说说这两个难点怎么解决，说说我们在实践中采取的方案。

02 一个方案，要解决一大类问题

数据准备的滞后性一直存在，尤其是业务数据中没有，需要网站上埋点的数据。这种滞后性，一定程度是产品迭代，公司发展的敌人。这个问题，更重要的是埋点数据的解决，我们解决埋点数据的方法也经历了几波的迭代，从开始的逐个埋点写代码，准确性可以保证，但基本没有通用性。所有的需求，都要特定的埋点。随着需求的增多，我们渐渐抽象出来一套模式，这套模式是基于需求层面的抽象。如下：

曝光 --> 点击 --> 业务动作1 --> 业务动作2

这个抽象非常的有用，基本上我们要看的就是如下的需求：

曝光的数量

点击的数量

业务动作1的数量

业务动作2的数量

点击率

点击到业务动作1的转化率

...

所以，我们有了一个方法，来解决这大类的分析需求。方案如下：

将页面划分为不同的功能模块，这个划分不要在前端做hard code，更好的做法是在Gateway层（我我们假设大家都采用了微服务的架构，其他的业务架构类似，只是叫法不同），通过接口划分。例如前端要展示商品（我们假设是电商的网站）的详情，或者列表。无论在哪个子页面，在Gateway层，都是不同的接口。在详情、或者列表返回的时候，都额外添加字段：module。不同的module可以根据不同的功能赋予可读的名字。为了方便作分析，我们要区分每一次请求展示（在用户层面，实际是用户行为的一次会话），我们又新增字段：groupUuid，用来标识后续的一些行为，实在这一次详情、或者列表展示的基础上完成的。

基于上面的设计，前端的工作就可以通用化。例如我们使用Vue作为前端的框架，在进行前端渲染的时候，我们直接将module、groupUuid渲染到dom元素，同时将商品dataId也渲染到dom元素，这个dataId和groupUuid在整个分析pipeline中起到了链接枢纽的作用。

用户在浏览页面的时候，前端统一监控，只要出现在可见区域的商品，则发送埋点事件，参数为前面dom元素已经渲染过的参数。

点击事件（这个时间要单独写）也要带上dom上渲染的参数：groupUuid，module和dataId。

点击之后，展开详情页或者预览也，都属于详情页。这时候需要将groupUuid，module和dataId三个参数作为URL参数带到详情的页面，此时，在这页面做的任何业务动作，都把groupUuid，module和dataId作为上下文传入到业务后台，这就保证了业务后台和数据埋点的统一关联。

基本上，在这个详情页做一些跳出的操作。都认为会话结束。

看起来也不简单，也没有解决全部的问题。但这个可以解决我们上面抽象出来的模式的问题。这里有一个经验，埋点方案，不要希望某一个方案能解决一切的问题，而是某一个方法，解决某个大类的问题，然后再来一个方法。

上面是常见的一类需求，还有一类是页面上各个控件的点击的频率以及对比，这个设计师们比较需要，用来改进产品的交互体验。这里也有一个和上面类似的思路，把每个控件进行编号（编号由设计师输出），然后前端统一处理。

03 分离统计表和业务表

这个问题我想大家都是认同的，但问题在于，分离的时机是什么？项目伊始就是做么？不然。因为这个时候统计的需求是频繁变化的、模式上是不稳定的。基本上这个阶段，分析仍旧是基于业务数据库的。接下来，业务逐渐画圆，最小闭环逐渐运行稳健。此时，另外一个特征是统计表的结构已经逐渐清晰。就可以开始着手ETL的开发。

以上提到的工具，纯开源的还没有遇到特别好的。基本都要根据自己团队的需求，定制开发。

04 彻底解决数据分析问题的方法

数据分析不是天马行空的想象，是基于对业务的深入了解。首先，明确我们要解决什么问题是最重要的，其次，这个问题该如何验证，怎么保证我们的方法就是可以得到结论，并且作为决策依据的。这一切，我觉得都是建立在对业务全局、系统、有序的理解上。之前有一篇文章做了讨论《做一个懂业务的产品和技术》。

业务应用架构比较繁琐，但也不乏有趣值得深入的点。欢迎大家一起讨论。

作者：张成

来源：待字闺中