最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

埋点、数仓到中台:数据体系的从0到1

[复制链接]
发表于 2020-3-30 13:45:27 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x



前言:有幸深度参与了公司从无数据,到有数据,到开始重视数据,最后能够尊重数据结果,参考数据进行决策的过程。本篇文章是笔者在这个过程中,作为数据产品搭建数据指标体系,如何踩坑、出坑,以及对数据仓库建设中的一些总结。
如标题所言,如果贵司已经是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 我所理解的数据中台
我很喜欢【中台】这个词:处于中间,承上启下;成为平台,隔绝上下流动,但自身提供服务上下的能力。对于数据中台,其核心是提炼各业务线的共性需求,将这些需求解决方案封装为标准化、组件化的解决能力,然后以接口的形式提供给前前台业务数据。从而实现尽量少地重复造轮子,尽量多地提高研发的敏捷性。
不是所有公司都需要立刻做中台,但根据熵增定律,一家能持续发展的企业,其业务形态一定会不断发展和膨胀,而当新业务线和老业务线有共性诉求,能够通过中台化来提高效率,并且具有能串联多业务线的项目能力,这些问题想清楚,就可以开始做中台项目了。
4.2 资料推荐
在学习数据中台的过程中,整理了一些资料,如下:
数据中台到底是什么?
换个视角看中台的对与错
有赞零售中台建设方法的探索与实践
三节课:中台产品经理

不会因为最后挂了一个三节课内容,认为我打广告吧,科科~
欢迎交流。

楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-28 20:56

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表