關於數據埋點，你須要瞭解這些基本知識

產品汪天天都在和數據打交道，你知道數據來自哪裏嗎？

移動app端內的用戶行爲數據大多來自埋點，瞭解一些埋點知識，能和數據分析師、技術侃大山，參與到前期的數據採集，更重要是讓最終的埋點數據能爲我所用，不然可憐巴巴等上幾個月是常有的事。

 

埋點類型

根據埋點方式，能夠區分爲：

1. 手動埋點
2. 半自動埋點
3. 全自動埋點

秉承「任何事物都有兩面性」的道理：自動程度高的，能解決通用統計，便於統一化管理，但個性化定製需求難知足，成本較低；偏手動的，能知足個性化需求，但容易出錯和疏漏，成本較高。

上報方式：

1. 客戶端上報
2. 服務端上報

客戶端能記錄一些通用頁面PV、UV、點擊等信息，但更多細節沒法覆蓋，用戶購買了什麼、訂單金額、成交單數，用戶看了哪一個視頻、視頻物理時長是多少等信息則須要服務端回傳，服務端上報有上線靈活、不隨版本、丟失率較低的優勢。

客戶端上報埋點數據流轉以下圖：

（客戶端上報埋點數據流轉）

埋點在個性化推薦系統（詳見下一篇推送）中扮演着先頭兵的角色，採集的數據的準確性將直接影響策略方向。

 

端數據

因爲不一樣端的用戶具備不一樣用戶特徵，每每會有不一樣的作功點，所以，採集數據時須要區分端數據，能夠經過app_id區分產品不一樣端，如iOS、Android、iPad、PC各端。

 

埋點事件

若是做爲數據分析師，思考角度較高，輸出的埋點須要有「可擴展、可維護、易用性、高效性」，字少事大的典型。產品汪可下降要求，只要能看懂埋點文檔，正確提出埋點需求、知道哪些數據對應哪些埋點便可。

(埋點文檔示例)

根據場景，同一屬性的行爲每每會歸爲同一類埋點，成爲「同一事件」，同一事件下會有相應的擴展字段來承接相關的細節信息。

 

事件字段

以資訊app（現在日頭條、騰訊新聞、網易新聞）爲例，按漏斗思惟和用戶的行爲路徑拆解，有哪些數據可能須要獲取？

打開APP人數（客戶端登陸損耗）->首頁/欄目訪問人數（訪問佔比）->刷新或點擊人數（刷新或點擊人數佔比）->點擊人數（點擊率）->閱讀時長/停留時長（讀完率、閱讀進度）->跟帖/收藏/分享等互動行爲（互動率）->迴流人數（迴流率、病毒傳播係數）

以上環節怎麼對應上埋點？

根據行爲屬性，埋點事件大體分爲如下幾類，並不惟一：

埋點事件下的信息怎麼看？如item_id:」114774」，冒號前是字段（key），冒號後是值（value），//後的是註釋。

以視頻瀏覽事件（_vdE）爲例：

字段注意點和應用場景：

1. item_id：內容id，易錯傳爲序列id
2. type：內容類型，如圖文、視頻、音頻，可區份內容類型做分析
3. referer_id：上一頁面內容id，可用於相關推薦業務的分析
4. _pt/_pi/_pm系列：定位頁面和模塊，可用於不一樣業務線的分析，例如首頁、要問頻道、正文頁等
5. _pre_系列：追蹤了上一級頁面，可用於用戶行爲路徑分析

除了關注字段的定義和場景外，還需留意上報時機，定義儘量周全，就以此視頻瀏覽事件爲例：

1. 頁面退出（銷燬）時：點擊返回等
2. 切換到其餘視頻：點擊上下集，點擊相關視頻等
3. 按home鍵退出時
4. 鎖屏時
5. app殺死時

以刷新事件（_fsE）爲例：

1. direction：可供產品汪區分上拉、下拉做刷新行爲的分析。你可能會發現，除自動刷新外，大部分用後喜歡上拉刷新，但下拉刷新的廣告位更值錢（有問題存在就有工做要作了）。
2. auto_type：在新session，打開app到達首頁會有一次自動刷新（即用戶沒有手動操做），可用於分析用戶主動刷新的行爲。

以評論事件（_cmE）爲例：

從以上埋點，咱們能獲取哪些數據？

每篇內容的評論數，可區份內容類型、欄目、評論類型、位置；結合獲取到的用戶id，還能夠從用戶維度分析。

以上埋點字段僅作示例說明，須要根據實際的數據須要來增刪字段，定義要明確，場景要詳盡，避免出現「想要分析次均閱讀進度，卻發現沒有相關字段」的窘境。

 

五花八門的用戶id

用戶id是用戶的惟一標識，是該用戶在應用裏活動的「身份證」，但它在獲取的時候但是五花八門的，曾經某產品汪提供的deviceid和數據分析師手上的uuid徹底對不上，ab實驗得重作，因此懂多點兒概念提早問一問準沒錯。

（用戶id獲取示例）

以iOS系統的用戶id獲取爲例，先補充幾個概念。

1. IDFA（廣告標識符，Advertising Identifier），是蘋果公司提供的用於追蹤用戶的廣告ID，同一手機的不一樣APP對應着相同的IDFA，IDFA可經過如下步驟重置：設置-隱私-廣告-還原廣告標識符。由於IDFA會存在取不到的狀況，所以須要選用其餘的ID做爲DeviceID。在取不到IDFA的狀況下，選用IDFV。
2. IDFV（Vindor標示符，IdentifierForVendor），通常用於追蹤用戶在應用內的行爲，每一個設備在所屬同一個Vender的應用裏值是相同的。若是用戶刪掉了該vender的全部APP，IDFV將會被重置。
3. UUID（通用惟一標識碼，Universally Unique Identifier），通用惟一識別碼，每次生成均不同；第1次生成後UUID後，須要保存到鑰匙串（keyChain）中；應用被刪除再重裝時，仍然能夠從鑰匙串得取到UUID；在一臺設備上，同一個開發者帳號的全部APP，可獲取到相同的UDID；刷機或者從新安裝系統後，UUID將從新生成。

鑑於沒有任何一種標識符能百分百準確獲取，且爲了儘量獲取用戶id，會有一個退而求其次的獲取邏輯，即先取IDFA的值，取不到IDFA時去取IDFV的值，再取不到時IDFA時，則生成UUID。

獲取用戶id邏輯示例：

• iOS：先取user-DA；若是user-DA爲空或者爲00000000-0000-0000-0000-000000000000，取user-DV；若是user-DV爲空，取deviceid
• Android：先取imei；若是imei爲空或者爲02:00:00:00:00:00，取deviceid

 

埋點踩過的坑

字段和值

• id字段指內容id，錯傳序列id，致使沒法讀取用戶瀏覽的內容，丟失用戶閱讀歷史（影響個性化推薦）。
• 當內容是合集時，item_id傳合集id仍是主視頻id需提早定義

上報時機

• 需明肯定義，如：不一樣端的文章瀏覽事件切換先後臺時的上報時機需統一，Android切先後臺都上報，iOS僅切前臺時上報，致使兩端的人均閱讀數差別大。
• 需正確上報，如：視頻瀏覽事件出現同一個用戶的同一條數據重複上報（事件、時間戳、用戶id等都相同），使統計的瀏覽量偏大。

統計

• 栗子1：過濾瀏覽事件中時長>=10 ms 和 時長<10000000 ms 的異常數據。
• 栗子2：過濾刷新事件中單個用戶天天幾千幾萬次刷新的異常數據。

 

埋點注意點

1. 埋點問題需跟版本修復，bug修復週期長：手動埋點若是出現漏埋或埋錯的狀況，必須依賴下一個版本發版，才能看到數據（發版還需時間覆蓋，很傷），想周全+多測試=高效率
2. 定義明確，格式規範，正確上報
3. 測試環節很重要（老生常談）

 

平常反饋bug姿式

產品汪反饋bug是屢見不鮮，甩個bug截圖可能會被忙碌精分的開發直接無視，掌握反饋bug的正確姿式：

1. 截圖
2. 提供本身的app帳號或手機信息
3. Android：提供imei（手機數入*#06#可自助查詢）
4. iOS：提供idfa（抓包查詢）
5. 說明時間和場景，給開發補充上下文，方便定位問題

走上述流程，開發必定以爲你可愛無比。

 

結語

只要產品仍在迭代，就須要更新埋點以供數據分析使用，能夠說埋點將伴隨產品終生，攜手埋點，頭髮也將愈來愈少，且行且珍惜。