我們平時所說的埋點，可以大致分為兩部分，一部分是統計APP頁面訪問情況，即頁面統計；另外一部分是統計APP內的操作行為，及自定義事件統計。

一、頁面統計

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

1.1 頁面訪問數

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

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

1.2 頁面訪問時長

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

1.3頁面流向分佈

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

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

其中，使用者在該“商品詳情”頁面，沒有進入對應的3個頁面，即視為“離開應用”，在頁面流向分佈，有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；事件發生人數，即根據使用者唯一標識，對事件發生次數進行去重。

三、常用前端埋點方案總結

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

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

(1) 程式碼埋點

程式碼埋點，就是以嵌入程式碼的形式進行埋點，比如需要監控使用者的點選事件，會選擇在使用者點選時，插入一段程式碼，儲存這個監聽行為或者直接將監聽行為以某一種資料格式直接傳遞給server端。此外比如需要統計產品的PV和UV的時候，需要在網頁的初始化時，傳送使用者的訪問資訊等。

程式碼埋點的優點：

• 可以在任意時刻，精確的傳送或儲存所需要的資料資訊。

缺點：

• 工作量較大，每一個元件的埋點都需要新增相應的程式碼

(2)視覺化埋點

通過視覺化互動的手段，代替程式碼埋點。將業務程式碼和埋點程式碼分離，提供一個視覺化互動的頁面，輸入為業務程式碼，通過這個視覺化系統，可以在業務程式碼中自定義的增加埋點事件等等，最後輸出的程式碼耦合了業務程式碼和埋點程式碼。

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

缺點：

• 視覺化埋點可以埋點的控制元件有限，不能手動定製。

(3)無埋點

無埋點並不是說不需要埋點，而是全部埋點，前端的任意一個事件都被繫結一個標識，所有的事件都別記錄下來。通過定期上傳記錄檔案，配合檔案解析，解析出來我們想要的資料，並生成視覺化報告供專業人員分析因此實現“無埋點”統計。

從語言層面實現無埋點也很簡單，比如從頁面的js程式碼中，找出dom上被繫結的事件，然後進行全埋點。

無埋點的優點：

• 由於採集的是全量資料，所以產品迭代過程中是不需要關注埋點邏輯的，也不會出現漏埋、誤埋等現象

缺點：

• 無埋點採集全量資料，給資料傳輸和伺服器增加壓力

• 無法靈活的定製各個事件所需要上傳的資料

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

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

(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