数据产品经理,要如何快速搭建公司数据体系?

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

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

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协议

给作者打赏,鼓励TA抓紧创作!
5人打赏
评论
欢迎留言讨论~!
  1. 请问大佬可以私聊下嘛~

    回复
  2. 老铁66的

    回复
  3. 请教一个问题,这个完整的数据系统的建设,哥们你们花了多长时间

    回复
  4. 请问下能不能提供开源的客户端数据采集SDK呢?

    回复
  5. 这等好文居然没人评论~这位PM一看就是要么搞过开发的,要么就是搞过ETL大数据的~这技术用语杠杠的,几个月前才搞完ETL数仓建设0.0

    回复
    1. 因为太专业。。。所以看不懂 :arrow:

      回复
    2. 没搞过ETL大数据的不懂正常~或许如果学点数据库东西还可以理解一下的

      回复