埋點--頁面統計與事件統計該如何入手？

咱們平時所說的埋點，能夠大體分爲兩部分，一部分是統計APP頁面訪問狀況，即頁面統計；另一部分是統計APP內的操做行爲，及自定義事件統計。

1、頁面統計

頁面統計，能夠統計應用內各個頁面的訪問次數（PV）,訪問設備數（UV）和訪問時長，以及各頁面之間的流向關係。

1.1 頁面訪問數

頁面訪問次數，即當前頁面的被訪問的次數，即瀏覽量PV；舉例：首頁，訪問次數，1000次；

頁面訪問人數，即訪問該頁面的活躍用戶數，即獨立訪問數UV；舉例：首頁，訪問人數，100次；

1.2 頁面訪問時長

頁面訪問時長，用戶在頁面的停留時長，即首頁受訪時長的總和；舉例：首頁，訪問總時長，2小時；

1.3頁面流向分佈

頁面流向（走向）分佈，可統計出，當前頁面和下一個頁面（有多個）的流向關係；

舉例1：在「商品詳情」這個頁面中，能夠進入「購買」、「收藏」、「返回列表」、共3個頁面，即在「商品詳情」頁，可能的流向分佈爲：

其中，用戶在該「商品詳情」頁面，沒有進入對應的3個頁面，即視爲「離開應用」，在頁面流向分佈，有2個常見問題：

2、自定義事件統計

自定義事件，即記錄用戶的操做行爲（如點擊行爲），記錄用戶操做行爲中的具體細節；通常來講，一般所說的埋點，指的就是自定義事件。

埋點能夠是某個按鈕，某個點擊區域，某個提示，甚至能夠用來統計一些特定的代碼是否被執行。在APP中，須要在代碼中定義一個事件行爲。

2.1簡單事件統計

簡單事件統計，即記錄事件的發生次數（可理解爲PV）和事件發生人數（可理解爲UV）。

如下面的登陸頁爲例：

其事件統計的結果爲：

事件ID，即EventID，該名稱可由程序員自行定義（按照APP統計平臺，如友盟、talkingdata等提供的事件ID命名規範進行命名），將該事件ID寫入須要跟蹤的位置中便可。

事件名稱，能夠理解爲事件ID的一箇中文翻譯名稱，是爲了方便運營人員查看，事件名稱命名是在APP上線後，該事件ID有數據後的一個過後行爲，一般是在APP數據平臺中定義（若是你樂意，你能夠把input_number這個事件ID的事件名稱改成：用戶在這裏輸入手機號）。事件名稱只是事件ID在前端頁面的一個顯示名稱。

事件發生次數，即該事件總共發生的次數；能夠理解爲，在每一個事件中，都會有個事件ID計數器，每當該事件被觸發時，事件數即加1；

事件發生人數，即該事件的發生人數（有些APP統計平臺也稱之爲：達成該事件的用戶數、獨立用戶數）；參考事件發生次數，能夠理解爲，在每一個事件中，都會有個事件ID計數器，每當該事件被觸發時，同時記錄下該用戶的惟一標識，事件數即加1；事件發生人數，即根據用戶惟一標識，對事件發生次數進行去重。

3、經常使用前端埋點方案總結

在上一節中介紹了前端監控的做用，那麼如何實現前端監控呢，實現前端監控的步驟爲：前端埋點和上報、數據處理和數據分析。首要的步驟就是前端埋點和上報，也就是數據的收集階段。數據收集的豐富性和準確性會影響對產品線上效果的判別結果。

目前常見的前端埋點方法分爲三種：代碼埋點、可視化埋點和無痕埋點。下面一一介紹每一種埋點的方法。

(1) 代碼埋點

代碼埋點，就是以嵌入代碼的形式進行埋點，好比須要監控用戶的點擊事件，會選擇在用戶點擊時，插入一段代碼，保存這個監聽行爲或者直接將監聽行爲以某一種數據格式直接傳遞給server端。此外好比須要統計產品的PV和UV的時候，須要在網頁的初始化時，發送用戶的訪問信息等。

代碼埋點的優勢：

• 能夠在任意時刻，精確的發送或保存所須要的數據信息。

缺點：

• 工做量較大，每個組件的埋點都須要添加相應的代碼

(2)可視化埋點

經過可視化交互的手段，代替代碼埋點。將業務代碼和埋點代碼分離，提供一個可視化交互的頁面，輸入爲業務代碼，經過這個可視化系統，能夠在業務代碼中自定義的增長埋點事件等等，最後輸出的代碼耦合了業務代碼和埋點代碼。

可視化埋點聽起來比較高大上，實際上跟代碼埋點仍是區別不大。也就是用一個系統來實現手動插入代碼埋點的過程。

缺點：

• 可視化埋點能夠埋點的控件有限，不能手動定製。

(3)無埋點

無埋點並非說不須要埋點，而是所有埋點，前端的任意一個事件都被綁定一個標識，全部的事件都別記錄下來。經過按期上傳記錄文件，配合文件解析，解析出來咱們想要的數據，並生成可視化報告供專業人員分析所以實現「無埋點」統計。

從語言層面實現無埋點也很簡單，好比從頁面的js代碼中，找出dom上被綁定的事件，而後進行全埋點。

無埋點的優勢：

• 因爲採集的是全量數據，因此產品迭代過程當中是不須要關注埋點邏輯的，也不會出現漏埋、誤埋等現象

缺點：

• 無埋點採集全量數據，給數據傳輸和服務器增長壓力

• 沒法靈活的定製各個事件所須要上傳的數據

4、前端埋點方案選型和前端上報方案設計

第一章中介紹了前端所須要監聽的信息，在第二章中介紹了前端埋點的常見方式，本文來根據需求，來定製咱們的埋點和上報方案。

(1)監控數據

首先咱們須要明確一個產品或者網頁，廣泛須要監控和上報的數據。監控的分爲三個階段：用戶進入網頁首頁、用戶在網頁內部交互和交互中報錯。每個階段須要監控和上報的數據以下圖所示：

(2)埋點方案

在實際項目中考慮到上報數據的靈活定製，以及減小數據傳輸和服務器的壓力，在所需埋點處很少的狀況下，經常使用的方式是代碼埋點。

以用戶進入首頁爲例，咱們在首頁渲染完成後會發送事件類型和類型相關的數據給server端，告知首頁的監控信息。

(3)上報週期和上報數據類型

若是埋點的事件不是不少，上報能夠時時進行，好比監控用戶的交互事件，能夠在用戶觸發事件後，馬上上報用戶所觸發的事件類型。若是埋點的事件較多，或者說網頁內部交互頻繁，能夠經過本地存儲的方式先緩存上報信息，而後按期上報。

接着來肯定須要埋點上報的數據，上報的信息包括用戶我的信息以及用戶行爲，主要數據能夠分爲：

• who: appid(系統或者應用的id),userAgent(用戶的系統、網絡等信息)

• when: timestamp(上報的時間戳)

• from where: currentUrl(用戶當前url)，fromUrl(從哪個頁面跳轉到當前頁面)，type(上報的事件類型),element(觸發上報事件的元素）

• what: 上報的自定義擴展數據data:{},擴展數據中能夠按需求定製，好比包含uid等信息

參考鏈接：http://www.woshipm.com/data-analysis/450268.html

http://www.cnblogs.com/liuhao-web/p/9609884.html

https://blog.csdn.net/zhuhengv/article/details/50911482