360数据中台与数据工具建设（一）

李娇老师：Hello，各位同学大家好。今天所分享的题目是主办方给到我的，我一开始没有去细想，感觉这对我应该没有什么大问题。然而但我真的在做的时候发现，这个标题还挺大的，所以后面我可能拣选一个产品来去细聊，关于这款产品的建设过程。

这次分享我会分四个板块来讲。第一块是产品设计方法；第二块是隐私审批的设计，大家应该有所了解，从今年的上半年开始，国家对个人隐私相关信息的管控相较以往会更加严格；第三个是关于权限管理的创新；第四个是我们内部一些产品使用的案例。

1 产品设计方法

目前内部的产品非常多，会分很多的系列，有 ToB 商业化的，也有一些 TO G (政务)等等。今天我们说说的仅仅针对我们对内的产品。

首先第一个是要确定的是产品定位，关于产品可能面向的用户群，那这些群体用户有什么样的数据问题。

第二，是用户调研，需要对已经确定好用户群进行一些调研，然后了解他们的特征。

第三，往往内部产品都会已经有历史产品了，所以也需要去了解历史产品的优点和缺点，在此基础之上设计一个新产品。第四，基于前面的定位调研，还有一些历史文件，充分了解之后，去做一些相关的一个产品架构，做完架构之后的话，就会跟研发一块确认相应的技术点和研发的难点，而后再进行详细的产品设计，后面可能会做内部的产品的运营。

1.1 产品定位

关于360数据中台的产品定位，先是整个数据中台一个大的定位，说我们有过分析，关于数据类的产品主要是给哪些人用的，发现基本上是给公司内部的各个业务线的领导、产品、运营、市场、商务、数据分析师、研发，还有会有一部分的数据科学家。他们重点想要了解的东西是关于新增、活跃、留存、流失这类的主题数据，还有一些关于转化的，比如付费，还有一些崩溃相关的，比如错误分析事件，还有 LTV、AB 测试、画像等等。

1.2 用户调研

我们针对这些要服务的对象做一个用户的调研。基本结论是，公司内部有 75% 的人的，需要使用数据类的平台去做相关的一些分析或者可视化。用户构成中，女生会占75%，非研发人员能占到88%。

我们大概分析了一下他们的工作场景，发现基本都业务人员，类似于产品、运营、分析师，只有极少数的会使用一些脚本命令的同学。那如果是这样话，说明我们的产品其实要尽可能的简单化，偏向于做又简单又方便又好用的一个高效的分析平台。

1.3 了解历史问题

调研之后，我们就开始去了解历史的问题。第一个历史问题是，历史系统非常多，操作麻烦。我们之前的系统，我这边只列了 10 个，以前的老系统基本上有将近 20 来个，这样用户在使用的时候会有选择困难症，他们根本就不知道在做相应分析的时候应该使用哪一款产品，这就成为了一个痛点。

第二个历史相关的问题是，不稳定因素导致系统存在很多的 bug。对于搭建新的中台，我可能需要稍微解释一下背景情况，在我接手中台建设的时候，相关的中台已经有 20 来个历史的产品了。但是这些历史产品因为各种各样的原因，使用困难也好，BUG多也好，导致业务线的吐槽会非常的多，所以我才接手这个项目。我们基本上了解各种各样问题之后，我们就能够很清晰的知道我们要干什么。因此，经过重新的评估和分析，我们决定从 0 到 1 来搭建一个新的平台。

1.4 产品架构

我们做了一个新平台叫雷达分析，这个平台本质上是要解决用户对数据从采集到清洗再到分析的可视化。看起来问题只有四个，挺简单，但是历史上居然能做那么多系统，真的是挺难为他们的。我们重点是要帮助业务线的人员能够快速的提升数据的获取效率，然后可视化分析他们自己的数据，发现他们的问题，让业务层面可以增加留存和营收，这个是我们解决的问题。

基于这四点：采集、清洗、分析、可视化，我们对流程进行了层级化的拆解。

·采集层：我们支持安卓、iOS、WEB、小程序等，以及服务端会支持到 hive mysql、druid等；

·清洗层：我们会基于具体的数据类型，形成 UE 模型和数仓模型。

·分析层：基于UE模型，我们会再做一个上层的分析，比如事件分析、留存漏斗等等。今天我也只是举一点案例。基于数据模型仓，往上层就是自主查询，多维分析，进一步会再做一些可视化层。我们会基于标准化的模型，生成相应的标准化报表，同时会支持用户做一些个性化的自定义看板。

我们目前是使用 UE 模型和数仓模型合并的方式，这种方式不仅适合互联网业务，同时也会适合物联网业务以及各种各样的通用的一些分析。那很多人可能听到这里就会有疑问，现在已经听你讲完分层结构之后，我是不是就已经懂了之后如何做好一款数据产品了呢？不是这么简单，我们还需要非常的清楚地了解这里面的数据的具体运转的逻辑。大家可以看一下这个图。

我们前面讲到数据分成了来自客户端的数据和来自服务端的数据。

图中“客户端的数据”流转是用蓝色的线表示，最终会变成标准化的报表，同时会支持事件分析和留存分析，也同时做成相应单独的可配置的看板。

“服务端的数据”是可以支持自助查询和ETL相关的操作，同时也支持多维分析（现在很多地方也称之为OLAP ），可以配置更多的报表、看板，这样用户可以做一些业务的核心分析。我们正在设计中的，也是我们未来可能会支持的，是从服务端的数据可以自定义的转化成客户端的事件模型。

然后第二个数据流转是我们未来会支持的内容，包含自助查询和 ETL ，同时支持客户端- SDK 的一些事件相关的内容。这个是我们设计的数据流的运转逻辑。

       基于这个设计，我们已经上线了产品，因为这是我们公司内部的产品，我们也就并没有去做对外的推广，所以具体的产品形态相关的内容，我今天没有办法展示太多的截图。去年 10 月份，我们完成了这个内部的产品的上线，上线时我们在内部开了一场发布会，我们对公司内部的一些重点的业务线做孵化，同时会创建“用户群”。

       说完产品设计方法，那么产品在实现上线以后，我们的流程也就来到了最后一步，就是对上线的产品做相关运营的，只不过是对于内部人员使用的产品，相对而言，可能真的是只有用户运营。我们对上线的产品分析发现，每周的活跃使用人数长不多是1000 多人，目前覆盖了360内部几乎所有的业务线，从大到小，从安全卫士、360搜索，到360浏览器、手机助手、手机卫士等等。