H5 內容有效閱讀時長和有效閱讀屏數的分析策略
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 的碎片聚合，產生有效的業務表，最終通過一定的配置落到某看板即可。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8ty8pGrl__xdres7gLF56w