APP埋點:頁面統計與事件統計該如何入手?
我們平時所說的埋點,可以大致分為兩部分,一部分是統計APP頁面訪問情況,即頁面統計;另外一部分是統計APP內的操作行為,及自定義事件統計。
一、頁面統計
頁面統計,可以統計應用內各個頁面的訪問次數(PV),訪問設備數(UV)和訪問時長,以及各頁面之間的流向關系。
1.1 頁面訪問數
頁面訪問次數,即當前頁面的被訪問的次數,即瀏覽量PV;舉例:首頁,訪問次數,1000次;
頁面訪問人數,即訪問該頁面的活躍用戶數,即獨立訪問數UV;舉例:首頁,訪問人數,100次;
1.2 頁面訪問時長
頁面訪問時長,用戶在頁面的停留時長,即首頁受訪時長的總和;舉例:首頁,訪問總時長,2小時;
1.3頁面流向分布
頁面流向(走向)分布,可統計出,當前頁面和下一個頁面(有多個)的流向關系;
舉例1:在“商品詳情”這個頁面中,可以進入“購買”、“收藏”、“返回列表”、共3個頁面,即在“商品詳情”頁,可能的流向分布為:
其中,用戶在該“商品詳情”頁面,沒有進入對應的3個頁面,即視為“離開應用”,在頁面流向分布,有2個常見問題:
?問題一:頁面流向分布中,僅有離開應用這一個指標?
造成這種情況的原因,可能有以下兩點:
- 用戶在該頁面全部選擇了離開用戶(這種概率相對很?。?;
- 該頁面的下一級頁面,沒有做埋點,導致所有的下一級頁面都沒有數據,其結果就是離開應用的占比為100%;
問題二:頁面流向分布中,離開應用的占比非常高,達到了40%以上?
與問題一類似,如果沒有為每個頁面添加統計代碼,會導致這些頁面統計不到,那么跳轉到這些未添加統計代碼的頁面,將會被視為離開應用。
備注:頁面流向分布的計算方法
頁面的統計數據中,會返回以下數據:當前頁面名稱,來源頁面名稱,當前頁面訪問次數;
舉例2:參照舉例1中的頁面流向分布,假定的頁面統計數字如下:
則,商品詳情流向購買頁面的占比為:在購買頁面中,來源為商品詳情的次數與商品詳情總次數的比值,即20/100*100%=20%;
依次類推,可以分別計算出商品詳情流向收藏、商品詳情流向返回列表的占比;
離開應用的占比,即為1-(20+30+30)/100*100%=20%。
二、自定義事件統計
自定義事件,即記錄用戶的操作行為(如點擊行為),記錄用戶操作行為中的具體細節;一般來說,通常所說的埋點,指的就是自定義事件。
埋點可以是某個按鈕,某個點擊區域,某個提示,甚至可以用來統計一些特定的代碼是否被執行。在APP中,需要在代碼中定義一個事件行為。
2.1簡單事件統計
簡單事件統計,即記錄事件的發生次數(可理解為PV)和事件發生人數(可理解為UV)。
以下面的登錄頁為例:
其事件統計的結果為:
事件ID,即EventID,該名稱可由程序員自行定義(按照APP統計平臺,如友盟、talkingdata等提供的事件ID命名規范進行命名),將該事件ID寫入需要跟蹤的位置中即可。
事件名稱,可以理解為事件ID的一個中文翻譯名稱,是為了方便運營人員查看,事件名稱命名是在APP上線后,該事件ID有數據后的一個事后行為,通常是在APP數據平臺中定義(如果你樂意,你可以把input_number這個事件ID的事件名稱改為:用戶在這里輸入手機號)。事件名稱只是事件ID在前端頁面的一個顯示名稱。
事件發生次數,即該事件總共發生的次數;可以理解為,在每個事件中,都會有個事件ID計數器,每當該事件被觸發時,事件數即加1;
事件發生人數,即該事件的發生人數(有些APP統計平臺也稱之為:達成該事件的用戶數、獨立用戶數);參考事件發生次數,可以理解為,在每個事件中,都會有個事件ID計數器,每當該事件被觸發時,同時記錄下該用戶的唯一標識,事件數即加1;事件發生人數,即根據用戶唯一標識,對事件發生次數進行去重。
2.2事件轉化漏斗
事件漏斗,即按照一定的事件順序,依次統計各個事件之間的轉化率,如我們可以對登錄注冊中的一些關鍵步驟進行事件漏斗分析,如輸入手機號碼,獲取驗證碼、輸入驗證碼等,以2.1中提到的登錄過程為例,其漏斗可設置為:輸入手機號碼->獲取驗證碼->輸入驗證碼->點擊登錄按鈕,即由4個事件組成的漏斗。
根據對應的事件數(設備數),即可計算出各個事件的轉化率,如輸入手機號碼發生人數為5000次,獲取驗證碼的次數為4000人數,那么輸入手機號碼后點擊獲取驗證碼的轉化率為4000/5000*100=80%。如下表所示:
2.3利用事件參數進行精確統計
為方便對相同類型的事件類型進行歸類,在事件統計中,提供了事件標簽(label)的方法;即相同類型的事件可以使用相同的事件ID和不同的事件label,通過事件ID+事件label的方式,指代一個特定的事件。
在進行事件統計時,為了為了統計一些特定的行為數據,如商品價格,商品類型等具體數據,提供了事件參數的方法,通過使用key-value的方式,記錄該事件的詳細記錄。
事件ID、事件label、事件參數的關系,如下圖所示:
舉例,在一個購買行為中,運營人員想查看用戶在整個購買流程的詳細參數,那么可以通過以下的事件埋點方式進行埋點;在這個購買行為中,購買就是事件ID,瀏覽商品詳情,收藏該商品,加入購物車等,就是一個一個的事件label;在瀏覽商品詳情中,“商品類型:電子產品”,“商品價格:1-100元”……,等,就是一對一對的key-value值,如下圖所示:
通過對商品價格的分析,可以統計得出,用戶所選擇的商品價格的分布情況。
三、結語
在APP埋點中,我們可以統計得出各個APP頁面和各個用戶操作行為的數據,我們也可以計算得出任意幾個事件之間的轉化數據。當然,考慮運營分析中的實際意義和各APP數據統計平臺的計算能力等因素,建議統計關鍵路徑的事件數據。
APP埋點所得出的數據,對優化設計流程,優化運營推廣策略有著極其重要的作用,通過埋點數據可以更好去了解用戶,更好地提供產品服務。
歡迎各位看官打賞~~
相關文章
作者:十三先,微信公眾號:產品者也
本文由 @十三先 原創發布于人人都是產品經理。未經許可,禁止轉載。
小白看懂了,真的不錯。
??
干貨滿滿,給作者大大點贊
埋點
謝謝作者 寫的不錯
寫的很好,既有概念又有示例,易懂但不簡單,學習了!
深入淺出,明白了
感謝大佬的分享,對工作有啟發
好
關注微信公眾號:產品者也,回復關鍵字【埋點】,即可獲得埋點文檔模板。
APP做活動的話,請問埋哪些點可以知道活動頁面轉化率?
文章寫得很有啟發,但有個地方有待商榷,在計算事件轉化率時(輸入手機號碼->獲取驗證碼->輸入驗證碼->點擊登錄按鈕),如果用”事件發生次數/上一事件發生次數=轉化率”會產生這樣的問題:比方說此頁面獲取驗證碼這個地方有問題,可能導致用戶多次獲取、多次輸入,這樣可能獲取驗證碼數會大于輸入手機號碼數,這個時候計算出來的轉化率是大于100%的,顯然不太合理。用“事件發生人數/上一事件發生人數”會更合理一些。
同感
是的。
嚴格意義上的轉化率,應該以 單一設備數(去重)的完成數(去重)來計算。
第1個動作,共有1000臺設備完成操作;第2個動作,在第1步的1000個設備中,有50個設備完成了操作,則轉化率為5%;
很有道理
自定義事件ID就是你埋點前需要給一個事件命名唯一ID名稱,label就是我這個事件ID需要傳哪些key,value參數,
通俗例子:我需要埋點統計查詢點擊,我的事件ID取一個唯一的quchaxun-001,代表我是查詢按鈕的事件,label就是用戶發生quchaxun-001事件時,還需要取這個用戶的哪些信息,如已登錄用戶的手機號、點擊時間等參數信息
這里和你說的貌似不同
不同統計平臺的埋點邏輯會有些不同哈。
label,是可用,可不用的哈
事件label是事件的組成部分,這些label在一起組成了事件,所以如果現在定義購買是一個事件,那么瀏覽商品詳情,收藏該商品,加入購物車就是事件的組成部分,即label,是否需要label取決于所統計的時間的粒度,所以也可以定義瀏覽商品詳情為一個事件,如果覺得粒度足夠就不用定義事件label了, 可以這樣理解嗎?
如果想看具體某個用戶的操作路徑,怎么統計?
樓主是使用什么統計工具呢?
學習了,很不錯
受益匪淺!贊贊贊!
事件ID、事件label、事件參數,這里不是很懂 ?? ,購買是事件ID、瀏覽商品詳情,收藏該商品,加入購物車是事件label,“商品類型:電子產品”“商品價格:1-100元”是事件參數,這好像沒組成一個完成流程?。?/p>
這是面向對象的思想
商品類型,商品價格是key ,衣服、褲子、鞋子;1-100、100-200價格區間是參數。好像是這樣的。我的理解key應該就是label
學習了,很清晰,希望能多介紹一些數據分析方法~
多交流!
微信公眾號:sikaoshenme(思考什么),個人微信:licx003,多多交流!
受益匪淺!贊贊贊!
謝謝!
h5的埋點,與比類似
干貨!謝謝分享!
謝謝,多多交流!