H5通用分析模型旨在通过规范化埋点设计方案，开发设计一套通用度高，扩展方便，需求响应迅速的模型，减少行业数据产品和开发在类似需求上的人力投入，提升数据分析效率。
图（1）应用生命周期内指标分析情况
2.2.1分析模型主题
本次通用分析模型围绕以下分析主题构建。
2.2.2分析指标定义
（以下示例中数据均为参考数据，非真实数据）
1、基础分析：访问pv，uv等指标（全维度）
注：用户对访问页面进行命名，分析平台提供配置入口，方便用户对页面进行命名。
3、留存分析：新用户留存，活跃用户留存包括：N日内留存和第N日留存。
通常意义上的留存分析指的是：用户在APP产生行为后，在固定的第N日继续访问或使用APP的用户；包括活跃用户留存和新用户留存
为满足不同业务的分析需求。此次留存模型包含n日内留存分析，即用户在APP产生行为后，在固定的第N日内继续访问或使用APP的用户（日期范围留存）。
3.1业务目标
3.2.1什么是自动采集
3.2.2如何自动采集
3.2.3自动采集的三大规则场景
我们的网站是一个SPA应用。SPA应用通过改变前端路由的变化，实现页面内组件的切换。组件的切换，对于一个非前端开发者来说，可以泛指页面的切换。所以我们第一场景是要覆盖url变化的这类事件。在实践中，我们发现，当我们需要采集页面的用户停留时长时，往往会不准确。为什么不准确？用户可以缩小化浏览器，也可以切换tab到其他网站，这个时候计算的用户时长是不准确的。因为用户虽然打开了我们网页，但是并没有聚焦到我们的网页。这种不应该算作用户停留时长，因此对于这些行为，我们又加上了失去焦点，得到焦点，以及切换浏览器tab事件的EventListener，这两种场景。
综上三大场景总结如下：
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
引入JSSDK
functionresetHistoryFun(type){//将原先的方法复制出来letoriginMethod=window.history[type]//当window.history[type]函数被执行时，这个return出来的函数就会被执行returnfunction(){//执行原先的方法letrs=originMethod.apply(this,arguments)//然后自定义事件lete=newEvent(type.toLocaleLowerCase())//将原先函数的参数绑定到自定义的事件上去，原先的是没有的e.arguments=arguments//然后用window.dispatchEvent()主动触发window.dispatchEvent(e)returnrs;}}window.history.pushState=resetHistoryFun('pushState')//覆盖原来的pushState方法window.history.replaceState=resetHistoryFun('replaceState')//覆盖原来的replaceState方法window.addEventListener('pushstate',reportBothEvent)window.addEventListener('replacestate',reportBothEvent)（2）规则二界定——怎么判断页面失去焦点，得到焦点？
失去焦点，得到焦点。我们主要进行如下这两个事件的EventListener：
window.addEventListener('focus',()=>{console.log('页面得到焦点')});window.addEventListener('blur',()=>{console.log('页面失去焦点')})（3）规则三界定——怎么判断浏览器tab切换离开，切换回来？
tab切换离开，切换回来。我们主要进行如下这一个事件的EventListener：
document.addEventListener('visibilitychange',()=>{if(document.hidden){console.log('页面离开')}else{console.log('页面进入')}})注意：如果一个行为同时满足2个及2个以上的规则时，只会取一个规则上报数据。避免不重复上报数据。
3.3.1埋点个数
为什么要设计2个埋点？设计2个埋点，能覆盖全面上述我们所说的3种规则场景；其次，方面计算页面停留时长；最后就是方便逻辑判断，避免重复上报；
3.3.2参数的设计
按照不同的需求，参数的设计分为如下4类：
数据上报方式是XMLHttpRequest、window.navigator.sendBeacon，基于h5sdk上报逻辑架构。
图（4）
关于兼容性，依赖于window对象、不兼容IE6、IE7，IE8;
关于容错性，对通用化内部逻辑做了trycatch的容错兼容，保证出错时不影响业务主逻辑运行，同时上报一个出错的事件类型，知道出错的原因，以便提前做好对应的优化方案。
埋点方案已经具备，接下来的工作就是设计一套接入高效，拓展便捷的数仓分析模型；为实现以上既定的分析目标，模型设计过程中需要解决以下核心问题。
介绍模型设计前，先说下vivo数仓模型分层基本原则，及本次模型分层思路，各层模型设计原则参照《vivo中台数仓建设方法论》，层级设计摘要如下：
通过核心问题拆解发现，为实现通用分析模型方案，需要从数据接入层收口，在数据接入时统一参数解析，统一字段命名，并设置相应的应用id字段，区分各个业务数据源；接着需要生成活跃数据明细表，可统计相应的基础分析，页面分析指标；同时为满足留存分析的需要，我们需要构建相应的活跃全量表，留存分析主题表基于活跃增量表和活跃全量表生成，用户活跃信息通过打标签的方式标记。至此涉及三个主题分析的模型规划完毕。层级划分原则及规划逻辑模型明细，如：图（5）
图（5）
从分层架构图可看出H5通用分析模型分为明细层(dw)、轻度汇总层(dma)、分析主题表(dmt)和指标层(da);其中轻度汇总层可作为中间数据提供行业分析师及数据开发、业务产品等查询分析使用；汇总层作为分析平台通用分析模型报表数据源，导入mysql存储，前端基于mysql表实现数据展示,各个模型设计细则如下：
数据模型规划及设计的核心在于三点：确定appid和用户id映射关系，留存方案实现及留存记录入库bitmap方式读写。
1、确定appid和用户id映射关系-unique_id关联设计
多业务id统一
留存方案
数据流图如下：
图（6）
模型数据展示可基于用户行为分析平台，数据指标存储使用MySQL数据库，数据展示逻辑实现如下：
图（7）
图（8）应用概况报表
图（9）用户留存报表
图（10）页面分析报表
所以，为更好的支撑业务目标达成，H5通用分析模型系列在后期会根据业务诉求落地相应的分析模型，持续为产品运营提供高效稳定的数据解决方案。