数据中台实战(一):以B2B电商亿订为例,谈谈产品经理视角下的数据埋点

产品小白专属,10周线上特训,测、练、实战,22位导师全程带班,11项求职服务,保障就业!了解一下

本文以B2B电商产品“亿订”为实例,与大家一同谈谈数据中台的数据埋点。

笔者所在公司为富力环球商品贸易港,是富力集团旗下汇聚原创设计师品牌及时尚买手/采购商两大社群,通过亿订B2B电商、RFSHOWROOM、环贸快版、环贸映像、富运通、富贸通等子品牌为时尚行业提供一站式产业+渠道服务的平台。

笔者所在部门为数据中台,职责就是为公司搭建数据中台,支撑各产品线数据化运营,通过数据中台打通各条产品线的数据,更精准的为产业的上下游客户服务。本文以B2B电商产品亿订为实战,谈数据中台的数据埋点。

图片来源:富力环球商品贸易港公众号

刚入公司时,公司的数据埋点这块是和百度合作,用的百度移动统计。

运营反馈百度的流量分析做的很强大,但是最大的问题是不能结合电商的业务数据,比如:只有坑位的流量数据却拿不到坑位的交易额、转化率(交易额/PV)这些数据,另外电商的主路径 访问>商品详情>商品列表>加购>下单>支付整个流程的转化率是取不到的。

此时,就拉上我们的开发,叫上了亿订产品经理和运营负责人,一起沟通目前的问题。

图片来源:百度移动统计, 百度的移动分析看不到任何业务数据。

沟通后确定主要确定解决以下问题:

问题一:要知道亿订B2B电商产品每天的主路径 访问用户数>商品列表页>商品详情页>加购>下单>支付主路径每天的人数及每个步骤之间的转化率。目的是长期监测每步的转化率如果有明显异常,运营同事会进一步分析转化率低的原因。

图片来源:亿订电商, 从左到右以此为:首页、商品列表、商品详情、加购、结算页

问题二:因为问题一只能解决总体转化率,要想定位到底是那里的转化率低导致整体转化率低的原因,还得看用户每个入口路径各环节的转化率。

问题三:要解决坑位的转化率问题,因为评价坑位好坏的因素不止有PV/UV百度统计的两个指标,运营同事定义了坑位的转化率为(pv/坑位交易额)来综合判定坑位的性价比,如果坑位的放在很明显的位置,那他的转化率还是很低,那就要分析原因,改变运营策略。比如图片的调整、商品的调整、位置的调整等。

问题四:要打通用户的行为数据和用户的交易数据,用户运营的同事需要更加了解他们的用户比如什么时候访问,访问了那些商品、什么时候加购,加购了那些商品,什么时候买了那些商品。这些百度是做不到的。通过用户的 访问行为,运营同事会进行针对性的运营型。

问题五:要看到用户的留存情况,留存的定义分为两种,第一种是访问留存率,新用户第一次访问看他接下来7天后、14天后、一个月后是否再次访问。第二种是购买留存率,用户第一次支付后看接下来的7天后、14天后、一个月后是否再次支付。这样就能直接看出平台的用户粘性。

基于以上问题,我们数据中台内部开始设计产品方案和技术方案。

关于技术方案

埋点技术选型

要解决以上问题,就要对亿订的H5端、APP端(IOS/安卓)进行全面的埋点,如果采用手工埋点的方式,工作量是比较大的,而且依赖各个产品线的前端开发(JS/安卓/IOS)。

我们的技术负责人研究了市面上各个数据公司的埋点方式,从是否开源,SDK是否支持H5、安卓、IOS。部署方式是私有化,还是saas化(采集到的用户数据是公司比较重要的数据,出于安全考虑,需要本地化部署)这几个方面入手决定用神策开源埋点SDK。

这样节省了大部分的工作量,SDK一旦部署基础信息比如(时间、地点、浏览器、硬件设备)都会自动化的采集。

基础信息采集

接下来,就要进行埋点接口的定义。

首先,是公共字段的定义,这些都封装在SDK中,只要前端工程师基于SDK的开发文档进行工程部署,程序就是自动收集用户的这些基础信息。这样用户在那里,用户使用的什么设备,用户什么时间访问了我们的产品,就解决了。

浏览页面事件采集

接下来,是用户浏览页面数据埋点,这个协调了亿订的产品经理梳理了亿订的所有网页地址和按钮名称(为了后文的触点埋点)包括上文提到的入口页面推广页、首页、商品列表页、商品详情页、加购页、下单页、支付页等关键页面进行了全方位的埋点。

拿电商最关键的商品详情页举个例子:他有可能是从坑位来的,有可能是从搜索来的、有可能是从推荐来的,要记录他的来源信息,才能对以后的分析有作用。

比如:上文问题三提到的转化率是涉及到坑位产生的交易额和PV两个指标,那每次进入商品详情页,要记录坑位的信息才能进一步计算出坑位的总的销售额和转化率。数据中台是数据贪婪的应用,埋点收集到的信息当然是越详细越好,不过过多的埋点也会影响前端的性能,所以所有的埋点都是基于问题指向的。

触点事件采集

基于亿订业务线提供的按钮列表,让亿订的前端开发工程师对关键按钮点击进行了埋点开发。

有两方面的作用:一方面如电商主路径中的加购是按钮点击,而不是页面点击。这时就要通过触点事件的方式,先收集数据,后期格式化为页面浏览事件来处理;另一方面,如要看关键按钮的点击次数,关键页面的转化率(如登录、注册页转化率等)都需要统计按钮的点击。

关于产品方案

问题一

关于问题一的电商产品的主路径:访问用户数>商品列表页>商品详情页>加购>下单>支付,只用取这些页面的UV就可以了,不过有几个个问题需要注意。

  1. 访问到到商品列表页的转化率:访问用户数最好是访问了首页+访问了商品列表页+访问商品详情页的人数去重后的UV,因为也有人直接 从商品列表页或商品详情页进入产品。这样算才能更精准。
  2. 加购>下单的转化率可能大于100%,比如:今天加购的用户可能在后天下单。
  3. 加购是一个按钮不是页面要格式化为页面处理。

基于这些问题设计出了电商主路径的页面,主要可以看出每天的访问用户数、浏览商品列表页用户数、浏览商品详情页用户数、加购用户数、下单用户数、收藏用户数、分享用户数和他们之间的转化率。每天的转化率我们以漏斗的形式展现,这样更能直观的看出转化率的变化情况。 点击数字后可以查看用户明细信息,可以直接导出这些结果,做针对性运营,这样主路径的问题就解决了。

问题二

运营用了一段时间就提出另外一个问题,天天看这些结果,但是就算发现了转化率比较低,也很难找出转化率低的原因。

为了解决这个问题,我们基于百度的历史数据发现:亿订的访问入口(用户第一次进入的页面)只有这几个推广页、首页、活动页、还有用户直接从商品列表页、商品详情页进入(大部分是朋友圈的推广)。

如果能知道这些入口主路径的转化率,那问题范围就缩小了。于是,就有了入口分析功能,和其他数据产品的路径分析不太同,我们不但把入口主路径的转化率清晰显示出来,还可以看每个路径每天的变化趋势。

这样就可以更加直观的观察出路转化率低那条路径,计算的方法要在这里讲下:

  • 第一步把所有的用户访问分为N个会话(我们会话的间隔时间定义为20分钟,也就是访问一个页面后如果超过20分钟才访问下一个页面,那下一个页面就算另外一个会话)。
  • 第二步找出用户首次访问包含这些入口的会话。
  • 第三步把用户的访问路径打横,遍历用户的访问路径如果满足我们定义的路径,这条路径就会算一个UV。 计算时商品列表页它是从搜索来的,还是从分类来的,还是直接从首页来的已经提前打好标识。

问题三

坑位转化率涉及坑位交易额,但是埋点数据有5%左右的丢失率,比如:用户操作时的网络不好,此时用户的埋点数据就无法正常上传到埋点服务器。

我们需要做到100%的精准,另外就是电商的加购是有一个断层的,比如:用户今天加购,没有购买,过了2天直接进入购物车买商品。

此时,如果通过普通的数据埋点是很难得到购物车商品的来源的。和亿订的前端开发工程师商量后,就决定采用后端埋点的方式。用户加购时将坑位的ID信息传至数据库,每次从购物车取出商品支付时再从数据空中取出商品的所属坑位ID,下单时将坑位ID保存至订单中,这样从订单中就能直接分析出这个商品来源于那个坑位。

问题四

采、存、通、用是对数据中台价值最好的解释。

采就是采集要采集用户行为数据和业务数据;存就是通过三层建模的方式对数据进行更科学的存储;通是打通,第一要打通用户用户行为数据和用户业务数据,比如能综合看到埋点采集到的数据像时间、地理位置、硬件设备和用户的购买行为像浏览、访问、加购、购买、收藏、分享等。

打通的第二层含义就是要打通公司内各个产品线的数据,比如:笔者公司要做产业的上下游,就要打通生产数据、销售数据、供应链数据,形成更加立体的用户画像。产品线之前的数据打通会在《数据中台实战-基于多条产品线的标签平台》中介绍。

问题五

留存率的概念每种产品都不同,一般来说就是锁定一批发生了某种行为的用户,看接下来的7天或者14天等等是不是又发生了这种行为。

电商产品的留存率是电商产品的北极星指标,是这样定义的:一个新用户在第一次来到产品后的一周内,如果一周内能让他购买1-2次,那接下来他的复购率会非常高。

但是,不同电商产品的消费频次是不同的所以基于我们产品的特性。我们做了7日留存率、14日留存率、30日留存率这几个数据指标来监控平台的用户粘性。另外就是电商产品初期用户量和交易量是比较小的,所以我们还特别定义了一个访问留存率的指标,看新用户访问后,7日后的留存情况、14日后的留存情况来综合监测用户的黏性。

以上就是本次分享有关数据中台-数据埋点的所有内容,接下来会持续更新有关数据中台的产品设计、标签平台的搭建、推荐系统的搭建等更多干货。全部基于实战,欢迎持续关注。

 

作者:Wilton(董超华),曾任职科大讯飞,现任富力环球商品贸易港大数据产品经理。微信公众号:改变世界的产品经理。简单、简短、有用,坚持原创、坚持做感动你的好文章。

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

题图来自Unsplash, 基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 董家兄弟👍

    回复
    1. ;-)

      回复