笔者所在部门为数据中台,职责就是为公司搭建数据中台,支撑各产品线数据化运营,通过数据中台打通各条产品线的数据,更精准的为产业的上下游客户服务。本文以B2B电商产品亿订为实战谈数据中台的数据埋点。
图片来源:富力环球商品贸易港公众号
刚入公司时,公司的数据埋点这块是和百度合作,用的百度移动统计。运营反馈百度的流量分析做的很强大,但是最大的问题是不能结合电商的业务数据。比如只有坑位的流量数据却拿不到坑位的交易额、转化率(交易额/PV)这些数据,另外电商的主路径 访问>商品详情>商品列表>加购>下单>支付整个流程的转化率是取不到的。此时就拉上我们的开发,叫上了亿订产品经理和运营负责人,一起沟通目前的问题。
图片来源:百度移动统计, 百度的移动分析看不到任何业务数据。
沟通后确定主要确定解决以下问题:
问题一:要知道亿订B2B电商产品每天的主路径 访问用户数>商品列表页>商品详情页>加购>下单>支付主路径每天的人数及每个步骤之间的转化率,目的是长期监测每步的转化率如果有明显异常,运营同事会进一步分析转化率低的原因。
图片 来源:亿订电商, 从左到右以此为:首页、商品列表、商品详情、加购、结算页
问题二:因为问题一只能解决总体转化率,要想定位到底是那里的转化率低导致整体转化率低的原因,还得看用户每个入口路径各环节的转化率。
问题三:要解决坑位的转化率问题,因为评价坑位好坏的因素不止有PV/UV百度统计的两个指标,运营同事定义了坑位的转化率为(pv/坑位交易额)来综合判定坑位的性价比,如果坑位的放在很明显的位置,那他的转化率还是很低,那就要分析原因,改变运营策略。比如图片的调整、商品的调整、位置的调整等。
问题四:要打通用户的行为数据和用户的交易数据,用户运营的同事需要更加了解他们的用户比如什么时候访问,访问了那些商品、什么时候加购,加购了那些商品,什么时候买了那些商品。这些百度是做不到的。通过用户的 访问行为,运营同事会进行针对性的运营型。
问题五:要看到用户的留存情况,留存的定义分为两种,第一种是访问留存率,新用户第一次访问看他接下来7天后、14天后、一个月后是否再次访问。第二种是购买留存率,用户第一次支付后看接下来的7天后、14天后、一个月后是否再次支付。这样就能直接看出平台的用户粘性。
基于以上问题,我们数据中台内部开始设计产品方案和技术方案。
埋点技术选型
要解决以上问题,就要对亿订的H5端、APP端(IOS/安卓)进行全面的埋点,如果采用手工埋点的方式,工作量是比较大的,而且依赖各个产品线的前端开发(JS/安卓/IOS)。我们的技术负责人研究了市面上各个数据公司的埋点方式,从是否开源,SDK是否支持H5、安卓、IOS。部署方式是私有化,还是saas化(采集到的用户数据是公司比较重要的数据,出于安全考虑,需要本地化部署)这几个方面入手决定用神策开源埋点SDK,这样节省了大部分的工作量,SDK一旦部署基础信息比如(时间、地点、浏览器、硬件设备)都会自动化的采集。
基础信息采集
接下来就要进行埋点接口的定义。首先是公共字段的定义,这些都封装在SDK中,只要前端工程师基于SDK的开发文档进行工程部署,程序就是自动收集用户的这些基础信息。这样用户在那里,用户使用的什么设备,用户什么时间访问了我们的产品,就解决了。
字段归类 |
字段中文名称 |
字段英文名 |
字段类型 |
说明 |
设备及浏览器信息 |
操作系统名称 |
$os |
String |
终端操作系统 |
操作系统版本 |
$os_version |
String |
终端操作系统的具体版本号 |
|
屏幕高度 |
$screen_height |
NUMBER |
屏幕的物理高度 |
|
屏幕宽度 |
$screen_width |
NUMBER |
屏幕的物理宽度 |
|
浏览器名称 |
$browser |
String |
访问该系统当前浏览器的名字 |
|
浏览器版本 |
$browser_version |
String |
当前浏览器版本 |
|
用户代理 |
user_agent |
string |
||
当前SDK信息 |
SDK名称 |
$lib |
String |
当前埋点采用的sdk的类型,如ios、Android |
SDK版本 |
$lib_version |
String |
当前sdk的版本号 |
|
网络信息 |
IP地址 |
Ip |
string |
当前用户的公网IP |
国家 |
Country |
string |
当前用户所在国家 |
|
省份 |
Province |
string |
所在省份/州 |
|
城市 |
City |
string |
所城市 |
|
经纬度 |
纬度 |
latitude |
string |
当前用户所在纬度 |
经度 |
longitude |
string |
当前用户所在经度 |
|
时间信息 |
服务器时间 |
server_time |
Float |
事件发送到服务端处理后的时间 |
客户端时间 |
clientTime |
Float |
事件发生时客户端时间 |
|
来源渠道 |
流量来源ID |
trafficSourceID |
string |
识别用户是从哪里来的编码,也就是访问渠道ID |
浏览页面事件采集
接下来是用户浏览页面数据埋点,这个协调了亿订的产品经理梳理了亿订的所有网页地址和按钮名称(为了后文的触点埋点)包括上文提到的入口页面推广页、首页、商品列表页、商品详情页、加购页、下单页、支付页等关键页面进行了全方位的埋点。拿电商最关键的商品详情页举个例子,他有可能是从坑位来的,有可能是从搜索来的、有可能是从推荐来的,要记录他的来源信息,才能对以后的分析有作用。比如上文问题三提到的转化率是涉及到坑位产生的交易额和PV两个指标,那每次进入商品详情页,要记录坑位的信息才能进一步计算出坑位的总的销售额和转化率。数据中台是数据贪婪的应用,埋点收集到的信息当然是越详细越好,不过过多的埋点也会影响前端的性能,所以所有的埋点都是基于问题指向的。
序号 |
页面名称 |
字段英文名称 |
字段中文名 |
字段类型 |
3 |
浏览商品详情页 |
pitpositionID |
坑位ID |
string |
pitpositionnum |
坑位位置 |
number |
||
sourceStoreID |
来源店铺ID |
string |
||
keyWord |
搜索关键词 |
string |
||
recommend |
推荐ID/url |
string |
||
commodityID |
商品ID |
string |
||
pricePerCommodity |
商品单价 |
number |
||
storeID |
店铺ID |
string |
触点事件采集
基于亿订业务线提供的按钮列表,让亿订的前端开发工程师对关键按钮点击进行了埋点开发。有两方面的作用,一方面如电商主路径中的加购是按钮点击不是页面点击这时就要通过触点事件的方式先收集数据后期格式化为页面浏览事件来处理。另一方面如要看关键按钮的点击次数,关键页面的转化率(如登录、注册页转化率等)都需要统计按钮的点击。
模块 |
字段英文名 |
字段中文名 |
字段类型 |
按钮点击 clickButton |
buttonID |
按钮ID |
string |
buttonName |
按钮名称 |
string |
问题一
关于问题一的电商产品的主路径:访问用户数>商品列表页>商品详情页>加购>下单>支付,只用取这些页面的UV就可以了,不过有几个个问题需要注意。
1.访问到到商品列表页的转化率 访问用户数最好是访问了首页+访问了商品列表页+访问商品详情页的人数去重后的UV,因为也有人直接 从商品列表页或商品详情页进入产品。这样算才能更精准
2.加购>下单的转化率可能大于100%,比如今天加购的用户可能在后天下单。
3.加购是一个按钮不是页面要格式化为页面处理。
基于这些问题设计出了电商主路径的页面,主要可可以看出每天的访问用户数,浏览商品列表页用户数、浏览商品详情页用户数,加购用户数,下单用户数、收藏用户数、分享用户数和他们之间的转化率,每天的转化率我们以漏斗的形式展现,这样更能直观的看出转化率的变化情况。 点击数字后可以查看用户明细信息,可以直接导出这些结果,做针对性运营。这样主路径的问题就解决了。
问题二
运营用了一段时间就提出另外一个问题,天天看这些结果,但是就算发现了转化率比较低,也很难找出转化率低的原因。为了解决这个问题我们基于百度的历史数据发现亿订的访问入口(用户第一次进入的页面)只有这几个 推广页、首页、活动页、还有用户直接从商品列表页、商品详情页进入(大部分是朋友圈的推广),如果能知道这些入口主路径的转化率,那问题范围就缩小了。于是就有了入口分析功能,和其他数据产品的路径分析不太同,我们不但把入口主路径的转化率清晰显示出来,还可以看每个路径每天的变化趋势。这样就可以更加直观的观察出路转化率低那条路径。计算的方法要在这里讲下,第一步把所有的用户访问分为N个会话(我们会话的间隔时间定义为20分钟,也就是访问一个页面后如果超过20分钟才访问下一个页面,那下一个页面就算另外一个会话)。第二步找出用户首次访问包含这些入口的会话。第三步把用户的访问路径打横,遍历用户的访问路径如果满足我们定义的路径,这条路径就会算一个UV。 计算时商品列表页它是从搜索来的,还是从分类来的,还是直接从首页来的已经提前打好标识。
问题三
坑位转化率涉及坑位交易额,但是埋点数据有5%左右的丢失率,比如用户操作时的网络不好,此时用户的埋点数据就无法正常上传到埋点服务器。我们需要做到100%的精准。另外就是电商的加购是有一个断层的,比如用户今天加购,没有购买,过了2天直接进入购物车买商品,此时如果通过普通的数据埋点是很难得到购物车商品的来源的。和亿订的前端开发工程师商量后,就决定采用后端埋点的方式。用户加购时将坑位的ID信息传至数据库,每次从购物车取出商品支付时再从数据空中取出商品的所属坑位ID,下单时将坑位ID保存至订单中,这样从订单中就能直接分析出这个商品来源于那个坑位。
以上就是本次分享有关数据中台-数据埋点的所有内容,接下来会持续更新有关数据中台的产品设计、标签平台的搭建、推荐系统的搭建等更多干货。全部基于实战,欢迎持续关注。
首发 | 富勒科技完成3亿元融资,经纬领投,高成和高瓴跟投
11586 阅读中国兵工物资集团有限公司2025届校园招聘供应链管理、仓储管理等岗位
4962 阅读近1500人!中远海运24-25届全球招聘启动
4259 阅读吉利十一月岗位火热招聘物流、供应链类岗位
3833 阅读顺丰社招仓储管理经理、KA客户经理、SME客户经理、灵活业务资源专员、散单管理岗等
3795 阅读立高食品2025届校园招聘物流类专业
3780 阅读蜜雪集团2025届校园招聘供应链类岗位
3738 阅读拼多多集团-PDD | 2025届校招正式批网申时间延长至2025年1月12日
3693 阅读梅花集团2025届校园招聘物流管理类与工程、供应链管理等专业
3533 阅读日日顺供应链2025届校园招聘
3422 阅读