本文作者從工作實踐出發，梳理總結了關于資料埋點的相關基本知識，與大家分享。
産品汪每天都在和資料打交道，你知道資料來自哪裡嗎？
移動app端内的使用者行為資料大多來自埋點，了解一些埋點知識，能和資料分析師、技術侃大山，參與到前期的資料采集，更重要是讓最終的埋點資料能為我所用，否則可憐巴巴等上幾個月是常有的事。
埋點類型
根據埋點方式，可以區分為：
- 手動埋點
- 半自動埋點
- 全自動埋點
秉承“任何事物都有兩面性”的道理：自動程度高的，能解決通用統計，便于統一化管理，但個性化定制需求難滿足，成本較低；偏手動的，能滿足個性化需求，但容易出錯和疏漏，成本較高。
上報方式：
- 用戶端上報
- 服務端上報
用戶端能記錄一些通用頁面PV、UV、點選等資訊，但更多細節無法覆寫，使用者購買了什麼、訂單金額、成交單數，使用者看了哪個視訊、視訊實體時長是多少等資訊則需要服務端回傳，服務端上報有上線靈活、不随版本、丢失率較低的優點。
用戶端上報埋點資料流轉如下圖：
（用戶端上報埋點資料流轉）
埋點在個性化推薦系統（詳見下一篇推送）中扮演着先頭兵的角色，采集的資料的準确性将直接影響政策方向。
端資料
由于不同端的使用者具有不同使用者特征，往往會有不同的做功點，是以，采集資料時需要區分端資料，可以通過app_id區分産品不同端，如iOS、Android、iPad、PC各端。
埋點事件
如果作為資料分析師，思考角度較高，輸出的埋點需要有“可擴充、可維護、易用性、高效性”，字少事大的典型。産品汪可降低要求，隻要能看懂埋點文檔，正确提出埋點需求、知道哪些資料對應哪些埋點即可。
(埋點文檔示例)
根據場景，同一屬性的行為往往會歸為同一類埋點，成為“同一事件”，同一事件下會有相應的擴充字段來承接相關的細節資訊。
事件字段
以資訊app（如今日頭條、騰訊新聞、網易新聞）為例，按漏鬥思維和使用者的行為路徑拆解，有哪些資料可能需要擷取？
打開APP人數（用戶端登入損耗）->首頁/欄目通路人數（通路占比）->重新整理或點選人數（重新整理或點選人數占比）->點選人數（點選率）->閱讀時長/停留時長（讀完率、閱讀進度）->跟帖/收藏/分享等互動行為（互動率）->回流人數（回流率、病毒傳播系數）
以上環節怎麼對應上埋點？
根據行為屬性，埋點事件大緻分為以下幾類，并不唯一：
埋點事件下的資訊怎麼看？如item_id:”114774”，冒号前是字段（key），冒号後是值（value），//後的是注釋。
以視訊浏覽事件（_vdE）為例：
字段注意點和應用場景：
- item_id：内容id，易錯傳為序列id
- type：内容類型，如圖文、視訊、音頻，可區分内容類型作分析
- referer_id：上一頁面内容id，可用于相關推薦業務的分析
- _pt/_pi/_pm系列：定位頁面和子產品，可用于不同業務線的分析，例如首頁、要問頻道、正文頁等
- _pre_系列：追蹤了上一級頁面，可用于使用者行為路徑分析
除了關注字段的定義和場景外，還需留意上報時機，定義盡可能周全，就以此視訊浏覽事件為例：
- 頁面退出（銷毀）時：點選傳回等
- 切換到其他視訊：點選上下集，點選相關視訊等
- 按home鍵退出時
- 鎖屏時
- app殺死時
以重新整理事件（_fsE）為例：
- direction：可供産品汪區分上拉、下拉作重新整理行為的分析。你可能會發現，除自動重新整理外，大部分用後喜歡上拉重新整理，但下拉重新整理的廣告位更值錢（有問題存在就有工作要做了）。
- auto_type：在新session，打開app到達首頁會有一次自動重新整理（即使用者沒有手動操作），可用于分析使用者主動重新整理的行為。
以評論事件（_cmE）為例：
從以上埋點，我們能擷取哪些資料？
每篇内容的評論數，可區分内容類型、欄目、評論類型、位置；結合擷取到的使用者id，還可以從使用者次元分析。
以上埋點字段僅做示例說明，需要根據實際的資料需要來增删字段，定義要明确，場景要詳盡，避免出現“想要分析次均閱讀進度，卻發現沒有相關字段”的窘境。
五花八門的使用者id
使用者id是使用者的唯一辨別，是該使用者在應用裡活動的“身份證”，但它在擷取的時候可是五花八門的，曾經某産品汪提供的deviceid和資料分析師手上的uuid完全對不上，ab實驗得重做，是以懂多點兒概念提前問一問準沒錯。
（使用者id擷取示例）
以iOS系統的使用者id擷取為例，先補充幾個概念。
- IDFA（廣告辨別符，Advertising Identifier），是蘋果公司提供的用于追蹤使用者的廣告ID，同一手機的不同APP對應着相同的IDFA，IDFA可通過以下步驟重置：設定-隐私-廣告-還原廣告辨別符。因為IDFA會存在取不到的情況，是以需要選用其他的ID作為DeviceID。在取不到IDFA的情況下，選用IDFV。
- IDFV（Vindor标示符，IdentifierForVendor），一般用于追蹤使用者在應用内的行為，每個裝置在所屬同一個Vender的應用裡值是相同的。如果使用者删掉了該vender的所有APP，IDFV将會被重置。
- 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：過濾重新整理事件中單個使用者每天幾千幾萬次重新整理的異常資料。
埋點注意點
- 埋點問題需跟版本修複，bug修複周期長：手動埋點如果出現漏埋或埋錯的情況，必須依賴下一個版本發版，才能看到資料（發版還需時間覆寫，很傷），想周全+多測試=高效率
- 定義明确，格式規範，正确上報
- 測試環節很重要（老生常談）
日常回報bug姿勢
産品汪回報bug是家常便飯，甩個bug截圖可能會被忙碌精分的開發直接無視，掌握回報bug的正确姿勢：
- 截圖
- 提供自己的app賬号或手機資訊
- Android：提供imei（手機數入*#06#可自助查詢）
- iOS：提供idfa（抓包查詢）
- 說明時間和場景，給開發補充上下文，友善定位問題
走上述流程，開發一定覺得你可愛無比。