自从阿里提出了“大中台，小前台”概念之后，这几年数据中台这个概念火了起来，互联网巨头们纷纷搭建起了自家的数据中台，究竟数据中台有什么魅力，能让企业如此重视？本文笔者从数据中台是什么、怎么做数据中台和为什么要做数据中台三个方面对这个问题进行了回答。

很多人会问，到底什么是数据中台？

通俗地讲，数据中台就是一个在数据层面上为企业业务提供帮助、决策的一个工具。

在以前，数据往往只被显示，不被存储；慢慢地，人们需要随时随地查找数据，存储数据的概念被普遍认知；再慢慢地，人们渐渐产生了数据思维，发现可以通过观看数据来制定运营策略；当互联网时代进入了爆发期，此时产生了大量的数据，人们通过数据挖掘，收集大量的外界数据作为决策的依据。

而如今，互联网已步入一个较为成熟的时期，大公司纷纷去打造自家的数据中台，将海量的数据作为自身的资产，并擅于利用数据中台将数据进行整合、智能分析，以数据驱动决策。

说到数据中台，又会牵扯到数据仓库，很多人一看，数据仓库？不就是数据库嘛，存储数据的东西，其实这是不太正确的认识，那这两者的区别又是什么呢？

数据仓库主要是将收集到的数据进行分析、处理；

而数据库主要是面向事务的处理；

数据仓库主要集中资源去优化资源的获取方式，因为业务人员、运营人员对于数据的获取需求是非常大的，往往每天都有大量的数据会被调用、获取以及处理；

而数据库主要集中资源对增、删、改、查等等方面的功能进行优化，防止过多的数据更新和事务影响数据库的效率和稳定性；

数据仓库往往是以时间来进行组织数据，以电商订单为例，数据仓库分别会以“1小时订单”、“1日的订单”、“1个月的订单”组织好数据分析表，方便业务人员获取分析；

而数据库则是以索引和实体内容来组织数据，例如“数码产品订单”、“生鲜订单”、“服装订单”等等将不同的数据表进行组织；

数据仓库往往是高冗余的，因为数据仓库希望借助更多重复类型的数据去分析整个产品的运营走势，为下一步的运营决策做依据；

而数据库往往是低冗余的，数据库不希望存储大量重复类型的数据，从而影响数据库整体的性能效率；

谈到这里，大概对数据中台有初步的了解，那接下来看看我们如何去搭建一个最适合自己公司的数据中台吧。

为什么要说是“最适合”自己的数据中台呢？

数据中台无论是功能、逻辑都是非常的复杂，其中涉及到的字段、维度非常的多，那如何打造最适合自己的数据中台呢？可以这样去思考：

首先必须根据自身业务出发，去分析到底我们需要什么数据？下面是例子：

（1）电商业务

电商，离不开订单、商品、支付等等这些数据，就订单数而言，就可以拆分这几个维度进行统计：分/时/日/周/月订单数、人均订单数、男性/女性用户订单数、服装/数码产品订单数、复购订单人数、订单销售额 、订单成交率、订单退换率等等；

如果是商品，又会涉及到商品种类成交数、商品点击率、商品评价数等等；

如果是支付，则会涉及到支付成功/失败率，支付次数、支付渠道、支付优惠使用率等等。

（2）直播业务

谈到直播业务，核心角色可分为主播和用户，整个直播平台就是围绕着这两大核心角色进行设计的。

简单的说，直播就是主播和用户进行信息交换的一个过程，主播提供内容，用户消费内容，反馈信息（发送弹幕，赠送礼物等等，当然用户也可以不做任何操作，但也为主播提供了人气和观众数）；

可以分析整个直播流程就是：主播打开直播间——用户收到推荐/订阅提醒/搜索/首页推荐等等方式进入了直播间——主播与用户进行信息交换、互动——用户退出直播间/主播下播——直播流程结束。

那么从这一简单的流程中，我们就可以挖掘出许多的数据指标，例如：开播1分钟/小时观众数、消息推送/订阅/首页推荐点击率、搜索次数、弹幕发送次数/率、送礼种类/数量、观看直播1/5/10…分钟的用户数、各种留存率等等，由于数据指标过多，暂先列出以上数据。

（3）出行业务

出行业务，我们也是根据业务流程去分析：用户提交订单——司机接单——用户上车，司机确认，订单开始——到达目的地，司机确认，用户下车——用户支付（自行决定是否评价）——订单流程结束。

根据流程，我们可以继续挖掘数据指标，例如：某区域内1小时内订单发起数、司机一天接单数、平均订单金额、订单取消数/率、订单公里数、某区域订单平均响应时间、订单好评/差评率等等。

因此要分析需要什么数据，必须切实地从自身业务的流程一步步去拆解出各个指标数据。

（1）明确需求

当明确自身需要什么数据后，此时可以与业务、运营人员进行沟通，他们需要什么样的数据，需要怎样组合数据，呈现方式是什么，是否支持导出数据等等，都需要产品经理与业务方进行详细地沟通，明确每一个需求，才能算是前期工作准备的良好开头。

（2）原型设计

当明确需求后，就可以开始进行原型设计了，这里就涉及到了设计的细节：如何让数据可视化更清晰？如何让操作更加简便，业务人员更容易上手？

因此在设计的过程中，除了跟开发保持沟通，同时还需要跟业务人员保持一定的联系，防止原型设计好，业务人员不满意又要大改。

（3）需求评估，跟进开发进度

当设计好原型和撰写好需求文档后，就可以进行需求评估了，这个阶段如果出现难以实现的功能，那产品和开发就要共同去想如何换另一种设计方式去解决同样的问题；

然后还有就是进行需求排期，大概确定每一个时间节点，产品经理时刻跟进开发进度。

（4）开发完成，严格测试

可能大家会想，中台又不是给C端用户用，测试那么严格没必要；但正是因为中台不是给用，而是给业务人员用，如果出现了数据上的严重纰漏，影响了运营的决策，那么带来的业务影响也是非常严重的，因此严格的测试必不可缺。

（5）成功上线，时刻跟进问题

测试结束后，终于可以上线了，然而重头戏才刚刚开始，此时会发现，业务方使用了中台后向你提出各种各样之前测试测不出来的bug，此外，还会吐槽功能的各种不好用，甚至给你提另外的需求……

作为中台产品经理的你，此时可能会感觉压力非常的大，但只要我们时刻保持跟进，合理安排项目进度，解决需求，我想，业务同学也不会刻意去为难你。

据调研发现，其实市面上已经存在不少如“神策数据”、“BDP”、“帆软”等等的第三方智能数据平台，企业购买即可使用，那相当于已经有现成的了，为什么还要大费周章去自己开发呢？

我想，可能是因为这些原因：

对于大公司来说，他们拥有的数据是海量的，海量的数据里面往往存在着许多商业价值极高的数据，简称商业机密，是不能泄露到外界去的，因此自家研发的平台能够保障一定的安全性。

数据对于企业来说，就是资产，尤其在大公司，数据就是运营决策的依据，若被竞争对手得知了数据，提前判断到对方的下一步运营策略，万一在某一重要节点的活动中竞争失败，对于企业来说则是遭受非常大的损失。

第三方数据平台往往是根据付费价格来区分服务质量的，如果想要享受到更多更好的服务，必须提高支付的费用，如果需要定制化方案，成本会变得更高；

如果采用自建平台，首先开发什么功能，调用多少资源都可以自己决定，对于成本有一定的把控能力，同时，如果后期扩展功能，也会更加地方便。

由于用户的需求种类繁多，因此业务人员提的需求往往存在个性化特征，例如需求以报表形式呈现，报表由各种指标组成，指标与指标之间形成了多对多关系，指标之间互相关联，那么这种多样化指标是第三方平台无法满足的，因此自建的平台就能体现它的作用了。

当互联网的红利逐渐消失，如何利用数据智能化运营将会是每一家企业的重要任务，运营人员的能力固为重要，但拥有一个好中台，会让你的运营走得更加顺畅。

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

题图来自Unsplash，基于CC0协议