首页天道酬勤数据分析埋点是什么,数据埋点设计

数据分析埋点是什么,数据埋点设计

admin 08-23 17:48 314次浏览

1.1 概述

数据和特征决定了机器学习算法的上线,而模型和算法只是不断地逼近这个上限而已。

分类:

流量数据:以用户访问产品,记录用户浏览行为核心的埋点数据日志以生产系统内存储的业务表单数据为核心的业务数据记录。

用户访问产品时候的交互“动作”触发的是埋点数据的流量数据,用户访问产品看到的内容是业务数据。比如:我们“点击广告”时间,能够产生一条埋点数据,我们看到的广告内容是“商品”信息,商品信息是被存储业务数据。

什么是埋点: 埋点是数据采集一种重要方式,主要记录和收集用户在终端操作行为;基本原理是在app|H5|pc上布置采集数据的SDK代码,当用户的行为满足某种条件后,比如进入某个界面,点击某个button,会自动触发记录和存储,然后这些数据会被实时或延迟传递到终端服务器,或者通过后端采集用户使用服务过程中的请求数据。(前端:客户端埋点,在客户端上写代码SDK;后端:服务器埋点,在服务器上写代码)。

前段埋点:

前端埋点是在用户端(APP、Web、客户端)等嵌入数据采集代码,比如友盟等均采用的是前端埋点,比如通过嵌入一段代码就就可以对网页数据的访问数据进行采集。相比于后端埋点,前端埋点能方便收集到用户在界面上的行为数据,比如用户点了哪个按钮、页面之间的跳转次序、停留时长等,这些数据是后面进行数据分析的主要来源。

前端埋点有以下三类:

代码埋点
代码埋点是直接将采集SDK集成在终端,然后不断在此基础上添加调整采集方案,是目前主流的埋点采集方案,其优缺点如下:

优点:

高度定制、控制精准、采集的数据丰富准确

缺点:

首先是每当有采集需求,需要开发人员不断添加采集代码,工作量大;

其次变更采集策略,需要发布新版本,代价巨大,存在滞后效应;

最后由于采集代码常驻终端,不断将采集的用户行为数据进行记录和上报,对于终端尤其是移动终端来说还有耗电、消耗数据流量等负载,此外在数据上报传输的过程中也存在丢失数据的风险。

可视化埋点
由于代码埋点需要终端开发人员来执行采集方案,对业务的功能开发侵入性较高。有的公司开发出了可视化埋点技术,只需要产品与运营人员通过GUI界面进行鼠标简单点击,就可以随时增加、取消、调整采集数据的位置和方式,此种埋点方式避开了终端开发人员的介入,由需求人员直接执行采集,减轻了需求传递过程中的信息损耗和误解,另外可视化埋点技术往往由服务端直接下发采集的配置文件,而不用跟随版本发布,从而加快了数据采集的流程。

(有埋点需求,直接操作即可生效!不需要等版本上线才能发布埋点)。

无埋点
无埋点与可视化埋点原理基本一致,区别在于无埋点是先遍历所有的控件和操作行为的组合情况,然后将这些组合情况交给埋点后台,由数据分析人员选择对哪些组合的埋点数据进行分析,其优缺点如下:

优点:

收集数据全面,无漏报

缺点:

采集数据量巨大,增加了终端流量消耗和服务器存储负担。

埋点的上报时机相对呆板,不能灵活的根据特定的场景进行特殊设置

前端埋点的注意事项:
页面和控件标示上报要从顶层进行合理的设计,层次感要明显

前端埋点不仅可以处理不需要和服务器交互的曝光和点击事件,也可以将与服务器交互的结果,比如关注成功、分享成功、优惠券领取成功等原属于后端埋点里的事件放在前端来上报。

后端埋点:
后端埋点为了避免前端埋点的以下问题:

前端埋点需要对采集的数据压缩、暂存,为减少移动端的数据流量,除一些需要实时上报的重要事件不限制网络环境,其它事件一般只在wifi情况下上报,因此数据会有延迟,丢数据等弊端,而在后端采集数据,由于数据是在内网传输,数据传输的即时性强,丢失数据的风险小。

前端埋点采集程序由于需要常驻,监测实时和延迟埋点上报,不可避免的带来额外的耗电。

前端埋点若要新增或调整采集方案,需要开发人员修改客户端代码,然后发版之后才能解决,受发布周期的影响较大,而且通常用户的版本更新并不会及时,这将导致新方案不能及时覆盖所有用户。虽然现在部分埋点管理后台也支持热配置更新,但功能一般都很弱,只支持一些基础的埋点事件热更新部署,

注意:
很多时候并不把后端埋点独立出来,而是混合在前端埋点中,等用户和服务器端的交互返回结果之后,将结果进行上报。

对一下需要精确采集的数据,比如代金券发放等,实施的时候尽量采用后端埋点,除非后端无法采集到所需要的数据,前端埋点只是用来参考。此外也可以将业务数据库代金券领取数据同步到数据仓库中进行分析。

1.2 设置埋点的意义是什么:

所谓埋点就是在应用中特定的流程收集一些信息,用来跟踪应用使用的状况,后续用来进一步优化产品或是提供运营的数据支撑,包括访问数(Visits),访客数(Visitor),停留时长(Time On Site),页面浏览数(Page Views)和跳出率(Bounce Rate)。这样的信息收集可以大致分为两种:页面统计(track this virtual page view),统计操作行为(track this button by an event)

1.3 案例:


数据埋点形式和参数说明:

[{ //Part1:配置信息 "user_id":"123", //埋点负责人的账号id "business":"xx业务", //埋点数据的业务分类 "label":"标签属性",//对埋点数据进行分类,对每个分类打标签 //Part2:环境信息 "uid":"123", //用户唯一ID,只要访问就生成一个新的身份标示 "user_id":"123", //用户的账户ID,仅登录用户可获取得到 "name":"joker",//用户的账户名称,仅登录用户可获取得到 "city_id":"2",//如果用户访问的页面有城市属性,这里可以获取页面的城市属性id "city_name":"上海",//如果用户访问的页面有城市属性,这里可以获取页面的城市属性值 "locate_city_id":"1",//用户访问时候所定位的城市id "locate_city_name":"北京",//用户访问时候所定位的城市属性值 "wifi":"on",//用户访问时候wifi的开关状态 "app_version":"10.9.2",//用户当前使用的app版本 "os_version":"11.8.2", //用户当前手机系统的版本 "os_souce":"android" //用户当前的手机系统(Android,iPhone,小程序、web…) //Part3:事件信息 "evs":[{ "id":"a1234"//坑位模块的全app唯一标示id "val_val":{ //以下所有数据为同时携带的想要获取的数据内容 "user_id":"123", //访问用户的账号id; "content_id":"123234", //商品唯一id标示 "title":"conklab连帽潮牌oversize情侣装",//商品标题; "price":"298",//商品价格; "business_id":"4",//商品分类属性id "business":"女装",//商品分类属性 "strategy":"abc123",//不同策略的策略id,用于区分不同策略的数据效果 "shop_id":"123",//商品所属的店铺id "长情的白云":"双十一",//个性化的数据标签,比如双十一代表此商品正在参加双十一活动 "position":"2",//商品在列表中展示排序的第几个位置 } }]}]

埋点数据触发时间上报策略

1.露出上报采用实际展示曝光上报策略,只有当事件本身实际曝光显示在屏幕当中才需要触发上报策略进行数据上报(露出像素>0px);

滑动:在页面内上下滑动时,不重复记录;刷新:刷新当前页面时,重复记录曝光;翻页:下拉到新一页后再返回到前一页,上下滑动不重复记录返回:事件点击到落地页后,从落地页返回(包括返回按钮返回、滑动返回、支付等行为后自动跳转返回),不重复记录录曝光;唤醒:a) 手机锁屏被打开,直接展示事件所在的页面,不重复记录曝光;b) 应用或者浏览器在后台被唤醒,展示广告所在的页面,不重复记录曝光;

2.没有特殊限制定义,埋点需要根据坑位颗粒端逐条上报,不做去重处理;

备注:
1.数据埋点中的“点击事件”在触发“点击”动作的时候上报埋点数据,触发条件很明显,不容易有歧义,所以很少单独强调。
2.其他类似的滑动、编辑、订单键、加载触发条件,因为不是主流触发条件,我们在后续课程中单独介绍。

常用的站内数据埋点方式,适用于各种平台WEB、APP、小程序;

在案例1中我们很容易总结出数据埋点的数据分为三个重要组成部分:

数据埋点的业务配置信息
用户访问环境信息
数据埋点动作信息(事件信息)

用户访问我们的产品的时候,触发单个“动作”事件信息的时候,我们会记录用户的所在城市、客户端,APP版本,埋点ID,以及很多其他的参数。

通过长期的总结和经验及常识分析,我们会发现用户在一次会话访问中城市不会发生改变,只需获取一次即可,不必每次“动作”时间的出发重复的获取用户的地理位置计算一个所属城市。

因此我们优化一下数据的获取方式,将城市作为环境信息在一次会话中仅获取一次,后在加工处理数据的时候将一次会话内的所有“动作”事件信息补全它所属的城市场景。

同样道理类推,我们会发现不仅城市拥有这个规律和常识,用户的wifi,APP版本,登录账号,手机系统,手机品牌的等等属性都是类似的,所以,我们将其统一归为环境数据信息,在一次会话中仅收集获取一次(特殊的业务场景除外,比如定位信息可能主动、被动的多次触发)。

和环境信息比较类似的是业务信息,我们在通过工具或者各种记事本管理数据埋点的时候,我们对埋点的业务定义已经明确,比如埋点数据的事件id,我们很清楚的知道它是谁负责的,中文名称是什么,所以我们在用户访问产品,触发埋点的时候完全可以选择不上报这部分数据,从而减少数据上报量。等我们将埋点数据收集采集到数据库的时候,同我们已知的明确的定义信息进行一次关联即可。

1.3.2 案例2:
假设我们有网址:https://www.xxxabc.com/about/1.html(运营促销活动),我们针对这个活动在某网站投放广告引流,最有效的数据埋点方法是对URL添加埋点参数如下:

例如:运营促销活动的URL添加参数如下:
https://www.xxxabc.com/about/1.html?source=sina_joker_ad_about_01

参数说明:

?:问号后面是我们的埋点参数,以问号分割的作用是不影响正常的访问链接source:埋点字段的命名,source表示参数的名字,—source后面是参数的值sina:表示来源的渠道,如果是sohu,那么这里是搜狐即可joker:表示来源渠道的负责人ad:表示为广告类型,这里以ad表示一类广告about:表示对应的是此次about这个活动01:如果我们对这个资源位做了很多不同的广告图片素材,我们可以对素材编号为01,02……

常用的站外,站内数埋点方式,多用于WEB、小程序平台;

案例2本身通俗易懂,重点就是在于将参数安排在URL中,通过收集访问的URL日志来解析我们希望获取的埋点信息。

案例2可以延伸出很多种不同的数据埋点方式,以上述埋点的参数为例,我们也可以将其在进行一次整合优化。

比如:

运营促销活动的URL添加参数如下:
https://www.xxxabc.com/about/1.html?source=sina_joker_ad_about_01

修改为:

运营促销活动的URL添加参数如下:
https://www.xxxabc.com/about/1.html?source=abc123

备注:abc123=sina_joker_ad_about_01的含义可以维护在工具或者其他地方,这样就避免了URL过长,参数过多的数据现象。

**1.3.3 案例3: **
story长情的白云: //业务场景标示,可以对应到不同的业务类型场景

“key1:”value" //页面跳转的时候传递的参数,采用key:value的形式写入参数值“key2:”value” //保留尽可能多的keyxid,写入更多参数值“key3:”value" //保留尽可能多的keyxid,写入更多参数值

数据触发上报说明:

我们希望统计浏览小视频的来源入口,比如通过首页的“搜索”还是“关注”进来的。我们需要在做如下2件事情。

1.当用户通过“搜索”进行内容筛选查找小视频的时候,在触发搜索任务的时候上报如下埋点数据。
story长情的白云: //业务场景标示,可以对应到不同的业务类型场景

“index:”search" //key(index)定义为是首页,value(search)标示是来自搜索功能
“content:”曾经的电源" //key(conten)定义的是携带的内容参数,value(曾经的电源)标示内容参数
2.当用户向下访问的时候,尤其是在到达“浏览小视频”目标页的时候,触发上报埋点参数。

同样原理类推如果想统计通过“关注”到达浏览小视频的目标页,埋点数据如下:
story长情的白云: //业务场景标示,可以对应到不同的业务类型场景

“index:”guanzhu" //key(index)定义为是首页,value(guanzhu)标示是来自guanzhu功能“content:”guanzhu" //key(conten)定义的是携带的内容参数,value(guanzhu)标示内容参数

备注:
1.“关注”的埋点参数“content:”guanzhu" ,vlaue可以为空(“content:”“ )
2.这种埋点有很严格和复杂的”抹除“逻辑,需要有很强的层级概念,比如用户通过”搜索“进入结果页但是未能再进一步,选择返回首页通过”关注“最终到达”浏览小视频“目标页,那么”搜索”相关的参数需要在“回退”的时候抹除,写出最新的“关注”埋点参数。

数据埋点中的一种透传方案,主要用于统计站内的来源入口,适用于WEB、APP、小程序。

案例3我在前面已经举例,这里在和大家针对一个数据问题埋个伏笔:

统计 x 页面的来源,统计 x 页面的分类 ,统计用户的访问路径。这是不同的数据概念模型,且依赖的数据埋点方案会存在差异。

汇总在vue中写jsx的方式iOS中多线程的经典崩溃总结大全分布式版Redis架构 云内存 UMem Redis
安卓埋点技术,android全埋点解决方案pdf 数据埋点分为几种方式,数据埋点设计
相关内容