深度干货 | 多维分析中的 UV 与 PV
1. 概念
1.1 UV 與 PV
對于互聯(lián)網(wǎng)產(chǎn)品來說,UV 與 PV 是兩個非常常見的指標,并且通常都是分析的最基礎指標。UV 一般來講,是指使用產(chǎn)品(或產(chǎn)品某個功能)的獨立用戶數(shù)。PV 則來源于網(wǎng)站時代,一般指網(wǎng)站(或網(wǎng)站某個頁面)的頁面瀏覽量,在移動互聯(lián)網(wǎng)時代,則一般會引申表示使用產(chǎn)品(或產(chǎn)品某個功能)的用戶行為或者用戶操作數(shù)量。
PV 和 UV 一般而言是互相影響,一起變化的,對于 PV 和 UV 的變化與數(shù)字的解讀,也是一門很深的學問。由于本文主要是介紹在多維分析中 UV 和 PV 的計算規(guī)則,所以,對于 PV 和 UV 的具體解讀與分析,不做展開論述。
1.2 多維分析
多維分析是在 BI(Business Intelligence)領域廣泛使用的一種分析技術和分析方法,能夠從不同的角度,靈活動態(tài)地進行分析。
多維分析中有“指標”和“維度”兩個基本概念,在這里,我們用一個實際的例子來進行描述。
一個典型的網(wǎng)站,它可能需要從地域、終端、App 版本這三個角度,來考察自己的 PV 和 UV 的情況。那么,在這個場景下,維度有三個,分別是地域、終端和 App 版本;指標則是兩個,分別是 PV 和 UV。所謂的多維分析,就是可以在維度的任意組合情況下,來看對應的指標的數(shù)值:可以看北京的,iOS端的,7.1 版 App 的 PV 和 UV;也可以看湖北的安卓端的 PV 和 UV;也可以看 7.2 版 App 的 PV 和 UV。具體設置查詢條件的時候,維度可以是三個,可以是兩個,也可以是一個。從這個例子可以看出,多維分析是非常靈活的,具有很強的分析能力,可以充分滿足分析人員對于產(chǎn)品的各種細粒度的分析需求。
而為了能夠讓多維分析發(fā)揮出更大的價值,一般情況下,都是希望多維分析的查詢結果能夠在一分鐘能就得到,從而可以讓使用者不停地調整查詢條件,快速地驗證自己的猜想。
2. “可加”與“不可加”
正如上面提到的,多維分析對于查詢速度非常敏感,業(yè)內也有很多專門的存儲和查詢方案。
而在具體的實現(xiàn)中,有一種最為常見的實現(xiàn)手段,就是把各個維度的所有取值組合下的指標全部預先計算并且存儲好,這種一般可以稱作事實表。然后在具體進行多維查詢的時候,再根據(jù)維度的選擇,掃描相對應的數(shù)據(jù),并聚合得到最終的查詢條件。
此時,會發(fā)現(xiàn)一個比較有意思的問題,就是 PV 這類指標,是“可加”的,而 UV 這類指標,則是“不可加”的。例如,我們把昨天三個維度的可能組合下的所有的 PV 和 UV 都計算并且存儲好,如下表所示:
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
那么,對于 PV 這種指標,是可以通過掃描對應的記錄,然后累加得到最終的結果。例如,我們想分析整個湖北的 PV,則可以把湖北相關的四條記錄中的 PV,累加起來就是整個湖北的 PV 值。
但是,對于 UV 這類指標,卻不能簡單的累加,因為,這個指標并不是在每一個維度上都是正交的。例如,同一個用戶可能先后使用了不同的 App 版本,甚至于有一定幾率使用了不同的終端,所以,UV 并不能簡單地累加,通常情況下,真實的 UV 是比加起來的值更小的。
因而,對于 UV 這類不可累加的指標,需要使用其它的計算方案。
3. UV 計算的常見方案
UV 類型的指標,有三種常見的計算方案,我們在這里分別進行介紹。
3.1 估算方案
所謂的估算方案,就是在上面的表格的基礎上,不再額外記錄更多細節(jié),而是通過估算的方式來給出一個接近真實值的 UV 結果,常見的算法有很多,例如 HyperLogLog 等。
由于畢竟是估算,最終估算的結果有可能與真實值有較大差異,因此只有一些統(tǒng)計平臺可能會采用,而如我們 Sensors Analytics 之類的以精細化分析為核心的分析系統(tǒng)并不會采用,因此在這里不做更多描述。
3.2 擴充事實表,以存代算
所謂以存代算,就是在預先計算事實表的時候,將所有需要聚合的結果,都算好。
依然以上面的例子來說明,如果我們想以存代算,預先做完聚合,類似于 Hive 所提供的group by with cube操作。在擴充完畢后,之前那個表的結果就應該是:
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
北京 | ? | ? | 28960 | 1995 |
湖北 | ? | ? | 105115 | 4570 |
| ? | 安卓 | ? | 74160 | 4026 |
| ? | iOS | ? | 59897 | 3510 |
| ? | ? | 7.1 | 68672 | 3321 |
| ? | ? | 7.2 | 65385 | 3079 |
北京 | 安卓 | ? | 17025 | 1097 |
北京 | iOS | ? | 11935 | 989 |
湖北 | 安卓 | ? | 57135 | 2563 |
湖北 | iOS | ? | 47962 | 2477 |
北京 | ? | 7.1 | 6549 | 1233 |
北京 | ? | 7.2 | 12649 | 907 |
湖北 | ? | 7.1 | 52361 | 2577 |
湖北 | ? | 7.2 | 52736 | 2601 |
| ? | 安卓 | 7.1 | 39529 | 2011 |
| ? | 安卓 | 7.2 | 34631 | 1778 |
| ? | iOS | 7.1 | 29143 | 1801 |
| ? | iOS | 7.2 | 30754 | 1772 |
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
從這個表我們可以看出,假設一共三個維度,每個維度有兩個取值,則之前的事實表一共是?2*2*2=8?條記錄,而現(xiàn)在,則擴充到了?3*3*3-1=26?條記錄,整個規(guī)模擴充了很多,會帶來更多的存儲和預計算的代價。
3.3 從最細粒度數(shù)據(jù)上掃描
之前提出的擴充事實表的方式,的確可以解決多維分析中指標聚合的問題,除此之外,還有一種方案,則是在事實表上,將用戶ID也做為一個維度,來進行保存,此時就不需要保存 UV 了,如下表所示:
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
北京 | ? | ? | 28960 | 1995 |
湖北 | ? | ? | 105115 | 4570 |
| ? | 安卓 | ? | 74160 | 4026 |
| ? | iOS | ? | 59897 | 3510 |
| ? | ? | 7.1 | 68672 | 3321 |
| ? | ? | 7.2 | 65385 | 3079 |
北京 | 安卓 | ? | 17025 | 1097 |
北京 | iOS | ? | 11935 | 989 |
湖北 | 安卓 | ? | 57135 | 2563 |
湖北 | iOS | ? | 47962 | 2477 |
北京 | ? | 7.1 | 6549 | 1233 |
北京 | ? | 7.2 | 12649 | 907 |
湖北 | ? | 7.1 | 52361 | 2577 |
湖北 | ? | 7.2 | 52736 | 2601 |
| ? | 安卓 | 7.1 | 39529 | 2011 |
| ? | 安卓 | 7.2 | 34631 | 1778 |
| ? | iOS | 7.1 | 29143 | 1801 |
| ? | iOS | 7.2 | 30754 | 1772 |
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
北京 | iOS | 7.1 | 23231 | 2 |
北京 | iOS | 7.1 | 46297 | 3 |
... | ... | ... | ... | ... |
甚至更進一步,我們將 PV 數(shù)值也進一步展開,對于用戶的每一個行為,都保留一條數(shù)據(jù),如下表:
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
北京 | ? | ? | 28960 | 1995 |
湖北 | ? | ? | 105115 | 4570 |
| ? | 安卓 | ? | 74160 | 4026 |
| ? | iOS | ? | 59897 | 3510 |
| ? | ? | 7.1 | 68672 | 3321 |
| ? | ? | 7.2 | 65385 | 3079 |
北京 | 安卓 | ? | 17025 | 1097 |
北京 | iOS | ? | 11935 | 989 |
湖北 | 安卓 | ? | 57135 | 2563 |
湖北 | iOS | ? | 47962 | 2477 |
北京 | ? | 7.1 | 6549 | 1233 |
北京 | ? | 7.2 | 12649 | 907 |
湖北 | ? | 7.1 | 52361 | 2577 |
湖北 | ? | 7.2 | 52736 | 2601 |
| ? | 安卓 | 7.1 | 39529 | 2011 |
| ? | 安卓 | 7.2 | 34631 | 1778 |
| ? | iOS | 7.1 | 29143 | 1801 |
| ? | iOS | 7.2 | 30754 | 1772 |
北京 | 安卓 | 7.1 | 9762 | 743 |
北京 | 安卓 | 7.2 | 7263 | 531 |
北京 | iOS | 7.1 | 6549 | 623 |
北京 | iOS | 7.2 | 5386 | 423 |
湖北 | 安卓 | 7.1 | 29767 | 1437 |
湖北 | 安卓 | 7.2 | 27368 | 1315 |
湖北 | iOS | 7.1 | 22594 | 1236 |
湖北 | iOS | 7.2 | 25368 | 1432 |
北京 | iOS | 7.1 | 23231 | 2 |
北京 | iOS | 7.1 | 46297 | 3 |
... | ... | ... | ... | ... |
北京 | iOS | 7.1 | 23231 | 2015-01-01 12:03:08.934 | 瀏覽商品 |
北京 | iOS | 7.1 | 23231 | 2015-01-01 12:04:08.934 | 提交訂單 |
... | ... | ... | ... | ... | ... |
雖然這樣一來,需要保存的數(shù)據(jù)規(guī)模有了數(shù)量級上的擴充,并且所有的聚合計算都需要在多維分析查詢的時候再掃描數(shù)據(jù)并進行聚合,存儲和計算代價都提高了很多,看似是一種很無所謂的舉措。
但是,相比較之前的方案,它卻有一個最大的好處,也即是因為有了最細粒度的用戶行為數(shù)據(jù),才有可能計算事件級別的漏斗、留存、回訪等,才有可能在這些數(shù)據(jù)的基礎之上,進一步做用戶畫像、個性化推薦等等。而這也正是目前 Sensors Analytics 所采用的數(shù)據(jù)存儲方案,也正因為采用了這種存儲方案,我們才能夠將自己成為精細化用戶行為分析系統(tǒng),才能夠滿足使用者的最細粒度數(shù)據(jù)分析和獲取的需求。
在這樣一個數(shù)據(jù)存儲方案的基礎上,為了提高數(shù)據(jù)查詢的效能,一般的優(yōu)化思路有采用列存儲加壓縮的方式減少從磁盤中掃描的數(shù)據(jù)量,采用分布式的方案提高并發(fā)掃描的性能,采用應用層緩存來減少不同查詢的公共掃描數(shù)據(jù)的量等等,這方面的內容我們會在后面的文章里面做進一步的探討,盡請期待。
總結
以上是生活随笔為你收集整理的深度干货 | 多维分析中的 UV 与 PV的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 一篇讲清:数据采集与埋点
- 下一篇: 运营,如何用数据说话?(以电商活动复盘为