文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

用户行为分析模型实践(三)——H5通用分析模型

2024-12-13 15:25

关注

现阶段H5埋点的自由度较高,行业数据产品在同类高频的业务场景上设计的时间花费较多,埋点开发、埋点测试等事项耗时,且需重复劳动;同样的埋点数据分析层面-基础分析指标,留存指标,页面分析等需求需多次开发模型,浪费宝贵的人力资源。

H5通用分析模型旨在通过规范化埋点设计方案,开发设计一套通用度高,扩展方便,需求响应迅速的模型,减少行业数据产品和开发在类似需求上的人力投入,提升数据分析效率。

二、分析模型概述

2.1 术语解释

2.2 模型概述

针对业务发展的不同阶段,会有相应的数据分析需求。如图(1),在业务初期,用户的访问,留存情况等是阶段性分析重点,业务产品运营可以根据分析数据适时的调整页面布局,运营策略等;应用发展中后期可能会更多的关注订单、转化、路径等相关分析指标。如果能在应用上线之初,快速的拿到核心分析指标数据,对产品的推广,迭代无疑是收益良多。所以,本次模型构建从应用初期分析最广泛的核心指标出发,落地应用概况、页面访问、用户留存等维度全方位核心分析指标体系。


图(1)应用生命周期内指标分析情况


2.2.1 分析模型主题

本次通用分析模型围绕以下分析主题构建。

2.2.2 分析指标定义

(以下示例中数据均为参考数据,非真实数据)

1、基础分析:访问pv,uv等指标(全维度)


2、页面分析:页面访问相关pv,uv,时长等指标

注:用户对访问页面进行命名,分析平台提供配置入口,方便用户对页面进行命名。

3、留存分析:新用户留存,活跃用户留存  包括:N日内留存 和 第N日留存。

通常意义上的留存分析指的是:用户在APP产生行为后,在固定的第N日继续访问或使用APP的用户;包括活跃用户留存和新用户留存

为满足不同业务的分析需求。此次留存模型包含 n日内留存分析,即用户在APP产生行为后,在固定的第N日内继续访问或使用APP的用户(日期范围留存)。


三、埋点方案

3.1 业务目标

3.2 自动采集

3.2.1 什么是自动采集

自动采集是相对于前端开发者而言,目的是为了帮助前端开发者提升数据采集效率。通过自动采集开关配置,无需在手动实现上报逻辑。使用时前端开发者通过引入h5sdk.js(也称jssdk.js),打开自动采集开关,我们就会在适当的时机,以适当的规则采集数据,并进行上报。开发者无需在关注采集代码内部逻辑,以此来减轻同类数据采集的开发工作量。

3.2.2 如何自动采集

按照给定的规则进行页面事件EventListener,当用户活动触发对应的事件时,我们会组装好数据,然后将组装好的数据通过https传入到后台。

3.2.3 自动采集的三大规则场景

我们的网站是一个SPA应用。SPA应用通过改变前端路由的变化,实现页面内组件的切换。组件的切换,对于一个非前端开发者来说,可以泛指页面的切换。所以我们第一场景是要覆盖url变化的这类事件。在实践中,我们发现,当我们需要采集页面的用户停留时长时,往往会不准确。为什么不准确?用户可以缩小化浏览器,也可以切换tab到其他网站,这个时候计算的用户时长是不准确的。因为用户虽然打开了我们网页,但是并没有聚焦到我们的网页。这种不应该算作用户停留时长,因此对于这些行为,我们又加上了失去焦点,得到焦点,以及切换浏览器tab事件的EventListener,这两种场景。

综上三大场景总结如下:

  1. 页面切换时,进行采集,即url变化时触发的事件;
  2. 页面失去焦点,得到焦点时,进行采集。即focus,blur事件;
  3. 页面通过浏览器tab切换离开,切换回来时,进行采集,即visibilitychange事件;

3.2.3.1 三大规则场景的界定

上文我们已经在实践中总结出了自动采集的三大场景,在实际应用针对三大场景的使用我们也总结出了一套界定方案。

(1)规则一界定——怎么判断页面切换?

a、现在的网站要么是MPA,要么是SPA模式,或者两种模式混合,MPA主要是后台路由,SPA主要是前端路由(hash模式和history模式)。但无论是SPA还是MPA,当页面需要切换时,url一定会变化,基于此点,我们判断当url变化时,用户一定切换了页面。此时触发规则一的事件,产生数据上报。

这里需要注意2个问题:


图(2)


b、完整页面切换上报流程,由页面A切换到页面B时,一共上报4个埋点;

图(3)


c、关于路由的EventListener

现在的大多网站,大多是SPA应用,SPA的前端路由有hash模式和history模式这两种模式,当通过前端路由来页面切换时,肯定会触发hash模式或history相关的api。

因此,我们只需要把所有触发事件的场景给全部进行EventListener即可。有如下2种路由的EventListener:window.hashchange事件——触发hash模式时、window.popstate事件、pushstate,replacestate自定义事件——触发history模式时。

这里有2个问题需要关注:一是当某个SPA应用的路由事件,触发了history模式时,我们应该移除hash模式的EventListener。二是pushstate,replacestate自定义事件,因为BOM并没有提供相关的api支持EventListener,需要自行封装使用,如下code。

引入JSSDK


function resetHistoryFun(type){
// 将原先的方法复制出来
let originMethod = window.history[type]
// 当window.history[type]函数被执行时,这个return出来的函数就会被执行
return function(){
// 执行原先的方法
let rs = originMethod.apply(this, arguments)
// 然后自定义事件
let e = new Event(type.toLocaleLowerCase())
// 将原先函数的参数绑定到自定义的事件上去,原先的是没有的
e.arguments = arguments
// 然后用window.dispatchEvent()主动触发
window.dispatchEvent(e)
return rs;
}
}
window.history.pushState = resetHistoryFun('pushState') // 覆盖原来的pushState方法
window.history.replaceState = resetHistoryFun('replaceState') // 覆盖原来的replaceState方法


window.addEventListener('pushstate', reportBothEvent)
window.addEventListener('replacestate', reportBothEvent)

(2)规则二界定——怎么判断页面失去焦点,得到焦点?

失去焦点,得到焦点。我们主要进行如下这两个事件的EventListener:

引入JSSDK

window.addEventListener('focus', ()=>{
console.log('页面得到焦点')
});


window.addEventListener('blur', ()=>{
console.log('页面失去焦点')
})

(3)规则三界定——怎么判断浏览器tab切换离开,切换回来?

tab切换离开,切换回来。我们主要进行如下这一个事件的EventListener:

引入JSSDK

document.addEventListener('visibilitychange',  () => {
if(document.hidden) {
console.log('页面离开')
} else {
console.log('页面进入')
}
})

注意:如果一个行为同时满足2个及2个以上的规则时,只会取一个规则上报数据。避免不重复上报数据。

3.3 埋点设计

3.3.1 埋点个数

为了得到pv和uv的相关数据,我们设计了2个埋点,1个为页面进入时上报的埋点,另外1个为页面离开时的埋点,上报的数据都是一对的,离开-进入页面为一对,失去焦点-得到焦点为一对,切换tab离开当前页面-返回当前页面也为一对;

为什么要设计2个埋点?设计2个埋点,能覆盖全面上述我们所说的3种规则场景;其次,方面计算页面停留时长;最后就是方便逻辑判断,避免重复上报;

3.3.2 参数的设计

按照不同的需求,参数的设计分为如下4类:

3.4 数据上报

数据上报方式是XMLHttpRequest、window.navigator.sendBeacon,基于h5sdk上报逻辑架构。

图(4)


3.5 兼容性和容错性

关于兼容性,依赖于window对象、不兼容IE6、IE7,IE8;

关于容错性,对通用化内部逻辑做了try catch的容错兼容,保证出错时不影响业务主逻辑运行,同时上报一个出错的事件类型,知道出错的原因,以便提前做好对应的优化方案。

3.6 个人数据保护合规

为了保护好用户的个人数据及其隐私并满足法律法规要求,在埋点的设计、采集、使用等环节需要进行充分的隐私保护设计。例如,在埋点设计阶段,需要确定标识符的选择、埋点参数的最小必要、采集频率的最小必要等;在埋点的采集、使用阶段,需要确保相关处理行为的透明、可控,包括对用户进行告知,获取用户的有效同意,提供撤回同意的渠道等等。

四、数仓方案

埋点方案已经具备,接下来的工作就是设计一套接入高效,拓展便捷的数仓分析模型;为实现以上既定的分析目标,模型设计过程中需要解决以下核心问题。

4.1 核心问题列表


4.2 模型分层标准

介绍模型设计前,先说下vivo 数仓模型分层基本原则,及本次模型分层思路,各层模型设计原则参照《vivo中台数仓建设方法论》,层级设计摘要如下:

4.3 模型层级架构

通过核心问题拆解发现,为实现通用分析模型方案,需要从数据接入层收口,在数据接入时统一参数解析,统一字段命名,并设置相应的应用id字段,区分各个业务数据源;接着需要生成活跃数据明细表,可统计相应的基础分析,页面分析指标;同时为满足留存分析的需要,我们需要构建相应的活跃全量表,留存分析主题表基于活跃增量表和活跃全量表生成,用户活跃信息通过打标签的方式标记。至此涉及三个主题分析的模型规划完毕。层级划分原则及规划逻辑模型明细,如:图(5)


图(5)

从分层架构图可看出H5通用分析模型分为明细层(dw)、轻度汇总层(dma)、分析主题表 (dmt) 和指标层(da); 其中轻度汇总层可作为中间数据提供行业分析师及数据开发、业务产品等查询分析使用;汇总层作为分析平台通用分析模型报表数据源,导入mysql存储,前端基于mysql表实现数据展示,各个模型设计细则如下:

数据模型规划及设计的核心在于三点:确定appid和用户id映射关系,留存方案实现及留存记录入库bitmap方式读写。

1、确定appid和用户id映射关系-unique_id 关联设计

多业务id统一

## 明细层收口数据,统一id字段
SELECT xx
,xx1
,CASE WHEN appid IN(1) THEN 1
WHEN appid IN(2) THEN 2
WHEN appid IN(3) THEN 3
WHEN appid IN(4,5,6,...) THEN 4
ELSE 0 END AS id_flag
,CASE WHEN appid IN(1) THEN id1
WHEN appid IN(2) THEN id2
WHEN appid IN(3) THEN id3
WHEN appid IN(4,5,6,...) THEN IF(NVL(params['id1'],'')='',NVL(params['id2'],'NA'),params['id1'])
ELSE 'NA' END AS unique_id
,appid
FROM ods_table_name_XXX a -- 各个接入业务线数据源 ods
WHERE day='${today}'
AND hour = '${etl_hour}'
-- APPID 事件id 要匹配新增
AND appid in (1,2,3 ...)
AND 事件id in (XXX|167,XXX|168,...);


## id字段后续关联使用方式
## 增量关联全量,确定是否新用户
SELECT if(b.unique_id is null,1,0) AS is_new
FROM
(
SELECT *
FROM table_XXX_hi
WHERE day= '${today}'
AND hour = '${etl_hour}'
GROUP BY XX
) a
-- 取全量表唯一 unique_id 作为关联条件,判断新老用户
-- 新用户是相对于历史全量的
LEFT JOIN ( SELECT unique_id,appid
FROM
( SELECT unique_id
,appid
,row_number() over(partition by unique_id,appid order by 活跃日期 asc) as rn_0
FROM table_XXX_df
WHERE day='${etl_date}'
) a
WHERE rn_0 = 1
) b
ON a.unique_id = b.unique_id AND a.appid = b.appid;

2、留存方案实现及留存记录入库bitmap方式读写

留存方案

## 利用bitmap思想,留存标签满8位转化为16进制组合到retain_tag之前,这样可以利用很少的位数记录较长的活跃情况
## 示例代码如下
SELECT user_unique_id
,if(length(tmp_retain_tag) = 8,is_active,concat(is_active,tmp_retain_tag)) as tmp_retain_tag
-- 如果tmp_retain_tag长度为8的时候,将数据转化为十六进制添加到retain_tag前,并将本字段清空,从头开始计数
,if(length(tmp_retain_tag) = 8,concat(con_tmp_retain_tag,retain_tag),retain_tag) as retain_tag
,is_active
FROM
(
SELECT unique_id
-- 前一天的临时存储,与con_tmp_retain_tag保持一致
,tmp_retain_tag
-- 如果转换为十六进制后的长度不为2,则在左边添加0
,if(length(conv(tmp_retain_tag,2,16)) = 2,conv(tmp_retain_tag,2,16),concat('0',conv(tmp_retain_tag,2,16))) as con_tmp_retain_tag
-- 历史轨迹
,retain_tag
,first_value(is_active) over(partition by unique_id,appid,topic_id order by first_active_day desc) as is_active
FROM
( SELECT unique_id
,topic_id
,appid
,first_active_day
,last_active_day
-- 留存标签
,'0' as is_active
,tmp_retain_tag -- 形如 11101010
,retain_tag -- 形如 A0E3
FROM table_active_XX_df -- 活跃全量表
WHERE day= '${last_etl_date}'
UNION ALL
SELECT unique_id
,topic_id
,appid
,day as first_active_day
,day as last_active_day
-- 留存标签
,'1' as is_active
,'' as tmp_retain_tag
,'' as retain_tag
FROM table_active_XX_hi -- 活跃明细表
WHERE day= '${etl_date}'
) a
) b
WHERE rn =1;


## 留存指标统计:## 以3日内及第3日留存为例
WITH tmp_table AS (
SELECT DAY
,unique_id
,appid
,首次活跃日期
,CONCAT(tmp_retain_tag,retain_tag) AS login_trace
FROM (
SELECT DAY
,unique_id
,tmp_retain_tag
,appid
,首次活跃日期
,IF(nvl(retain_tag,'') <> '',CONV(SUBSTR(retain_tag,1,8),16,2),'') AS retain_tag
-- 如果retain_tag为空时,直接取空值。如果长度超过8位数,取最后八位数;如果长度不超过8位数,取全部。如果是30日内新用户,长度不超过8位
FROM table_active_XX_df WHERE DAY = 统计日
) x1
)
## 以3日内及第3日留存为例:
SELECT -- 第N日留存指标:第N日来访
,SUM(IF(SUBSTR(login_trace,3,1) = '1',1,null)) AS retain_cnt_3th
-- N日内留存指标:N日内访问过1次或N次
,SUM(IF(instr(SUBSTR(login_trace,2,2) ,'1')= 0,null,1)) AS retain_cnt_between_3th
FROM (
SELECT '统计日-2天' AS dt
,unique_id
,REVERSE(SUBSTR(login_trace,1,3)) AS login_trace
,appid
FROM tmp_table WHERE SUBSTR(login_trace,3,1) = '1' AND 首次活跃日期 = 统计日-2
) X GROUP BY dt,appid;

4.4 模型数据流图

至此,模型的设计落地全部完成,模型包含埋点数据表2张,dw明细层模型1张,维表1张,dma轻度汇总主题层2张,dmt主题表2张,任务层深4层,模型层2层,模型数据接入0.5人日可完成。

数据流图如下:

图(6)


五、数据展示

模型数据展示可基于用户行为分析平台,数据指标存储使用 MySQL 数据库,数据展示逻辑实现如下:

图(7)

5.1 报表展示

报表配置完成后,各个分析模块的前台展示示例如下:

图(8)应用概况报表


图(9)用户留存报表


图(10)页面分析报表


六、未来展望

至此,H5通用分模型落地流程已介绍完毕。本文主要是基于业务初期诉求,快速落地通用的、统一的数据解决方案,满足业务分析人员在产品初期最迫切的分析需求。随着业务的不断发展迭代,运营产品的分析方向也会不断的扩展和深入,同时不同的业务关注点不同,针对分析模型的诉求也不尽相同。例如在业务中后期,简单的访问留存分析已经支撑不了更进一步的决策制定,此时针对页面访问的路径分析模型;针对营销分析的订单转化模型、归因分析模型;针对页面跳转分析的用户漏斗模型等需求会相应变多。

所以,为更好的支撑业务目标达成,H5通用分析模型系列在后期会根据业务诉求落地相应的分析模型,持续为产品运营提供高效稳定的数据解决方案。

来源:vivo互联网技术内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯