轉載原文（https://mp.weixin.qq.com/s/E6ETEUikyjAYFdDr-2ipYQ）

第一章：初始埋點

第二章：埋點之前

第三章：設計埋點

第四章：注意事項

第五章：管理驗收

第六章：埋點實戰

前言

什麼是埋點

數據埋點是數據採集的一種重要方式，主要用來記錄和收集終端用戶的操作行爲，其基本原理是在App/H5/PC等終端部署採集的SDK代碼，當用戶的行爲滿足某種條件的時候，比如進入某個頁面、點擊某個按鈕等，會自動觸發記錄和存儲，然後這些數據會被收集並被傳輸到終端提供商，或者是通過後端採集用戶使用服務過程中的請求數據。

一個典型的埋點採集處理流程如下圖所示

埋點的用途

終端提供商在收集到埋點數據之後，通過大數據處理、數據統計、數據分析、數據挖掘等加工處理，可以得到衡量產品狀態的一些基本指標，比如活躍、留存、新增等大盤數據，從而洞察產品的狀態。此外更重要的是隨着數據挖掘等技術的興起，埋點採集到的數據在以下方面的作用也越來越凸顯：

驅動決策：ABtest、漏斗優化、用戶增長、bug修復、精準營銷、流失用戶預警
驅動產品智能：智能推薦(千人千面)、場景化提示(私人助理)等
驅動安全：風險識別

埋點的分類

從位置上分爲前端埋點和後端埋點，從形式上分爲顯性埋點和隱性埋點，從路徑上又可以分爲路徑埋點和獨立埋點，從需求上分爲業務埋點和監測埋點。

由於埋點的主要操作過程是以終端的交互界面爲基礎，制定數據採集的方案，其它的埋點分類也只是從不同的角度來進行埋點設計。前端埋點是當前主要採用的埋點方式，下面主要對前端埋點進行闡述。

一、前端埋點

前端埋點是在用戶端(APP、Web、客戶端)等嵌入數據採集代碼，比如友盟等均採用的是前端埋點，比如通過嵌入一段代碼就就可以對網頁數據的訪問數據進行採集。相比於後端埋點，前端埋點能方便收集到用戶在界面上的行爲數據，比如用戶點了哪個按鈕、頁面之間的跳轉次序、停留時長等，這些數據是後面進行數據分析的主要來源。

前端埋點技術有以下三類：

代碼埋點

代碼埋點是直接將採集SDK集成在終端，然後不斷在此基礎上添加調整採集方案，是目前主流的埋點採集方案，其優缺點如下：

優點：

高度定製、控制精準、採集的數據豐富準確

缺點：

首先是每當有采集需求，需要開發人員不斷添加採集代碼，工作量大；
其次變更採集策略，需要發佈新版本，代價巨大，存在滯後效應；
最後由於採集代碼常駐終端，不斷將採集的用戶行爲數據進行記錄和上報，對於終端尤其是移動終端來說還有耗電、消耗數據流量等負載，此外在數據上報傳輸的過程中也存在丟失數據的風險。

可視化埋點

由於代碼埋點需要終端開發人員來執行採集方案，對業務的功能開發侵入性較高。有的公司開發出了可視化埋點技術，只需要產品與運營人員通過GUI界面進行鼠標簡單點擊，就可以隨時增加、取消、調整採集數據的位置和方式，此種埋點方式避開了終端開發人員的介入，由需求人員直接執行採集，減輕了需求傳遞過程中的信息損耗和誤解，另外可視化埋點技術往往由服務端直接下發採集的配置文件，而不用跟隨版本發佈，從而加快了數據採集的流程。

具體實現方式參考：

具體實現是SDK定時做界面截圖，在截圖的同時從界面UI的根對象開始遍歷所有的可視化子對象，得到其層級關係。根據截圖和UI元素的可視化信息重新渲染頁面，識別可埋點的控件。當產品人員在後臺管理端的截屏畫面上點擊可埋點控件，設置事件關聯方面的配置，服務器保存這些配置，客戶端在獲取到這些配置信息以後，按照新配置採集數據。

無埋點

無埋點與可視化埋點原理基本一致，區別在於無埋點是先遍歷所有的控件和操作行爲的組合情況，然後將這些組合情況交給埋點後臺，由數據分析人員選擇對哪些組合的埋點數據進行分析，其優缺點如下：

優點：

收集數據全面，無漏報

缺點：

採集數據量巨大，增加了終端流量消耗和服務器存儲負擔。
埋點的上報時機相對呆板，不能靈活的根據特定的場景進行特殊設置

前端埋點的注意事項：

頁面和控件標示上報要從頂層進行合理的設計，層次感要明顯
埋點數據的漏報和重複上報如何衡量
前端埋點不僅可以處理不需要和服務器交互的曝光和點擊事件，也可以將與服務器交互的結果，比如關注成功、分享成功、優惠券領取成功等原屬於後端埋點裏的事件放在前端來上報。

二、後端埋點

後端埋點爲了避免前端埋點的以下問題：

前端埋點需要對採集的數據壓縮、暫存，爲減少移動端的數據流量，除一些需要實時上報的重要事件不限制網絡環境，其它事件一般只在wifi情況下上報，因此數據會有延遲，丟數據等弊端，而在後端採集數據，由於數據是在內網傳輸，數據傳輸的即時性強，丟失數據的風險小。
前端埋點採集程序由於需要常駐，監測實時和延遲埋點上報，不可避免的帶來額外的耗電。
前端埋點若要新增或調整採集方案，需要開發人員修改客戶端代碼，然後發版之後才能解決，受發佈週期的影響較大，而且通常用戶的版本更新並不會及時，這將導致新方案不能及時覆蓋所有用戶。雖然現在部分埋點管理後臺也支持熱配置更新，但功能一般都很弱，只支持一些基礎的埋點事件熱更新部署，

注意：

很多時候並不把後端埋點獨立出來，而是混合在前端埋點中，等用戶和服務器端的交互返回結果之後，將結果進行上報。
對一下需要精確採集的數據，比如代金券發放等，實施的時候儘量採用後端埋點，除非後端無法採集到所需要的數據，前端埋點只是用來參考。此外也可以將業務數據庫代金券領取數據同步到數據倉庫中進行分析。

三、其它埋點

路徑埋點和獨立埋點

這部分的埋點根據業務對路徑的追蹤需求和SDK的開發能力，可爲每個事件設計上下文的路徑信息，路徑信息的組成一般由頁面、控件、行爲三部分組成，而路徑的深度也不宜太深，一般小於五層。

顯性埋點和隱性埋點

顯性和隱性是從用戶有感和無感來區分的，有感事件是用戶的主動事件，比如展示和點擊事件；無感事件主要用來處理後臺的數據請求和拉取，用以監控和服務器的數據交互是否正常等，無感事件中常用的是掃描採集，比如app啓動之後，掃描各設置開關的狀態信息進行上報等

業務埋點和監測埋點

業務埋點是從業務需求的角度而言，比如產品需要統計某個頁面的曝光和點擊，算法人員需要的推薦項點擊率等；而監測埋點是從業務的流程上來講的，一般是指隱性的（比如服務器交互的內容拉取情況、本地潛在信息的生成情況等），此外業務埋點中的關鍵部分也可以用作監測埋點。

參考資料

一些資料參考：

可視化埋點參考：https://github.com/mixpanel
無埋點參考：https://www.growingio.com/
產品經理如何做數據埋點：http://www.woshipm.com/data-analysis/1347283.html

常見的埋點平臺參考：

growing io： https://www.growingio.com/
神策： https://www.sensorsdata.cn/
諸葛ＩＯ： https://zhugeio.com/
talking data: http://www.talkingdata.com/
友盟： https://developer.umeng.com
百度統計： https://mtj.baidu.com/web/welcome/login
Google Analytics: https://analytics.google.com
數獵天下DataHunter：https://www.datahunter.cn/

埋點之前

瞭解產品

所謂磨刀不誤砍柴工，埋點設計是和產品密切相關的，對產品熟悉可以極大的加快埋點設計的進度。瞭解產品可以從以下方面入手

瞭解產品的交互

自己親自下載安裝下負責的應用，隨意的操作點擊，將產品提供的功能服務都嘗試一遍，初步劃分出產品的幾大模塊，建立初步的感知。

梳理產品的信息流結構

在感知的基礎上，將產品的提供的功能抽象出幾個實體，然後畫出這些實體是如何隨着用戶的操作進行流動的，西什麼樣的形式展現的，提供了哪些交互入口。

瞭解產品的未來規劃

多個產品經理溝通下，詢問下產品目前的定位，近期的計劃，和未來的規劃，這些信息可能暫時對你的幫助不大，但當你設計埋點的時候，這些信息貴潛意識的影響你的設計方法，以更好的兼容未來產品的改變。

梳理舊需求

埋點的很大一部分用途是爲了做報表呈現當前產品的大盤狀態，比如整體的新增、活躍、留存、迴流，以及各個功能模塊的使用情況。通過對舊需求的梳理，你能明白產品關注哪些指標，是從哪些角度進行分解的，有哪些度量方式此外嘗試着將這些指標梳理成體系，比如哪些是技術指標，哪些是業務指標，哪些是故障指標等，對需求的梳理也是同樣的邏輯。

梳理舊埋點

根據作者的瞭解，絕大部分的公司都沒有埋點管理系統，大多都是以excel的方式進行管理，雖然excel管理也不是不可行，埋點的形式天然就具有表格的樣式，問題在於埋點人員對埋點管理的認識參差不齊，所以埋點文檔百花齊放，紛繁複雜，混亂不堪是常見的。但舊埋點的梳理是必不可少的，試着多向以前的埋點人員瞭解下，建立app上的交互和埋點文檔中事件的對應關係，對快速展開埋點工作大有裨益。

熟悉埋點流程

要做好一件事，必須知道其具體流程，埋點雖然聽起來簡單，其實也是一個系統性的工程，需要各方共同參與。以當前主流的前端代碼埋點爲例，埋點牽涉到產品經理、數據產品經理、數據開發、業務開發、數據測試五個角色，在一些企業的設置中可能並沒有數據產品的角色，其角色就會有數據開發來兼任，此外很多的數據測試也是由業務測試來兼職的。但不管角色的多少還是兼職，埋點所遵循的流程改動並不大。埋點開發的通用流程如下圖所示：

角色職責

產品經理：輸出策劃文檔、統計需求(一般是以報表需求的形式呈現，也是數據產品埋點轉換的重要參考)
數據產品經理：負責進行埋點轉化，對埋點的完整性負責，其一般有兩個轉化參考點,一是策劃文檔，根據相應的改動增加相應的曝光、點擊等埋點事件，另一個參考就是報表需求文檔，通過完善已有的埋點(常見的有增加參數、增加參數值等)或者增加新的埋點來支撐報表需求。
數據開發：根據產品輸出的埋點轉化文檔，進行埋點設計，具體體現爲埋點參數名、參數值、上報時機等，對埋點的準確性負責。業務開發：根據數據開發輸出的埋點設計文檔，根據響應的觸發時機，將事件相關的設計的附屬信息按指定的格式進行上報，對埋點植入的正確性負責、對採集數據的完整性負責（漏掉一些上報時機是很常見的事）。數據測試：根據業務開發的上報，通過測試用例抓包的方式驗證數據的上報是否和埋點設計的一致，驗證一致後發起埋點驗收報告。

注意

產品提出統計需求的時候，需要用到哪些數據最好能先和開發溝通一下，是否能獲取到，可以極大的減少在埋點需求和設計評審時討論開發能否實現的耗時。
數據測試發起埋點驗收報告的時候，上報數據要經過篩選，只覈驗本次埋點設計改動的地方，並見埋點設計的改動和上班數據的對應關係標註出來，可以極大的加快數據驗收的進度。（數據驗收目前還有很多的挑戰，比如我參數值的層級組合等，只能做簡單的自動化）

埋點設計

漏斗思維

漏斗思維即分階段思維，是從流水線的角度考慮問題，追蹤整個鏈條，具體有以下兩種形式。* 同一事件的不同階段在埋點設計中時常會遇到一些持續性的事件，不是在瞬間完成的，比如播放、下載等，都存在這一定的持續階段，對於這樣的非孤立事件，要設計一個鏈條進行追蹤，在埋點設計中常用會話的方式表示，比如可以採用開始時間戳的方式作爲會話id,每次事件開始都會生成不同的事件id。此外在設計埋點的事件名的時候也應該顯著的進行區分，比如用同一個事件，然後在該事件的屬性參數中選擇一個類似step的參數來代表該事件的不同階段，若每次事件的消費對象具有唯一的標示符如indentid，這樣就可以使用imei+eventid+step+indentid這四個值串聯了該次事件的整個過程。也可以用不同的事件名進行串聯事件(或者過程)的不同階段，如下圖彈窗的上報邏輯：

同一事件的不同平臺不同平臺的串聯簡單來說是入口要做統計，出口也要統計，做好銜接，形成一個完整的漏斗。以分享爲例，客戶端的分享（點擊開始分享、分享結果返回）要做埋點，分享出去的頁面的展現和點擊也要設計埋點，在設計埋點參數的時候要注意加入加密處理過的用戶標示、分享來源標示等，代表一次完整的分享會話，做好跨平臺之間的信息透傳，避免鏈條中斷或者模糊。這裏需要強調的是不同平臺的串聯容易泄露用戶數據，要注意加密處理進行隱私保護。

層次思維

層次思維的是指在進行埋點設計的時候，要有將頁面邏輯、事件過程、擴展參數等設計的有層次感。不僅可以方便對埋點進行查找，而且可以在更高維度上概括。具體體現在以下方面：

交互層次

交互層次主要處理母頁面和子頁面的展現和點擊事件，對於某些app爲了界面上的清潔，對一些行爲操作進行了摺疊，常見的場景如點擊更多，出現分享、保存等操作按鈕，長按評論，出現刪除、複製、舉報等操作，這些在彈出界面上的簡答操作可以上捲到母頁面上進行處理，比如原來的母頁面上評論有點贊和回覆兩個點擊位置，則子頁面上點擊上卷之後，就有點贊、回覆、長按_複製、長按_刪除四個點擊位置，其中以長按代表子頁面上的點擊，這樣上報更加清晰明瞭。但需要注意的是對於一些複雜的功能多樣的子頁面，要將這些頁面當做普通的頁面進行處理，並在頁面相關的事件上進行普通頁面和彈出頁面的屬性區分。

屬性層次組合

屬性層次常見於具有複雜參數上報的事件中，屬性的參數值之間存在層次的組合關係，比如A參數取值爲A1的情況下，B參數有B1,B2取值的可能，而當A參數爲A2值的情況下，B參數有B3、B4取值的可能，像這種同一事件屬性層次的組合關係又適合拆分成多個事件的情況下，建議使用參數組合表進行設計的展示，可以極大的方便開發處理各種邏輯和測試案例的完備性。

屬性層次包含

屬性層次包含是指在參數取值具有很明顯的分類情況下，設計更高的層次來給每個類進行命名。比如參數A具有A1、A2、A3、A4...A9一系列值，A1、A2屬於類C1，A3屬於類C2，A4...A9屬於類C3，若這一些列值存在明顯的可區分特徵，則在統計該類值過濾下相關事件行爲即可，若不存在，則需要很繁瑣的窮舉，不僅代碼臭長，而且當有新的該類值出現的時候，要不斷的修改統計代碼。此時若在參數設計上增加一個參數來進行C1、C2、C3的劃分，則可以輕鬆的解決剛纔的問題。

擴展思維

擴展思維是抽象思維的一種體現，越抽象的事物越容易擴展，但並不是說越抽象越好，把握號抽象的程度，可以有效的提高擴展性。

事件擴展

在設計事件的時候要有對業務擴展的預見性，比如一個app最初只具有發佈自拍視頻的功能，那麼在設計視頻發佈相關的事件的時候是否應該採用shortvideo_publish_xx呢？如果採用這種事件id的數據方式，若以後新增了其它類型內容的發佈，其基本流程和視頻的發佈基本類似，此時是將視頻發佈的相關事件流程重新複製一份，還是新增content_publish_xx事件，使用type參數來代表發佈不同的內容類型（排除視頻外的,就版本埋點事件要兼容），不論採用哪種設計，都會讓埋點變得混亂，而如果最終設計的時候就採用content_publish_xx的方式進行設計，則就整潔很多，很容易擴展。

屬性擴展

屬性擴展在屬性值的上報格式上體現十分明顯，此外擴展格式設計的時候要不影響已有數據的原始處理邏輯，表現在埋點上儘可能的採用增加屬性和屬性值的方式進行埋點，避免一大堆不可複用的垃圾事件，增加管理的難度。具體的措施如下:採用字典的方式進行埋點,儘量不要採用分隔符分割的列表方式，例如:vid1_vid2_vid3 對可能出現的邏輯進行頂層設計區分,在每層上同樣採用字典的方式對多個事件引用的同一屬性的枚舉值，建議用表分割出來，不要在每個事件上一個個地修改卡片類等點擊內容可能多個的情況，在設計之初就應該有clickid屬性用以區分點擊的具體位置針對點擊事件的針對性，比如針對某條評論的點擊恢復，點贊等，在點擊事件中要設計針對屬性。

分類思維

按位置、按模塊、按頁面、按功能等多角度進行分類，有時將行爲從頁面中獨立出來形成單獨的一類，比如如果app中在多個地方都存在分享、評論和點贊等功能，而這些行爲的統計又是經常使用到的指標，更甚至若在底層實現上這些模塊都繼承自同一個模塊，這就天然具有了在埋點設計的時候按行爲分類，而不是在每個頁面的位置上都單獨設計埋點事件。試想一下如果各個頁面維護各自的分享模塊，如果分享渠道增加一個，那麼是不是要更新所有頁面分享的埋點設計，追加響應的參數值(當然如果所有頁面雖然使用了不同的事件，但是維護的是同一份信息表就相對好些)。另一方面，如果指標體系十分關注app在不同位置、來源上提供的內容消費差異，則要求我們在進行行爲分類設計埋點的時候加入其來源相關的信息，並對來源按來源app(跨app的導流)、來源頁面（app內部）、來源控件（app內部的某一位置），比如下面的播放來源所展示的設計：

刷新流

刷新流又稱服務流，是在新聞資訊類APP中常見的交互形式，隨着用戶不斷的滑動，內容不聽的更新，根據刷新的方式有分爲全部刷新和增量刷新，而增量刷新有時候在頁面的頂部，有時在頁面的底部。對於刷新流埋點我們要終端關注上報的數據信息和上報時機。

上報數據：

refresh_num：第幾次刷新（0代表首次進入，沒有刷新）
refresh_id：刷新id(包括下拉刷新和加載更多)
refresh_type:是否系統自動刷新，sys-系統自動刷新，manual-用戶觸發刷新
position：元素刷新部分的位置(在每次刷新中的位置)
rn:元素位於列表位置(在所有刷新中的位置)
sessionid:用戶一次連續使用id(用戶首次進入首頁生成，頂部刷新時更新

上報時機：

一般先加入緩存，緩存滿多少條上報，或者結合一些其它的上報時機。上報完成之後清空緩存，新曝光的加入緩存，等待新的上報時機被觸發。
用戶來回滑動也正常加入到緩存中，回滑加入緩存不去重

列表式

曝光事件的處理是埋點設計中最難的部分，其中尤以上報時機和上報格式最爲考研埋點設計人員的能力，下面結合給出作者的經驗設計。

上報時機

曝光上報的一個基本原則是用戶可見(離開之後再次可見算二次曝光)，上報時機有以下幾種處理方式：

簡單式：

離開頁面的時候上報所有已曝光過的內容，但可能出現的問題對於刷新流的內容形式，一次上報的內容可能超出了限制，造成數據丟失。

混合式：

混合式的上報在簡單式的離開上報基礎上增加了緩存條數的觸發上報條件，緩存達到了指定數目之後，則將緩存過的數據進行上報，同時清空緩存等待新的曝光條目加入。

綜合起來，在處理曝光事件的上報時機的時候要充分的考慮以下場景：

緩存數據滿上下滑動等的重複曝光是否加入緩存快速滑動是否加入緩存
離開tab切換（內容是否刷新）實體鍵返回/軟鍵返回息屏（息屏之後解鎖）摺疊展開隱藏的內容浮層/彈窗等遮擋進下級頁面

上報格式

列表式的曝光常採用多條一起上報的方式，每個條目有共性和個性屬性兩部分，一般設計如下：

# 公共屬性
page:xx
src:xxx
# 個性屬性:個性元素之間用‘;’分割，同元素不同屬性之間‘,’分割 
contentlist:"a=1,b=2,c=3,d=4;a=5,b=6,c=7"

其中對於個性屬性的上報，又有以下兩種常用的方式（以今日頭條新聞推薦tab下的列表項爲例）：

json嵌套

-- 多源埋點(info:string(json格式)) {
"page":"mp", /*不要求key唯一,高擴展性*/ "contenlits":[
{"type":"娛樂","auth_id":"111","rn":1,"id":"v111"}, {"type":"政治","auth_id":"222","rn":2,"id":"v222"}, {"type":"科技","auth_id":"333","rn":3,"id":"v333"},
],
/*要求key唯一*/ "contentlist2":{
} }
"v111":{"type":"娛樂","auth_id":"111","rn":1}, "v222":{"type":"政治","auth_id":"222","rn":2},

固定分割

# 內容公共屬性 
page:mp
# 內容個性屬性 
contentlist:
"type=娛樂,auth_id=111,rn=1,id=v111; type=政治,auth_id=222,rn=2,id=v222; type=科技,auth_id=333,rn=3,id=v333;"

注意事項

在處理曝光內容的時候，有以下幾點需要提前考慮：

重複曝光是否計算在內，即集合和列表的區別。
懸浮的授權彈窗下的頁面曝光，需要授權彈窗消失後才能上報

點擊相關

點擊延後

點擊埋點的上報時機一般不存在疑問，即點擊發生時候或者點擊結果返回時上上報，但在處理一些特殊場景的時候合理的制定上報時機，會給後續數據處理帶來極大便捷性。典型的使用場景是單頁面批量操作，具體如下：

單選或多選、然後一起操作(操作結果:關注/刪除/移動)
單選，每個選擇有單獨的操作結果(頁面不發生跳轉)，整個頁面是每個操作的結果組合

以上兩種場景，建議離開當前頁的時候上報該頁面操作的結果，可以選擇上報所有操作之後的最終態，也可以記錄修改態(增什麼減什麼保留了什麼，開什麼關什麼不變什麼)

點擊附着

具有附加信息的點擊事件上報，建議單獨拿出來，這是因爲每個點擊對象都導致不一樣的結果，而這些結果有時候又沒有共性(有共性的情況下可抽象成一個點擊事件)。具體的點擊附着場景如下：

點擊評論這個事件，就附着了評論的id、評論作者的id等信息，如果歸結到統一的點擊事件，就需要加額外的信息。而這些信息是其它的點擊事件所不具備的，例如點擊返回(就沒有附着的對象id)
點擊具有跳轉能力的對象，就要記錄點擊的位置，跳轉前的屬性(比如當前url)和跳轉後的屬性(比如跳轉url) - 點擊具有紅點提示和消息條數提示的控件，則需要上報控件的狀態(是否有紅點或消息條目的多少)
點擊具有附帶結果，比如關注等，附帶結果是否要上報(牽涉到上報時機)

點擊信息表

對於某些特殊的入口型應用，或者具有豐富內容形態的產品，有很多的交互設計，點擊不同的地方，跳轉不同的位置，甚至相同的位置，隨着後臺的配置不同而跳轉不同的地方。這種具有豐富的複雜的跳轉關係情況下，如果繼續採用屬性和屬性值堆疊的方式，不僅不能很好的體現屬性值之間的組合情況，以便測試和其它人員進行鍼對性的測試，也不利於使用人員快捷的進行點擊信息的統計，此時建議採用信息表的方式來設計，其形式如下：

點擊區分	點擊位置	跳轉區分	跳轉地址
按鈕/非按鈕等	具體點擊的位置	應用自身、第三方等	具體跳轉目標

說明：

點擊區分重點按是否點擊率計算的分之來區分
跳轉區分是否跳轉跳轉到應用自身還是第三方
跳轉地址若是應用內部的跳轉，直接用對應的頁面編碼即可應用外部的跳轉，若是拉起具體的應用，則給出具體的包名，若是地址形式，則直接給出地址

聯動演化

聯動

聯動是指顯性的某些操作引起其它地方狀態改變的一些關聯變動（而這些變動同樣可有其它的顯性操作引起），這個時候要注意被聯動的狀態改變的上報（同時也要注意區分出狀態改變的原因），這些聯動可以是層級的關係（上層關閉，下層自動關閉），也可以是平級的關係。比如一些內容服務類的app，提供內容類型的關注，並同時可定製內容子類型，當子類型全部刪除後，則父類型自動取消關注。這種情形下，父類型的取消關注就會有兩種方式，一種是直接取消父類型，一種是通過對子類型的操作聯動父類型的改變。另外一些隱性的聯動也可以通過事件映射的方式下沉到埋點層解決，如果沒有這個將同類型操作結果的事件在底層映射成一個，很容易造成埋點遺漏，如果後面又利用此事件建立了開關累積表，則統計的準確性大大降低，而且修復起來也很複雜。

演化

演化是指在一個行爲發生的過程中該行爲附帶的屬性會發生變化，比如在一次播放過程中清晰度的切換、暫停和繼續、播放器界面的小屏和大屏切換等，或者隨着時間推移彈窗內容的改變等，這些存在演化的行爲，一般的建議是用一個標示符串聯起來，比如播放用的sessionid串聯一次完整的播放，下單過程的產生訂單id（注意區分成功之後的訂單id）,在某些場景要求不細的情況，可合併到事件的某個階段一起來上報，不用拆分階段來追蹤整個鏈條。

埋點注意事項

同質一致

相同指標度量的上報時機和格式一致，比如:

實體返回鍵和app返回鍵及空白位置的點擊clickid統一處理成return
頁面停留時長信息的上報，其上報時機爲離開頁面的時候，時長單位ms
多同質元素的曝光，用統一的上報格式，如下：

 a=x,b=x,c=x;a=y,b=y,c=y #或者
  a=x&b=x&c=x,a=y&b=y&c=y 

  #此種格式十分利於後期處理：
  select
      str_to_map(pos,',','&')  # 轉化爲字典
  from db.tbl
  lateral view explode(split(cotentlist,','))ed as pos
  where xxx rlike '_list_show$'  # 此處多內容曝光事件的事件命名應該規範，和其它形式的內容曝光進行區分

曝光和點都採用列表的方式，在統計該位置的點擊率的時候，若點擊事件的上報和曝光事件的上報格式一致，可極大的提高效率

同質參數的名稱和類型應該保持一致

同質參數的設計一致主要體現在普通參數、維度參數、行爲標識上，雖然這些要求是數倉規範上介紹的，但如果能事先治理，在數據採集的時候就規範化，其能減輕的工作量是巨大的。以下是一些通用的詞根：

普通字段

名稱	意義	備註
渠道	channe	一般是渠道編號
版本	version	若同時有多個版本，加前綴
包名	package	一般在上報層處理爲小寫
來源	from
目的	to	qq/wechat/weibo/friends等

行爲字段規範

行爲	命名建議	備註
點擊	click
曝光	show
分享	share
評論	comment
點贊	like
舉報	report
安裝	install
下載	download
升級	upgrade
退出	exit

注意：命名規範的應該遵循相應的邏輯，先要理解現有的埋點規範，然後對其進行沿襲，最好設計之初就嚴格按規範來執行，可以有效的避免後面統一的時候需要考慮新舊兼容的情況。

同頁面同模塊的事件名基本一致

同一個頁面的點擊事件，應該從事件名上可以直接進行區分，如下：1、進入頁面即上報該頁面的pv，作爲分母(下滑等操作曝光的頁面上部分的內容再單獨上報各自的show事件)2、頁面各個部分的點擊遵循:頁面名_模塊部分名_click/show例如：

同質繼承

跳轉繼承

從A頁面跳轉到B頁面，只在B頁面的展現事件上報了from，而在B頁面的後續重點操作都沒有繼承最初進入該頁的from屬性，或者在B頁面的下一級需要重點關注來源的頁面也漏報了from屬性，都是繼承中斷的情況。

初始繼承

初始繼承是指在用戶當天（或者更長日期）首次發生某種行爲的時候，該行爲即成爲用戶的一種標籤，在後續的其它事件的上報上都上報此標籤。比如記錄首次啓動的方式，桌面圖標的啓動的，則標註爲圖標啓動用戶。雖然後臺的數據處理可以計算出用戶的這些首次行爲標籤，但是多個行爲的時候可能會存在計算量大的情況。

通用複用

該準則的要求是儘量少的創建新的事件，而是想法複用原來的事件，這不僅是減少事件數量，方便後續的埋點管理，同時在思考能否複用的過程中，也是對自己埋點設計的能力的一次檢驗，檢驗埋點設計的擴展性如何。此處以彈窗的曝光和點擊爲例介紹

粒度平衡

粒度平衡指埋點粒度在最小化的原子粒度和抽象粒度概括之間要平衡，常見的有以下幾個方面：

時間粒度

時間粒度在盒子不變，其交互也不變，而盒子裏的內容通過左右滑動或者點擊跳轉而改變，簡言之就是複用同一套模板的交互情況下要特別注意。此處以某詳情頁的停留時長粒度來舉例：事件名：離開詳情頁事件id： x_detail_exit 上報時機：

點擊返回、切後臺等常規形式的退出
點擊頁面交互元素跳轉非同類模板頁
點擊相關推薦等進入同類模板頁

參數： stay_duration:停留時長，單位ms 在設計埋點的時候，該事件的停留時長參數就一定要精確到原子粒度，即單個內容的停留時長，而不是該類頁面的停留時長。基於單個時長可以統計同類時長，若埋點粒度太粗，就沒法分解，這樣在計算類似TopN條目的情況，埋點數據就無法支撐了。

事件粒度

雖然我們在設計埋點的時候要求採集的信息要完善，不能漏採，但並不是意味事件的上報並不是越多越好，要全但是不要濫，至於上報哪些事件，則要從整個產品交互邏輯和漏斗分析的重點對象出發，在滿足版本迭代功能需求統計基礎上，不斷補齊漏斗環節。

事件的串聯此外事件粒度也體現在埋點設計上，可以將一個串的事件用一個時間id，而在params裏使用attribute1這個參數來代表不同的階段，進行了埋點展平，同時這樣的拆分設計也可以避免在不同的階段下，附帶的參數不一致，而需要不斷的說明層級的關係。

時間粒度的上報數據量度量此外在處理類似心跳事件這樣可能造成大量數據上報的情況，要有事前的預估，如果可能超出數據的接收能力，則在客戶端進行選擇性的上報，但要注意上報樣本的均勻合理，能夠反映總體的特徵。

埋點管理和驗收

管理目的

埋點管理主要有三大目的：方便查詢、方便協同、方便驗證。

方便查詢

因爲埋點是最底層的元數據，在查詢報表系統上沒有展示的數據時候，產品、運營等可以將需求拆解爲統計什麼頁面上的什麼行爲，根據頁面和行爲的簡單拆解，通過埋點系統找到對應的埋點設計，然後根據埋點設計從原始的上報數據中查詢即可。

方便協同

在第二節《埋點之前》中，我們介紹到埋點設計的過程中，需要產品、數據產品、數據開發和數據測試一起協同工作，而協同的根本就是埋點設計文檔，而埋點設計文檔是隨着終端版本的更新而不斷更新的，如何將這些更新準確地傳達給各方，讓協同高效，這是埋點管理的重點職責。

方便驗證

在選擇何種埋點管理方式的時候，一個重要的考慮點是能否將埋點設計的變更導出成可自動化測試的規則，從而可以在測試數據上快速的驗證數據是否有上報、格式是否正確、各種情況是否窮盡等。

管理準則

埋點管理需要遵循以下準則：歷史兼容、追蹤回溯、備註完善

歷史兼容

歷史兼容是指在埋點設計的時候，有以下三個不可改變:

不能改變已有事件標示（事件id等）代表的事件含義
不能改變屬性標示代表的含義
不能改變參數值代表的含義

基於以上三個不可改變，埋點設計只能在原有事件的基礎上新增屬性、新增參數、新增參數值，也可以在適當的時候廢棄某些事件、參數、參數值。

雖然可以隨着版本的迭代也容許事件、參數、參數值的含義進行改變，但是十分不可取的，不僅要在改變的過程中詳細的記錄，而且過度期間數據開發要很好的兼容遷移前和遷移後，待基本完成遷移後，還要精簡程序。這無疑帶來了很大的工作量。

也正是由於歷史兼容的準則，受三個不可變的約束較強，在埋點設計之初就要進行合理的規劃和佈局，避免後期不得已進行埋點重新設計時帶來的混亂。

追蹤回溯

追蹤回溯功能是埋點出現問題的時候排查的重要利器，要求埋點設計文檔可以回退到任何版本的埋點快照（事件、屬性和屬性值級別），同時可以追蹤的對應的操作人（埋點設計者、埋點開發者、埋點測試者等）。

備註完善

備註完善要求詳細的標註出事件的上報時機（策略）、參數取值的具體含義，參數值計算方式和單位（尤其是時長類的參數值）、埋點針對的具體點頁面位置。

管理方式

不管採用哪種管理方式，都應該記錄該埋點涉及的相關人員：

埋點類型：

算法/業務（產品、運營）/監測/數據
需求人員
開發人員
測試人員
轉化人員：數據產品經理（單一，一般可不寫）
設計人員：大數據開發（單一，一般可不寫）

不管採用哪種管理方式，都要求輸出埋點的改動信息如下：

版本改動：新增xx事件，事件參數有a,b,cxx事件新增a參數xx事件的a參數新增xx值
版本快照：該版本生效中的所有事件和參數
版本對比：xxa版本和xxb版本對比新增了什麼，刪除了什麼，改動了什麼。

同時在用戶體驗上，當鼠標懸浮在某個事件或參數上面的時候（或者點擊旁邊的問號），可以給出該事件或者參數的歷史變更記錄。

Excel表格：

修改摘要

修改內容

修改內容的維護是通過手動版本記錄實現的

管理系統

採用該管理體系統的目的是方便的事件和屬性添加修改，版本間對比的修改記錄，版本快照，完善的註釋（支持圖片和文字）、一鍵驗證、修改自動通知到干係人等。

備註：本部分只講解了單個產品的埋點管理，而埋點管理系統是要處理多個app的的埋點，後面完善。

權限管理

根據不同的角色設計不同的app、version、event_id、params增刪改查權限，尤其要注意權限的繼承

埋點驗收

埋點驗收是埋點設計的最後一環，是把控埋點質量的關鍵環節。

雙重驗收

一是客戶端通過抓包的方式確認數據的確有上報，二是通過數據倉庫提取的方式確認數據落地的形式是否和埋點設計一致的

驗收預警

一旦上報了不符合埋點設計的值自動預警，比如埋點設計中該參數只有a,b,c三個枚舉值，結果卻上報了d這個值，這個功能可以反過來保證埋點設計和埋點上報是嚴格一致的。

另外埋點的上報頻次和每次上報埋點數據量的大小也要在預估的範圍內，尤其是像加入心跳埋點這樣的事件，不然很容易就爆庫。

埋點驗收問題可以引出數據的自動化測試課題，見數據治理部分。

埋點實戰

信息架構

信息架構即提供的消費內容實體，簡言之就是app提供的功能，以及消費這些內容實體的路徑。比如極客時間的提供的消費內容實體主要有以下：

主實體

專欄

主要形式爲圖文和音頻，伴隨行爲有購買、閱讀文字、聽/下載音頻、分享（課程、內容）、評論（評論點贊、分享）

視頻課

主要形式視頻觀看，伴隨行爲有購買、觀看、分享、評論（評論點贊、分享）

每日一課

主要是視頻形式，存在視頻合輯等組織方式，伴隨行爲有購買、點贊、評論（評論點贊、分享）

備註：加看單行爲可視爲內容的路徑

微課

主要形式爲圖文和音頻，伴隨行爲閱讀文字，音頻（聽、下載）、分享（課程、內容請朋友讀）、評論、收藏（內容）、設置（內容）

附實體

特別放送

基於某個專欄或者話題的特別頁面，比如左耳聽風的ARTS打卡召集令等

資訊

一些技術分享、業界視點、產品動態等，圖文形式

新聞

一些技術分享、業界視點、產品動態等，音頻形式

商品

一些計算機書籍、大數據相關書籍，極客充值卡、極客周邊，以及其它

交互梳理

在消費內容實體上梳理出來的交互全景圖，主要從實體的消費類型，及對應的頁面和入口來分解，此外還附加的有一些不依賴於實體的公共的入口，比如登錄、搜索等。

界面入口梳理如下：

其中功能行爲的入口信息，也即路徑信息是要重點梳理的，比如以下登錄行爲的路徑梳理：

設計佈局

埋點設計的佈局以位置、行爲抽象、形式抽象、實體爲主進行管理，將路徑信息配置成信息表，關聯到相應的實體消費中，整體的設計佈局如下：

目錄	分類	介紹
發現tab	主界面	主實體和附實體的入口1，曝光和點擊等數據
講堂tab	主界面	主實體和附實體的入口2，曝光和點擊等數據
學習tab	主界面	主實體和附實體的入口3，曝光和點擊等數據
我的tab	主界面	主實體和附實體的入口4，曝光和點擊等數據
專欄	主實體	專利消費，含介紹頁、目錄頁、內容頁
視頻課	主實體	視頻課消費，含介紹頁、目錄頁、內容頁
每日一課	主實體	每日一課消費，含介紹頁、目錄頁、內容頁
微課	主實體	微課消費，含介紹頁、目錄頁、內容頁
附實體	附實體	含特別推送、諮詢、新聞，不包含商城
購買	關鍵行爲	主實體的購買，不包含商城
分享	關鍵行爲	實體的分享
評論	關鍵行爲	實體的評論，含發表評論、點贊評論、分享評論
設置	抽象行爲	APP的設置
播放	抽象行爲	音頻播放和視頻播放
彈窗	形式抽像	app內的各種推薦彈窗、活動彈窗、授權彈窗等，也是實體的快捷入口之一
通知	形式抽象	各種通知的曝光、點擊等，也是實體的入口之一
商城	業務拓展	記錄用戶在商城上的曝光、點擊、購買等

最終呈現的管理樣式如下（以Excel管理方式爲例）：

具體設計

經過設計佈局後，我們可以根據實體、界面、行爲三者快速的定位到具體的埋點。其它的佈局界面都是實體的入口深度，對入口的層級設計，對列表類型的曝光佈局，對操作類型的匯聚處理等，這裏是四大思維和四大場景的運用。

所有實體全局編碼，在各種行爲的上報上附加實體信息和實體的入口，此處以

專欄頁的曝光爲例

事件名	上報時機	事件id	事件信息
專欄介紹頁曝光	進入專欄介紹頁	sc_intro_show	from:參考本sheet的專欄內容來源
專欄介紹頁點擊	點擊發生時	sc_intro_click	from:參考本sheet的專欄內容來源 clickid:點擊位置
專欄目錄頁曝光	進入專欄目錄頁	sc_catalog_show	from:參考本sheet的專欄內容來源
專欄目錄頁點擊	點擊發生時	sc_catalog_click	from:參考本sheet的專欄內容來源 clickid:點擊位置
專欄內容頁曝光	進入專欄內容頁	sc_content_show	from:參考本sheet的專欄內容來源
專欄內容頁點擊	點擊發生時	sc_content_click	from:參考本sheet的專欄內容來源 clickid:點擊位置
專欄內容頁時長	離開專欄內容頁	scl_content_exit	from:參考本sheet的專欄內容來源 dur:停留時長

專欄內容來源信息表：

from	一級來源（端）	二級來源（一級頁面）	三級來源（二級頁面/部分）	四級來源（控件）
app/我的tab/推薦閱讀/	app	我的tab	推薦閱讀
app/講堂tab//	app	講堂tab
app/講堂tab/專欄列表頁/	app	講堂tab	專欄列表頁
app/學習tab/課程列表頁/	app	學習tab	課程列表頁
app/學習tab/筆記列表頁/全部	app	學習tab	筆記列表頁	全部
app/學習tab/筆記列表頁/專欄	app	學習tab	筆記列表頁	專欄
h5/x/xx/xxx	h5	x	xx	xxx
applet/x/xx/xxx	applet	x	xx	xxx

總結

本節先梳理了極客時間app的信息架構，根據梳理出的實體和功能等信息，進行了埋點設計文檔的佈局，最後給出專欄頁的一個埋點設計框架樣例。需要強調的是雖然埋點框架在很大程度上解決了埋點設計的檢索、管理和擴展問題，但更詳細的埋點採集信息等血肉的補充則是更加關鍵的內容，這個是在七天埋點設計之旅系列上無法傳遞和分享的，需要埋點設計人員根據業務特點和需求進行相應的調整。

數據埋點（轉載）

前言