本文作者從工作實(shí)踐出發(fā)，梳理總結(jié)了關(guān)于數(shù)據(jù)埋點(diǎn)的相關(guān)基本知識(shí)，與大家分享。

產(chǎn)品汪每天都在和數(shù)據(jù)打交道，你知道數(shù)據(jù)來(lái)自哪里嗎？

移動(dòng)app端內(nèi)的用戶行為數(shù)據(jù)大多來(lái)自埋點(diǎn)，了解一些埋點(diǎn)知識(shí)，能和數(shù)據(jù)分析師、技術(shù)侃大山，參與到前期的數(shù)據(jù)采集，更重要是讓最終的埋點(diǎn)數(shù)據(jù)能為我所用，否則可憐巴巴等上幾個(gè)月是常有的事。

埋點(diǎn)類型

根據(jù)埋點(diǎn)方式，可以區(qū)分為：

1. 手動(dòng)埋點(diǎn)
2. 半自動(dòng)埋點(diǎn)
3. 全自動(dòng)埋點(diǎn)

秉承“任何事物都有兩面性”的道理：自動(dòng)程度高的，能解決通用統(tǒng)計(jì)，便于統(tǒng)一化管理，但個(gè)性化定制需求難滿足，成本較低；偏手動(dòng)的，能滿足個(gè)性化需求，但容易出錯(cuò)和疏漏，成本較高。

上報(bào)方式：

1. 客戶端上報(bào)
2. 服務(wù)端上報(bào)

客戶端能記錄一些通用頁(yè)面PV、UV、點(diǎn)擊等信息，但更多細(xì)節(jié)無(wú)法覆蓋，用戶購(gòu)買了什么、訂單金額、成交單數(shù)，用戶看了哪個(gè)視頻、視頻物理時(shí)長(zhǎng)是多少等信息則需要服務(wù)端回傳，服務(wù)端上報(bào)有上線靈活、不隨版本、丟失率較低的優(yōu)點(diǎn)。

客戶端上報(bào)埋點(diǎn)數(shù)據(jù)流轉(zhuǎn)如下圖：

（客戶端上報(bào)埋點(diǎn)數(shù)據(jù)流轉(zhuǎn)）

埋點(diǎn)在個(gè)性化推薦系統(tǒng)（詳見下一篇推送）中扮演著先頭兵的角色，采集的數(shù)據(jù)的準(zhǔn)確性將直接影響策略方向。

端數(shù)據(jù)

由于不同端的用戶具有不同用戶特征，往往會(huì)有不同的做功點(diǎn)，因此，采集數(shù)據(jù)時(shí)需要區(qū)分端數(shù)據(jù)，可以通過(guò)app_id區(qū)分產(chǎn)品不同端，如iOS、Android、iPad、PC各端。

埋點(diǎn)事件

如果作為數(shù)據(jù)分析師，思考角度較高，輸出的埋點(diǎn)需要有“可擴(kuò)展、可維護(hù)、易用性、高效性”，字少事大的典型。產(chǎn)品汪可降低要求，只要能看懂埋點(diǎn)文檔，正確提出埋點(diǎn)需求、知道哪些數(shù)據(jù)對(duì)應(yīng)哪些埋點(diǎn)即可。

(埋點(diǎn)文檔示例)

根據(jù)場(chǎng)景，同一屬性的行為往往會(huì)歸為同一類埋點(diǎn)，成為“同一事件”，同一事件下會(huì)有相應(yīng)的擴(kuò)展字段來(lái)承接相關(guān)的細(xì)節(jié)信息。

事件字段

以資訊app（如今日頭條、騰訊新聞、網(wǎng)易新聞）為例，按漏斗思維和用戶的行為路徑拆解，有哪些數(shù)據(jù)可能需要獲?。?/p>

打開APP人數(shù)（客戶端登錄損耗）->首頁(yè)/欄目訪問(wèn)人數(shù)（訪問(wèn)占比）->刷新或點(diǎn)擊人數(shù)（刷新或點(diǎn)擊人數(shù)占比）->點(diǎn)擊人數(shù)（點(diǎn)擊率）->閱讀時(shí)長(zhǎng)/停留時(shí)長(zhǎng)（讀完率、閱讀進(jìn)度）->跟帖/收藏/分享等互動(dòng)行為（互動(dòng)率）->回流人數(shù)（回流率、病毒傳播系數(shù)）

以上環(huán)節(jié)怎么對(duì)應(yīng)上埋點(diǎn)？

根據(jù)行為屬性，埋點(diǎn)事件大致分為以下幾類，并不唯一：

埋點(diǎn)事件下的信息怎么看？如item_id:”114774”，冒號(hào)前是字段（key），冒號(hào)后是值（value），//后的是注釋。

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

字段注意點(diǎn)和應(yīng)用場(chǎng)景：

1. item_id：內(nèi)容id，易錯(cuò)傳為序列id
2. type：內(nèi)容類型，如圖文、視頻、音頻，可區(qū)分內(nèi)容類型作分析
3. referer_id：上一頁(yè)面內(nèi)容id，可用于相關(guān)推薦業(yè)務(wù)的分析
4. _pt/_pi/_pm系列：定位頁(yè)面和模塊，可用于不同業(yè)務(wù)線的分析，例如首頁(yè)、要問(wèn)頻道、正文頁(yè)等
5. _pre_系列：追蹤了上一級(jí)頁(yè)面，可用于用戶行為路徑分析

除了關(guān)注字段的定義和場(chǎng)景外，還需留意上報(bào)時(shí)機(jī)，定義盡可能周全，就以此視頻瀏覽事件為例：

1. 頁(yè)面退出（銷毀）時(shí)：點(diǎn)擊返回等
2. 切換到其他視頻：點(diǎn)擊上下集，點(diǎn)擊相關(guān)視頻等
3. 按home鍵退出時(shí)
4. 鎖屏?xí)r
5. app殺死時(shí)

以刷新事件（_fsE）為例：

1. direction：可供產(chǎn)品汪區(qū)分上拉、下拉作刷新行為的分析。你可能會(huì)發(fā)現(xiàn)，除自動(dòng)刷新外，大部分用后喜歡上拉刷新，但下拉刷新的廣告位更值錢（有問(wèn)題存在就有工作要做了）。
2. auto_type：在新session，打開app到達(dá)首頁(yè)會(huì)有一次自動(dòng)刷新（即用戶沒有手動(dòng)操作），可用于分析用戶主動(dòng)刷新的行為。

以評(píng)論事件（_cmE）為例：

從以上埋點(diǎn)，我們能獲取哪些數(shù)據(jù)？

每篇內(nèi)容的評(píng)論數(shù)，可區(qū)分內(nèi)容類型、欄目、評(píng)論類型、位置；結(jié)合獲取到的用戶id，還可以從用戶維度分析。

以上埋點(diǎn)字段僅做示例說(shuō)明，需要根據(jù)實(shí)際的數(shù)據(jù)需要來(lái)增刪字段，定義要明確，場(chǎng)景要詳盡，避免出現(xiàn)“想要分析次均閱讀進(jìn)度，卻發(fā)現(xiàn)沒有相關(guān)字段”的窘境。

五花八門的用戶id

用戶id是用戶的唯一標(biāo)識(shí)，是該用戶在應(yīng)用里活動(dòng)的“身份證”，但它在獲取的時(shí)候可是五花八門的，曾經(jīng)某產(chǎn)品汪提供的deviceid和數(shù)據(jù)分析師手上的uuid完全對(duì)不上，ab實(shí)驗(yàn)得重做，所以懂多點(diǎn)兒概念提前問(wèn)一問(wèn)準(zhǔn)沒錯(cuò)。

（用戶id獲取示例）

以iOS系統(tǒng)的用戶id獲取為例，先補(bǔ)充幾個(gè)概念。

1. IDFA（廣告標(biāo)識(shí)符，Advertising Identifier），是蘋果公司提供的用于追蹤用戶的廣告ID，同一手機(jī)的不同APP對(duì)應(yīng)著相同的IDFA，IDFA可通過(guò)以下步驟重置：設(shè)置-隱私-廣告-還原廣告標(biāo)識(shí)符。因?yàn)镮DFA會(huì)存在取不到的情況，因此需要選用其他的ID作為DeviceID。在取不到IDFA的情況下，選用IDFV。
2. IDFV（Vindor標(biāo)示符，IdentifierForVendor），一般用于追蹤用戶在應(yīng)用內(nèi)的行為，每個(gè)設(shè)備在所屬同一個(gè)Vender的應(yīng)用里值是相同的。如果用戶刪掉了該vender的所有APP，IDFV將會(huì)被重置。
3. UUID（通用唯一標(biāo)識(shí)碼，Universally Unique Identifier），通用唯一識(shí)別碼，每次生成均不一樣；第1次生成后UUID后，需要保存到鑰匙串（keyChain）中；應(yīng)用被刪除再重裝時(shí)，仍然可以從鑰匙串得取到UUID；在一臺(tái)設(shè)備上，同一個(gè)開發(fā)者賬號(hào)的所有APP，可獲取到相同的UDID；刷機(jī)或者重新安裝系統(tǒng)后，UUID將重新生成。

鑒于沒有任何一種標(biāo)識(shí)符能百分百準(zhǔn)確獲取，且為了盡可能獲取用戶id，會(huì)有一個(gè)退而求其次的獲取邏輯，即先取IDFA的值，取不到IDFA時(shí)去取IDFV的值，再取不到時(shí)IDFA時(shí)，則生成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

埋點(diǎn)踩過(guò)的坑

字段和值

• id字段指內(nèi)容id，錯(cuò)傳序列id，導(dǎo)致無(wú)法讀取用戶瀏覽的內(nèi)容，丟失用戶閱讀歷史（影響個(gè)性化推薦）。
• 當(dāng)內(nèi)容是合集時(shí)，item_id傳合集id還是主視頻id需提前定義

上報(bào)時(shí)機(jī)

• 需明確定義，如：不同端的文章瀏覽事件切換前后臺(tái)時(shí)的上報(bào)時(shí)機(jī)需統(tǒng)一，Android切前后臺(tái)都上報(bào)，iOS僅切前臺(tái)時(shí)上報(bào)，導(dǎo)致兩端的人均閱讀數(shù)差異大。
• 需正確上報(bào)，如：視頻瀏覽事件出現(xiàn)同一個(gè)用戶的同一條數(shù)據(jù)重復(fù)上報(bào)（事件、時(shí)間戳、用戶id等都相同），使統(tǒng)計(jì)的瀏覽量偏大。

統(tǒng)計(jì)

• 栗子1：過(guò)濾瀏覽事件中時(shí)長(zhǎng)>=10 ms 和? ? ?時(shí)長(zhǎng)<10000000 ms 的異常數(shù)據(jù)。
• 栗子2：過(guò)濾刷新事件中單個(gè)用戶每天幾千幾萬(wàn)次刷新的異常數(shù)據(jù)。

埋點(diǎn)注意點(diǎn)

1. 埋點(diǎn)問(wèn)題需跟版本修復(fù)，bug修復(fù)周期長(zhǎng)：手動(dòng)埋點(diǎn)如果出現(xiàn)漏埋或埋錯(cuò)的情況，必須依賴下一個(gè)版本發(fā)版，才能看到數(shù)據(jù)（發(fā)版還需時(shí)間覆蓋，很傷），想周全+多測(cè)試=高效率
2. 定義明確，格式規(guī)范，正確上報(bào)
3. 測(cè)試環(huán)節(jié)很重要（老生常談）

日常反饋bug姿勢(shì)

產(chǎn)品汪反饋bug是家常便飯，甩個(gè)bug截圖可能會(huì)被忙碌精分的開發(fā)直接無(wú)視，掌握反饋bug的正確姿勢(shì)：

1. 截圖
2. 提供自己的app賬號(hào)或手機(jī)信息
3. Android：提供imei（手機(jī)數(shù)入*#06#可自助查詢）
4. iOS：提供idfa（抓包查詢）
5. 說(shuō)明時(shí)間和場(chǎng)景，給開發(fā)補(bǔ)充上下文，方便定位問(wèn)題

走上述流程，開發(fā)一定覺得你可愛無(wú)比。

結(jié)語(yǔ)

只要產(chǎn)品仍在迭代，就需要更新埋點(diǎn)以供數(shù)據(jù)分析使用，可以說(shuō)埋點(diǎn)將伴隨產(chǎn)品終生，攜手埋點(diǎn)，頭發(fā)也將越來(lái)越少，且行且珍惜。

本文由 @張小喵Miu 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議。