前言：有幸深度参与了公司从无数据，到有数据，到开始重视数据，最后能够尊重数据结果，参考数据进行决策的过程。本篇文章是笔者在这个过程中，作为数据产品搭建数据指标体系，如何踩坑、出坑，以及对数据仓库建设中的一些总结。

如标题所言，如果贵司已经是B轮之后，数据指标和平台化产品应该已经比较健全，属于数据产品应用阶段。如果贵司处于B轮及B轮之前阶段，大概率上会出现笔者下面所描述的情况。

本文较长，目录如下：

1 混乱期：资源有限，功能为先，忽视数据

1.1 资源永远不够用

1.2 数据产品的窘境

2 规范期：他山之石：GrowingIO和神策

2.1 GrowingIO平台实践总结

2.2 神策平台实践总结

2.3 他山之石后的埋点设计及管理

3 平台期：建设数据仓库

3.1 数据维护及治理

3.2 数据仓库架构设计

4 未来：数据中台？

4.1 我理解的数据中台

4.2 数据中台学习资料推荐

------正文分割线------

1 混乱期：资源有限，功能为先，忽视数据1.1 资源永远不够用

笔者所在的内容服务公司，在搭建指标体系前，已经“裸奔”了3年。对于内容产品来说，最影响用户体验的是内容本身，公司前期依靠不错的内容口碑，搭上知识付费的风口，发展迅速，公司资源和业务方向更多是受运营驱动、销售驱动，目标简单而明确，做什么心里都有大致预判，轻轻拍拍脑袋，这事儿就定了。后来平台用户数达到第一个1000w，日活进入50w量级后，新人加入，业务线也在拓展，基于主线业务上的优化和探索，不敢再轻易拍脑袋了；各业务线也有不同的诉求，如何评判优先级和协调资源，没有数据，很容易僵持不下。

也是在那个时候，决定要参考数据来决策了。之前APP偏向于做功能，只在特殊功能点，或活动节点时，会在产品需求文档中，附上埋点需求。彼时突然想看很多数据，会发现除了一些大数据（日活、激活率、付费率等）外，缺少很多细部数据，因为压根没有做埋点上报的需求，从日志中也无法解析出相关数据。

后来在每个版本中，由功能产品经理附上相关功能的埋点需求，大部分开发资源还在具体功能开发上。在功能上线后很久，才会想起来捞数据看看效果。初创公司很容易在业务快速扩张中忽视数据的作用，产品开发团队首要解决的是不断新增的业务需求。资源总是不够用的，所以数据埋点处理、数据分析、复盘等工作一直处在被忽视的地方。

1.2 数据产品的窘境

彼时我转岗到数据产品，常自嘲自己是一个取数机器。公司有数据需求的部门共有7个，我负责对接各部门的数据需求，梳理清晰后再提交任务给大数据组，由他们做具体的ETL工作。这中间，常会陷入到以下的汪洋大海中：

与需求方沟通并最后明确最后的数据需求（比如：活动组提需求想看某活动页分享数据，经沟通之后，其目的是想看新页面的文案上线后，对分享/浏览比的影响，因此明确了该需求是该页面的uv、pv，以及分享控件点击的人数、次数）；提交明确需求后，大数据组发现之前没有埋点，然后需要跟需求方解释，这个数据为什么拿不到，从ta的分析目标再看看，是否还有其他数据也能够达成这个分析目标。

那段时间非常忙碌，但总感觉自己是个二传手，最大的收获，就是在对接了N个需求之后，发现我司的数据基础建设情况惨不忍睹：平台埋点不规范、数据指标定义不统一、业务数据库和数据仓库标准不统一、数据需求处理周期长…… 我的精力很多耗在沟通需求、管理需求上。后来与公司的数据分析部门一同讨论制定了一套新的数据提交流程：每个部门的需求汇总到部门中的一个数据对接人，由ta先行提交到数据分析组，简单需求，会由数据分析组通过DBeaver等工具，连接数据库导出，复杂类、工具类需求，则提交给我：

图1：数据需求提交流程

另外，针对每个部门的数据对接人进行了指标定义的说明，以及提交数据需求的规范标准的培训：

图2：培训资料一页：什么是好的数据需求

此时的工作还停留在偏临时需求的处理上，作为数据产品，却没有做出多少数据产品出来。

2 规范期：他山之石：GrowingIO和神策

在决定搭建数据体系后，我司接洽了几家头部的数据平台，如GIO、ThinkingData、神策等，来补充我司埋点功底薄弱的问题，最后选择了GIO，在使用了一年多之后，因为要做私有化部署，而GIO的私有化部署功能还刚处在开发阶段（写这篇文章的时候，他们的私有化部署已经做出来了），于是我司又决定换神策平台，重新来一遍POC和SDK接入工作（对，就是这么折腾，o(╥﹏╥)o）。在完整地对接了这两家平台之后，我司数据体系逐步走向规范，我也总结了一下两家平台关于指标管理、数据体系搭建的工具特点，以及思路进行了一些总结，如下。

2.1 GrowingIO平台实践总结

在接触了几家平台后，我们最终选择了GIO，该平台的特点非常明显：

拥有无埋点技术，能够实现做功能时，不需要专门针对埋点花费工时，接入GIO的SDK，在功能上线后，SDK能够采集基础使用信息，同时，针对页面浏览数据，和页面控件点击数据，可以通过“圈选”的方式实现（对于彼时苦于埋点效率低下的现状，这种方案极具诱惑）；公有云部署，接入成本低；后台操作界面简洁，属于运营思路的一款产品，上手较容易；因为是SaaS服务，线上问题反馈速度比较快。

但后来发现一些问题：接入SDK后，我们只简单对接了会员状态数据，做了少量的埋点指标，除此外手动圈选了大量页面指标和控件数据，因为GIO的圈选功能实在太好用了，所见即所得，不必再发版等埋点上线，经过简单操作后就可以自己取数、看数，结合GIO提供的基础分析工具，如事件分析、漏斗分析、留存分析等功能，人人都能成为一名分析师了。

图3：GIO圈选功能

但到后期，圈选数据的问题逐渐暴露，也成为平台要更换GIO平台的导火索。圈选数据的逻辑：是根据页面xpath路径，监听页面浏览事件，和页面上的控件的浏览、点击事件，保留7天，因此圈选完成后，能往前追溯7天的数据。圈选功能的问题主要在于：

耗流量，看下逻辑你应该能理解；一旦版本迭代，对页面的路径做修改，或者控件位置、文案有修改，原来的圈选数据可能就会出错，需要重新圈选，之前利用圈选指标设定的分析模型都要替换；圈选指标无法区分细部参数，比如：书籍详情页，无法通过圈选数据来区分是哪一本书；对web的页面数据处理一直不好，尤其是涉及到APP的内嵌H5页时，非常痛苦。

图4：版本升级后，某圈选指标数据突降

这其实也是GIO的业务同事比较推崇无埋点技术，而我司彼时经验尚不充足踩下的坑，到后半阶段开始补课，开始做客户端和服务端埋点了，埋点开发周期虽然长了点，但是至少能够用得起来。但是因为之前对GIO工具使用上产生的各种不爽，导致后面有了更准确的埋点后，大家用起来也常常怀疑，这数据准不准，能不能用？一旦对数据源产生不信任感，产研团队的解释成本高，数据发挥价值的周期变长，团队屡受质疑又看不到成绩，大数据团队本身在数据体系建设的早期存在感就低，如此一来，工作积极性变得更低。

后来受资方等多因素影响，我们需要做私有化部署，对数据的准确度、智能运营也有更进一步的需求，而彼时GIO还没有成熟的私有化部署功能，因此我们两家后来好聚好散，转而选择了神策。（此处抱着GIO的同学哭一会儿）

但总体来说，GIO平台还是可圈可点，它的优势在于：

数据响应速度快，圈选功能比较成熟，对于快速迭代活动的场景，圈选功能最为便捷；用户操作界面友好，几大核心分析功能逻辑结构清晰，学习成本低，能够实现在公司大范围推广使用（你千万别觉得这类数据工具是可以轻易上手的，根据我在公司推广GIO和神策的经验，工具使用门槛并不低）；售后团队比较专业，能够从分析视角，发现我司业务上的问题；并且对平时提到的问题，反馈及时，问题解决程度也比较高。2.2 神策平台实践总结

后来因为私有化部署的诉求，选择了神策平台的产品。这里解释下，为啥没有选择自己研发数据产品。这其实是一个很经济学的考量。在接入GIO前，我司有自己一套ubt的埋点系统，但是只是基础的数据采集，以及raw data进数据库，从raw data 到数仓，再到提取，把统计类数据以excel形式，或者教会分析人员使用SSMS或PowerBI来进行取数分析，中间流程太长，无法做到快速响应及反馈。而找一个团队自研，时间成本和人力成本都太高。

神策、GIO这样的平台，取数功能完整度比较高，而且有一个比较完整的可视化分析平台，包含了事件分析、漏斗分析、留存分析等基础的分析功能，也有归因分析模型、用户画像等功能，这些功能找一个大数据团队和几个算法工程师，一年的成本高了去了。对于B轮左右的公司，建议别折腾，花点钱，除了避免自研成本，还能从这些SaaS平台的服务中，了解到比较成熟的方法论。

神策的分析全家桶有以下几款产品：

图5：神策产品矩阵

其中，左边【数据基础能力】是基础服务，可以选Pass，也可以选私有化部署，但是节点费、流量费是根据自己的流量来核算。（市政单位，或者对业务数据安全敏感度高的，建议私有化。不是说Pass不安全，像神策、GIO这样专门做数据服务的平台，不至于去泄露客户数据，一个客户数据泄露事件就可以让这类企业直接挂掉，这个账他们拎得清，而且有数据隐私协议）。右边的【数据应用产品】则是可选项了，【神策分析】包含了事件分析、漏斗分析等基础的分析功能，一般必不可少；【神策用户画像】和【智能运营】是偏向于运营侧的工具，如果自己没有精准营销的产研能力，这两项服务业比较好用。至于【智能推荐】和【神策客景】则根据公司情况，对于内容庞杂，品类繁多的内容平台、电商平台，还是比较有必要。但我个人认为，前三项服务玩得转了，再去考虑采购后两项服务不迟。

神策平台的特点是一开始推的是埋点方案，而非无埋点方案；而且最早支持私有化部署的数据服务平台。这一点是让他们能够获得一些金融行业、政企行业的单子的原因。这也是我们最后评估后，选择他们的原因。

2.3 我司平台的埋点设计及指标管理

在经过了UBT、GIO和神策三套埋点方案的使用和比较后，对于我司自己的埋点系统也有了比较清晰的方向，最后决定采用常规数据使用前端埋点、关键数据使用服务端埋点、临时活动搭配使用全埋点的方案。

全埋点、前端埋点和服务端埋点的区别

埋点方案

实施方案

优点

缺点

全埋点

部署对应sdk，页面及控件数据全采集，使用时解析

不需要做埋点开发；需要用的时候再去圈选使用；所见即所得，圈选时就可以看到数据；不需要测试介入，取数周期极短新圈选时，只能往前追溯7天；数据不够准确；发版后会影响之前圈选数据的稳定性。

前端埋点

前端定义的事件触发时，上传对应数据

较为准确；基本不会受页面改版影响。有一定开发工作量；设计新功能时需要考虑对原有埋点的影响，维护指标文档；会受网络环境等因素影响，出现数据无法上报或延时上报。

服务端埋点

服务端定义的事件触发时，上传对应数据

最为准确；不受前台功能改版影响。开发和测试的工作都较大；不容易发现问题。

而我司基本是前端埋点和服务端埋点的组合，其中关于数据指标的设计和管理，采用了下图所展示的字段名，对事实表进行管理和维护。

图6：我司数据指标维护表头

关于数据指标管理，最让我头大的就是如何保证可读性的前提下，梳理不断新增的数据埋点需求。我的设计思路是：以使用者视角设计，尽可能合并同类型指标，用维度保证扩展性，用备注内容保证可读性。

上面的指标维护表，是要同时给开发人员，和运营人员看的，这里指的使用者，是指运营人员。因为最后埋点设计做完了，也正常上报了，但是运营人员看不懂，用不起来，培训成本高企，是无法充分发挥数据价值的。所以在这里就需要数据产品经理平衡简约和可用性。

举两个例子：

例子1：平台资源位埋点设计

对于一般互联网产品平台来说，资源位无外乎两种类型，弹出型和轮播型；而具体指标无外乎浏览和点击，因此，将这两种类型的资源位抽象成下面4个指标，由维度（资源位位置、轮播位置）来进行拆分。

图7：平台资源位埋点设计

例子2：内容详情页埋点设计

对于内容类、电商类平台来说，内容详情页和商品详情页是最为关键的页面，因此这个页面的浏览数据极为重要。因为详情页是一个通用页面，而且对于一篇文章，或者一个商品来说，可能会在APP出现多个入口，如果对N个入口进行分别埋点，会让指标建设冗余，并且因为网络环境等影响，点击数≠页面加载≠页面加载成功，可能会采到脏数据上来。因此我在这里的设计思路是：以页面加载成功为触发，区分页面本身的数据信息，以及上一个页面的维度信息。

图8：内容详情页埋点设计

这里的挑战来自于去梳理上一个页面的类型和具体参数值，需要与运营组、数据组同事沟通清楚，他们关心的维度，以及下钻的颗粒度。

3 平台期：建设数据仓库

建设数据仓库是一个必然的选择，在业务体量不大，数据需求不多的情况下，从业务数据库捞数据，甚至解析日志，都是能够满足的。但后期必然会有更多维度、更复杂的分析型、报表型数据需求，全部依靠业务数据库显然不现实。现在计算机存储成本不高，数据仓库可以看做是一个【用空间换时间】的方案，数据仓库是面向分析、应用的数据库，在建立好标准的ETL流程和更新机制后，分析型、报表型数据需求从数据仓库中获取，从而提高效率，也解放业务数据库，让业务库专心处理业务。

特点

面向对象

数据库

处理业务需求，实时性要求高

具体业务

数据仓库

ETL后有比较明确区分的主题表可并多个表、多个维度，支持复杂查询

分析型数据

目前有关数据仓库的文章非常多，对数据仓库应该分几层，也有很多说法。这里需要明确一点，数据仓库的分层是一个理念，其核心是将不同应用层级的数据进行划分。一般来说至少有三级，我司采用的也是三级数仓。

数仓分层

数据来源

特点

ODS

操作型数据、实时数据、日志数据等

近似 = raw data

EDW

ODS层

按明确主题和维度进行ETL的数据表

DM

ODS层、EDW层

面向明确应用，ETL获取的数据表

3.1 数据维护及治理

基于Hadoop的成熟体系，搭建完成数仓系框架后，接下来要做的是往数仓中填充数据“血肉”，以及持续进行数据治理的工作了。在用数据赋能业务的链条中：产生数据（埋点）-> 获取数据(ETL) -> 分析数据 -> 发现问题 ->业务决策，似乎并没有数据治理的事情。链条上的四点是可见的过程，而数据本身产生污染后，可能会到获取时、分析时，甚至是决策阶段，才会意识到数据本身可能出现了问题。数据从触发上报-> 发送-> ETL-> 进数仓，中间有任何一个过程出问题，都可能会影响数据的稳定、准确和及时。另外，不断扩展的业务需求，业务数据字段会发生变更，这时错传、漏传了数据进数仓，也会影响数据质量。

总结下来，基于下面三个点，需要持续进行数据维护和治理：

数据进仓链路长，存在出现脏数据的风险；新业务需求增删改字段，没有及时同步进数仓；数仓表结构字段设计扩展性不足，新数据需要单独建表，导致冗余。

针对第1点，我司对于数据指标本身的异常波动做了监控的设计。在接入了神策平台之后，该平台提供了一个指标异常波动提醒的功能，还挺好用。

图9：神策数据异常监控

针对第2点说说我司实践。我司通过搭建【异构数据平台】来解决业务数据同步到数据仓库的问题。业务数据在进数据仓的同时，会按照约定的规范，同步传送一份到数据仓库；如果有修业务数据的情况，也需要异步地通过该平台，发消息给数据仓库，由数仓消费后，更新数仓的数据。

针对第3点，没有什么好办法，需要数据产品和大数据组、业务产品经理多沟通，对于数仓目前有哪些表，哪些字段，功能规划上，未来会新增哪些产品线，与当前业务线的关系，有一个大致预判，最大程度减少重复建表的工作。

3.2 数据仓库架构设计

基于以上，我司数据仓库是基于Hadoop框架，Hive处理离线数据，Flink处理实时数据，实现用户行为数据和业务数据准实时入数仓（有一些延时），并且前端数据产品应用，从数据仓库中调接口取数。（目前还没有完全实现所有业务数据都从数据仓库走，还在建设中）

图10：数据仓库架构设计

4 未来：数据中台？

数据中台概念在19年实在太火了，颇有些12年，到处都在说O2O的情形。对于数据产品来说，将产出的数据产品抽象化、共用化，成为像中台一样的基础服务能力是心之所向。但是否应该盲目上中台项目，谈谈我的理解。

4.1 我所理解的数据中台

我很喜欢【中台】这个词：处于中间，承上启下；成为平台，隔绝上下流动，但自身提供服务上下的能力。对于数据中台，其核心是提炼各业务线的共性需求，将这些需求解决方案封装为标准化、组件化的解决能力，然后以接口的形式提供给前前台业务数据。从而实现尽量少地重复造轮子，尽量多地提高研发的敏捷性。

不是所有公司都需要立刻做中台，但根据熵增定律，一家能持续发展的企业，其业务形态一定会不断发展和膨胀，而当新业务线和老业务线有共性诉求，能够通过中台化来提高效率，并且具有能串联多业务线的项目能力，这些问题想清楚，就可以开始做中台项目了。