很多特别是创业公司产品都会遇到数据体系的问题，当然可以找第三方公司来解决，但数据安全又是个问题。如果全部本地化部署那费用也真的是不菲，所以自己干吧。那我们要如何快速搭建公司数据体系？

BOSS：对了，盒子，我这两天看你们电商的订单量好像有点波动呀。

盒子：emmm…老板您真委婉，最近订单量的确下降了很多。

盒子：我觉得有可能是我们最近新上的品太贵了，另外感觉现在这个UI还是没有能让人有购买的欲望。而且这里产品设计上有很大的问题，不过我这里已经做好了七夕大促活动方案。准备发他1000张优惠券，然后活动商品全场8折，在加上全量PUSH，您放心订单量不涨我现场表演吃翔。

BOSS：别别别，我还是很看好你的，加油。

小的时候家里经营了一家花店，每到情人节之际总能看到无数的男主花重金求购玫瑰，自然那一天玫瑰的价格，至少要比平常翻个5倍左右吧。所以在情人节前几日，总能见到我爸妈盘算着今年该采购多少玫瑰，才能既保证情人节当天的需求量，又能最大程度降低花枝损耗及库存风险，从而实现利益最大化。

当然，当时他们在决定具体采购数量凭借的更多还是过往的经验，所以大部分情况并没有实现利益最大化。我们知道影响一个指标可能有很多因素，比如说：周围花店的数量，周围人群客流量，人群对鲜花的喜好程度，以及是否有固定老客户等等。

那么我们姑且将这些因素都看成一个个变量X，将最终采购数看成变量Y。那实际采购数量Y就等于X1*k+X2*k+X3*k，即为一个多元线性方程。这样如果我们有足够的历史数据，利用最小二乘等方法就可以逐步优化得出K值。

这样我们就有可能得出了一个公式：

y=x1*0.23+x2*0.38+x3*0.53

那么利用这个公式我们将今年有关周边花店、客流量、偏好程度等数据代入，即可得出今年情人节到底应该采购多少朵玫瑰花。最后通过情人节当天男主们实际购买情况，来调整公式的参数直至最优。这样明年我想他们应该就不用在那么纠结到底该采购多少玫瑰了，可惜的是花店没有坚持到明年。

差点忘了文章的标题，但是我认为明确数据分析的目的和方法，要比拥有数据和工具更重要。

那么到底该如何搭建公司的数据体系？

我想是很多特别是创业公司产品都会遇到一个问题，当然可以找第三方公司来解决，但数据安全又是个问题。如果全部本地化部署那费用也真的是不菲，所以响应习大大号召撸起袖子自己干吧…

一、数据仓库

首先我知道你有很多数据，但总也得有个地儿放吧。不至于我每次要拉数据都跟挤牙膏似得，小心翼翼的在线上数据库上跑吧，查个订单数据怎么也要limit一下才敢点执行。所以如果业务系统很多并且数据量比较大，建议将数据先同步到HDFS中，然后在利用HIVE对数据进行分布式计算，这期间有可能还会涉及到一些ETL的工作。

另外既然数据有地儿放了，那么也不能乱放吧。之前也有看过关于数据仓库维度建模，但我觉得一般中小公司如果不是以大数据为主要业务的，只要能够把数据分门别类就可以了，有特殊需要做处理的在考虑跑个离线计算的任务。

不管怎么说，数据仓库是数据上层应用的基础，先把地基打好。

二、数据获取

那么有地儿放数据了，总要放点数据进来吧。

一般我们会将数据分为两种：一种是业务数据，另一种是行为数据。

业务数据数据源即为各个业务系统，每个业务系统产生的，如：交易数据、商品数据、用户数据等等，都会根据业务需求通过数据抽取工具全部同步到数据仓库中。

行为数据其实就是我们常说的用户行为数据，常用于分析用户在客户端的访问路径及行为。

行为数据一般有两种方式进行收集：

• 一种是通过用户访问的接口日志数据进行存储。但是这种方式的问题是，有可能存在客户端对接口数据进行缓存的情况。所以如果是这种情况，那么当用户访问该页面时客户端就不会在请求服务器接口，自然会造成一定的数据收集偏差。
• 另一种是通过对客户端进行埋点的方式，但是需要运营或产品同学预先定义埋点事件，并请开发同学进行手动埋点。这种方式可以有效减少数据丢失的情况，但仍有1～3%的几率丢失数据。并且很多时候由于版本发布比较紧急无资源给你埋点。

我们现在的做法是，在网上找了一个支持客户端全量数据收集的开源SDK，也就是常说的全埋点。只要将该SDK嵌入客户端并将上报数据的地址，改为我们的服务器地址，大多数情况就可以收集到用户的全部操作数据了。

除非有特殊数据需求，一般情况只要将客户端控件ID做好映射，就可以知道用户点击了哪些按钮或跳转到了哪些页面。

三、数据报表

在公司业务发展过程当中，无论是运营或产品多数情况都需要有数据的支撑，最常见的像GMV、订单量、用户数、支付数、支付金额等等。类似这些指标的集合即为业务的数据报表，一般通过浏览这些报表便，能够让我们快速了解当前业务的实际情况。

更有经验的数据分析者可以通过对数据的聚合、下钻等方式发现问题，找到原因，并输出分析结论从而指导业务决策。但往往这类报表需求多变，如果每次都让开发人员手动修改和导出数据，效率又会非常低。

这里推荐一款由Airbnb开源的BI工具——Superset，开源BI里面个人感觉算是比较强大了。

一般的报表需求通过几句简单的SQL及其自带丰富的图表，就都能够满足啦。如果报表的数据计算量过大，建议离线计算一层之后在用Superset查询。将Superset部到服务器上，并连到您的数仓，你会发现很多数据需求都不需要找开发了，解放了一大部分可视化前端的开发资源。

当然我也承认，毕竟开源的系统，所以BUG还是有的，不过整体来说还是利大于弊，是时候让你的SQL策马奔腾吧！

四、数据应用

除了数据报表，对于数据的应用还有很多种形式，比如：用户行为分析、用户画像、漏斗分析、个性化推荐等等。当然市场上有很多第三方的数据分析工具，免费的，如：友盟、TalkingDate等等。收费的有….怕有打广告的嫌疑这里就不枚举了。

但系统终究是人家的系统，一些个性化的需求恐怕不能满足变化莫测的业务需求，另外对于自己数据的沉淀也不方便。

我们现在的做法是简单的数据报表用Superset，复杂数据需求，比如：类似用户画像等等，产品及研发才会介入设计和开发。

在这也简单说几个我们自己做的一些数据应用：

1. 用户行为分析

利用桑吉图，在通过客户端事件埋点将用户的行为路径整体描绘出来。非常有助于了解用户的操作喜好，以及发现产品中存在的问题。

这里在开发过程中可能需要注意两点：

• 一是当客户端事件过多时桑吉图会变得非常混乱且难以浏览，因此在设计系统时应提供窗口式或分页式对数据进行浏览的功能。
• 二是我们的用户会有很多刷新的动作，所以行为数据中必然会存在从A到A的情况。

但是很多开源的桑吉图并不支持递归数据，所以我们将存在递归的数据进行重命名（如A1），这样桑吉图就画出来喽。当然如果要系统更强大，个人的脑洞是可以考虑针对某条路径进行向下钻取等等。

2. 转化漏斗分析

业务上最关注的恐怕就是每个节点的转化情况，因此如果能设计一套灵活的漏斗分析工具，对于业务分析及运营效率上的帮助都会非常大。

为了尽可能的让业务人员根据自己的需求，个性化的配置一组节点，并快速生成可视化的漏斗和报表，我们将用户的每一次点击事件都以一整条链路的数据结构进行存储。

这样当业务人员选择一组节点时，系统会将所有用户中存在这一条路径的所有节点枚举出来，在进行计算和处理，从而达到无需业务人员事先定义漏斗，只需要在系统中配置一组事件即可看到其转化及流失情况。

3. 用户群体分析

通过漏斗分析发现某业务的A到B节点的转化非常低，并已将该部分流失的用户ID导出，希望能找出问题的原因。

可以通过两种方式：一是电话访谈好几万的用户累死你；二是利用该类用户的数据进行分析。

首先我们可以先看看这部分用户都是谁，整体的属性分布是什么样的，那么就需要用到用户群体分析的功能，它必须支持用户组的导入及保存，以及灵活的图表组件（如性别饼图、年龄分布图、城市分布图、地域、设备、消费等）。然后再利用用户行为分析等其他分析工具或方法，或许就会帮你发现数据的规律，找到该类用户流失的原因。

以上是个人在创业公司中从0到1摸索的一些数据产品经验，当然与大公司的数据能力相比这些不足为奇。写出来是希望与大家分享自己的一些思考，同时也希望能够与大家一起学习和成长，文中若有偏差之处请多包涵。

数据本没有意义，需要工具和算法以及能够驾驭它们的人，数据才能够创造价值。因此我始终认为现在拥有数据思维比拥有数据更重要，毕竟无法量化，就无法增长。

盒子：BOSS我发现我们最近这个版本的活跃用户和平均停留时长都有所降低，一定程度上会间接影响到商品的销量。

盒子：查了一下最近版本的迭代功能，发现社区的入口被关闭了一个，发帖量减少了将近一倍。

盒子：所以这个版本我们将用户社区版块优化了一版，结果发现用户的平均停留时长，以及电商的销量都有所增加。

BOSS：好的，就说我很看好你！

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

题图来自Unsplash，基于CC0协议