H5内容有效阅读时长和有效阅读屏数的分析策略

见贤思齐

H5内容有效阅读时长和有效阅读屏数的分析策略 H5内容有效阅读时长和有效阅读屏数的分析策略 杨秀武 贝壳产品技术 贝壳产品技术 “贝壳产品技术公众号”作为贝壳官方产品技术号，致力打造贝壳产品、技术干货分享平台，面向互联网/O2O开发/产品从业者，每周推送优质产品技术文章、技术沙龙活动及招聘信息等。欢迎大家关注我们。 242篇内容 2022年04月08日 09:34 1、背景介绍有效阅读时长和有效阅读屏数是分析内容质量的两个重要指标，一篇优质的内容理论上应该是被认真地阅读完成，产生的数据应该是在较合适的时间内完成高屏数的阅读。如果在短时间内阅读屏数非常高，则说明用户在刷数据或者对内容不感兴趣，随手滑，无法吸引眼球，从而说明当前内容质量差，需要进行更新，迭代，以更好的满足用户诉求，推动用户对APP内容有足够的兴趣和粘性。2、公式分析那么如何收集这些数据，对收集的用户数据如何分析？通过分析结果来赋能业务做内容质量上的优化，首先来看两个公式：2.1 公式A --- 有效阅读时长阅读时长的定义为对某篇内容从开始阅读到结束阅读的时间差。不过在当代手机环境下，APP在生命周期内是可以切后台运行的，那么切到后台的时间理论上来说是不属于有效阅读时间内，需要减掉。有效阅读时长则需要去掉阅读期间的暂停阅读的时长。2.1.1 方案1有效阅读时长(S) = (停止阅读时间戳 - 开始阅读时间戳) / 1000 - N次数 * 暂停阅读时长。但是有个问题，如何能在切后台以及停止阅读的时候获取到开始阅读时间呢？需要自己手动存储，并且需要记录计算，自然增加了变量的维护成本和测试成本。另外，还有一个更重要的可见性误差，即非正常停止阅读的时长统计全部丢失，这个错误严重地影响了该指标的可信性。2.1.2 方案2换一种过程式的思考方式：是否可以把阅读时间给碎片化，只考虑每一个有效的阅读时长，把碎片化的数据上报，在分析的时候再加工成完整的有效阅读时长呢？答案是肯定的，根据时间碎片化思路，公式变为：有效阅读时长(S) = ((切后台时间戳 - 开始阅读时间戳) + (切后台时间戳 - 切前台时间戳) * N次数 + (停止阅读时间戳 - 切前台时间戳)) / 1000。其中：次数为切后台再切前台的周期次数。2.2 公式B --- 有效阅读屏数有效阅读屏数 = 向上取整函数(页面最高点移动距离 / 屏幕高度尺寸)；这个在离开页面之前计算并且上报即可。如果APP切到后台再也没切回来继续运行，或者直接杀死进程，显然是会丢数据的，会严重地影响了该指标的可信性，故方案应该调整为在切后台的时候增加一次数据的兜底上报，之后再分析去重，以免拉低阅读屏数的平均值。（PS：为啥拉低阅读屏数平均值？来做一个假设：开始阅读，第一次切后台阅读到第2屏，上报数据，第二次切后台阅读到第3屏，上报数据，结束阅读到第5屏，上报数据，这样看来会上报三次阅读屏数，但是有效阅读屏数只有最后一次，也就是本次阅读有效阅读屏数为5，如果不去掉其余的两次，显然会拉低阅读屏数的平均值。）3、事件分析通过以上对数据公式的分析，我们可以设计出APP的相关事件：其一：web容器页面的开始显示事件，定义为事件A，对应时间戳为：Atime；其二：APP切到后台的事件（被挂起），定义为事件B，对应时间戳为：Btime；其三：APP切到前台的事件（被激活），定义为事件C，对应时间戳为：Ctime；其四：web容器页面的开始消失事件，定义为事件D，对应时间戳为：Dtime；基于这四个事件和上面两个公式(A/B)来计算出对应的两个数据。有效阅读时长 = ((Btime - Atime) / 1000 + (Btime - Ctime) / 1000 * N次数 + (Dtime - Ctime) / 1000) （其中：次数为切后台再切前台的周期次数）。有效阅读屏数 = 向上取整(页面最高点移动距离 / 屏幕高度尺寸)因【有效阅读时长】公式稍微复杂，故举个例子说明：步骤一：打开APP中某个H5页面，开始阅读取【事件A】，时间戳为Atime（1637771479000），收到其他APP的PUSH消息，切当前APP到后台，取【事件B】，时间戳为Btime（1637771499000），此时上报第一片阅读时间碎片(Btime - Atime) / 1000，20S；步骤二：处理完其他APP消息继续阅读，需要切回APP到前台，取【事件C】，时间戳为Ctime（1637771519000），阅读一段时间后，再次收到其他APP的PUSH消息，切当前APP到后台，取【事件B】，时间戳为Btime（1637771539000），此时上报第二片阅读时间碎片(Btime - Ctime) / 1000，20S；步骤三：处理完其他APP消息继续阅读，需要切回APP到前台，取【事件C】，时间戳为Ctime（1637771559000），阅读一段时间后，再次收到其他APP的PUSH消息，切当前APP到后台，取【事件B】，时间戳为Btime（1637771579000），此时上报第三片阅读时间碎片(Btime - Ctime) / 1000，20S；步骤四：2和3的过程可以是N次；即上报N片阅读时间碎片(Btime - Ctime) / 1000；步骤五：处理完其他APP消息继续阅读，需要切回APP到前台，取【事件C】，时间戳为Ctime（1637771599000），阅读一段时间后，跳转其他页面或者关闭H5页面，取【事件D】，时间戳为Dtime（1637771619000），此时上报第N+4片阅读时间碎片(Dtime - Ctime) / 1000，20S；步骤六：完成本次有效阅读。4、上报时机从公式上可以分析得出，切前台时间就是碎片时间的开始阅读的时间戳，埋点上报在切后台和停止阅读事件上；而阅读屏数恰好也需要在这两个事件中上报数据，故而两个指标可以埋在同一个请求中。5、解决问题按照公式A和B以及上述算法，在关键节点上把当时计算的数据进行上报，但是这样就会出现几个问题：5.1、如何把上报的碎片时间数据做累加，得到最终的有效阅读时长？此时就需要一个有效阅读周期内的唯一标识，把时间碎片串到一起，该标识存成全局变量，放在每次埋点上报中，且只能在开始阅读即【事件A】中重置该标识，强调一下不能在【事件C】中重置该标识是因为APP切换是在一个有效阅读周期内，所以埋点上报的信息就必须要包括参数1：有效阅读时长碎片，dura参数2：阅读屏数，screen参数3：有效阅读周期内的唯一标识，uuid即action:{dura:20,screen:4,uuid:“UFD6N3KI7LP”}有效阅读时长 = 同一uuid的dura加和。把埋点中uuid为 “UFD6N3KI7LP” 的筛出来，dura做累加即为该阅读周期内（标识UFD6N3KI7LP）的有效阅读时长。5.2 如何去掉因兜底而上报的多余阅读屏数，以增加数据的准确性？按照上面的三个值是没有办法区分事件类型的，所以需要另外一个标识：埋点上报的时机，即切后台事件还是停止阅读事件上报：参数4：埋点上报的时机，切后台(disappear)/停止阅读(stop)即埋点一：action:{dura:20,screen:4,uuid:“UFD6N3KI7LP”status:“事件B”}埋点二：action:{dura:30,screen:9,uuid:“UFD6N3KI7LP”status:“事件B”}埋点三：action:{dura:30,screen:8,uuid:“UFD6N3KI7LP”status:“事件D”}有效阅读屏数 =case 1、如果有埋点一，埋点二，埋点三，那么同一uuid不区分status的screen值较大的埋点数据，其他值舍去；即对比所有埋点screen之后，取埋点二，阅读屏数为9。case 2、如果只有有埋点一，埋点二，那么说明没有上报停止阅读的埋点，则取事件B埋点里的screen，取screen较大的埋点数据，其他值舍去；取埋点二，阅读屏数为9。根据以上两个case可以得出，同一uuid不区分status的最大screen值即为有效阅读屏数。6、分析总结综上所述，通过以上分析过程，H5内容的有效阅读时长和有效阅读屏数就被收集，分析和计算出来了。不过只是理论上的分析和计算，那么如何才能让运营同事等相关人员查看到对应的指标数据呢？答案是可视化看板。由于涉及到奥丁的配置，不在本文赘述，有兴趣的可以线下交流，其思路就是：通过SQL的碎片聚合，产生有效的业务表，最终通过一定的配置落到某看板即可。 预览时标签不可点 大前端69大前端 · 目录#大前端上一篇前端构建工具Vite初探下一篇精品化组件｜全局运营浮层关闭更多小程序广告搜索「undefined」网络结果