上一章《埋點需求分析&設計埋點方案》已經說明了什么是埋點，埋點需求分析、數據指標、常見的埋點事件等基本概念。本周主要輸出整理埋點文檔的思路。
一、什么是埋點需求文檔
埋點文檔是一個對我們之前埋點需求分析結果的方案落地，上一章里，我們知道埋點分為前端埋點和后端埋點，我們常說的埋點文檔是指前端埋點文檔，通常由產品經理進行梳理。
首先，埋點文檔沒有一個固定結構。不同平臺，不同渠道，不同公司對于業務需求的不同，所產出的埋點方案都不同。但是通常需要包含：
● 應用標識：指當前應用的唯一標識，用來區分各數據來源于哪個的應用（站點）。
● 頁面名稱：即當前埋點所屬的頁面，有了這個頁面位置，才能知道這個埋點屬于哪個頁面的數據。通常我們埋點文檔中是根據頁面來劃分的。
● 埋點位置：即需要添加埋點的位置信息，比如一個收藏按鈕，一個分享按鈕，某一指定位的曝光區域等等。
● 埋點標識：每個埋點的位置有一個埋點標識，用來標記這個位置，有且僅有一個，不能出現標識重復的情況，不然統計到的數據一定有重復。
●?埋點參數：參數就是除了點擊這個位置帶來的點擊量，你還想看到哪些信息。比如點擊支付按鈕時，需要附帶支付方式，支付金額，支付流號等信息。
二、如何寫埋點文檔
1、選擇數據平臺
目前大多中小型公司都會選擇第三方數據平臺，少部分公司會自建數據平臺。目前知名的第三方平臺有：國外的Google Analytics、Mixpanel，國內的有友盟+、Talkingdata、百度統計、諸葛IO、神策數據，還有專注于游戲領域的dataeye等。
各平臺都能基本滿足業務需求，各有優缺點，具體選擇哪家需要各自進行權衡。我之前僅用過友盟、百度統計和諸葛IO，以上3家來講，我更傾向于友盟，除了數據統計，還提供推送服務、社會化分享、用戶反饋，功能十分強大。也有很多人推薦TalkingData，界面很清晰，功能也好用。
2、查看平臺技術文檔
選擇好平臺后，我們需要查看平臺的技術文檔。比如進入TalkingData的官文點擊App集成文檔，就可以查看相應的技術文檔了。
這需要開發按照操作說明把SDK集成到我們的APP中，而產品需要輸出埋點文檔。
如上TalkingData的自定義事件的文檔說明，其中包含代碼事件和靈動事件。TalkingData的靈動事件，是一種無需預先埋點，隨時可以按需配置即可實現的自定義事件追蹤方式。在正確集成SDK后，任何時候通過報表頁面設置，就可以實現自定義事件追蹤。
代碼事件是通過在代碼中對每個需要追蹤的自定義事件調用接口，傳入相應參數從而實現對自定義事件追蹤的方式。自定義事件需要定義的信息有：EVENT_ID(自定義事件名稱)，EVENT_LABEL(自定義事件Label)，Map（自定義事件的參數及參數取值Key，Value）。TalkingData自定義了標準事件，比如下單、成功支付訂單、瀏覽商品、加購、查看購物車。
一般地，如果所有事件都需要傳輸相同的參數，可以設置全局的Key-Value，這些Key-Value自動會添加到所有自定義事件中。比如操作系統（Android、iOS），渠道（小米，華為，app_store）、應用版本等。
設計事件大概分為三類：
● 常規通用事件：APP激活、APP退出、頁面瀏覽、點擊事件等
● 重要操作事件：Banner點擊、icon點擊、頻道Tab等重要操作點擊、某推薦位的曝光事件等
● 業務流程事件：注冊流程、忘記密碼流程、購物流程等
總之，不管采用第三方數據平臺，還是自建的埋點平臺，我們的方案中一般都采用Key-Value的形式，Key一般表示某個事件，Value代表相對應的值，一個Key可以對應一個Value或多個Value。埋點過程中，同種屬性的多個事件要命名成一個事件ID，并以Key-Value的形式區分；不同屬性的多個事件要命名為多個事件ID，此時盡量不用Key-Value的形式埋點。
事件（Event）、參數（Key）、參數值（Value）關系如下：
3、埋點文檔實例
先舉個簡單的栗子，比如我們想要知道新上線的【國美官方入駐】活動入的點擊情況，在京東有以下3個地方可以進入該活動頁面：
這里我們設置的參數是“國美的入口按鈕A“的點擊頁面（Page），參數值有3個，一個從全球品質購物節頁面點擊(Page1)，一個從家電品質盛典頁面可點擊(Page2)，一個從排行榜點擊(Page3)。根據這個思路，我們就可以做這樣一個簡單的埋點方案了。Key字段表示分析的維度，Value是不同維度下對于的值。即便以后增加活動入口，也只用增加value值即可。
獲得埋點文檔如下：
好了，按照這樣就能順利的統計和維護數據了。但是我們思考一下上述思路的短板是什么呢？很明顯，我們發現如果要給【國美活動頁】新增一個頁面很容易，添加一條value就好了。但是如果PageA頁面新增一個XX活動按鈕B呢，我們就得新增一條功能了，叫“統計XX活動入口按鈕B的點擊情況”，比如這樣：
這樣看起來沒有問題，但是這樣會不斷增加事件ID，不但工作量越來越大，后期維護成本和處理數據的成本也很高，所以通常我們不建議這樣做。
實際上我們通過歸納總結，可以這樣來思考：將不同維度（頁面、元素）分開，這樣根據不同維度（Key）和不同參數（Value）組成事件ID。這樣有組織的進行歸納，可以將不同維度下的不同參數有效區分出來，即便以后增加活動頁面入口，或者增加增加元素類型，都只需在當前Key-Value的基礎上對應的維度上增加新值就可以了，這樣再來看下思維導圖，是不是就清晰了一丟呢。
按照上面這樣從不同維度去設計的思路，輸出埋點文檔如下：
三、實例反推
時隔一周，京東APP排行榜頁面已經進行了新的改版。這就呼應了我們上篇文章說的埋點的作用：改善產品。我們根據調整后的頁面對比之前的頁面，反推一下該頁面通過怎樣的數據埋點，可能產生怎樣的數據結果改成目前這樣的。
1、改動點1：展示界面調整。新增一個tab叫【精選】，跟以前的頁面相比，從手機一屏幕來講，以前只能看到4個商品。現在我們可以看到3個熱賣榜，共9個商品，首頁共可以展示90個商品。
分析該頁面：我們可以猜想，可能是由于在排行榜首頁的商品點擊率都集中在榜單前三名。雖然展示了1~30名排行，但是對于用戶來說，他并不關心所有該榜單類目的東西。所以我們反推點擊商品這個事件上，應該有個參數（Key）是排名，參數值（Value）是排名位數。
2、改動點2：首頁數據源調整。之前的首頁的商品都從屬于一個“面部精華”的類目，比如面部精華的Tab下，就是面部精華熱賣榜，進口面部精華熱賣榜，韓系面部精華熱賣榜。調整后的首頁數據源擴展到了其他類目，比如面部精華熱賣榜、口紅榜、耳機熱賣榜。
分析該頁面：為什么要加入其他分類的榜單呢，可能是因為該頁面統計到用戶點擊Tab標簽選項卡的頻率較高，且在其他類目下瀏覽的時長較多。證明用戶還對其他分類的產品感興趣。由此我們可以知道應該有點擊Tab標簽這個事件，參數（Key）是標簽名稱、該標簽下停留時長（點擊標簽記錄t1，切換其他標簽記錄t2，t2-t1）。
基于當前頁面，用代碼埋點的方式，大概輸出的埋點文檔長這樣：
四、埋點文檔維護
在實際開發中，我們還需要根據公司要求或者場景要求添加部分字段，比如上線日期，英文變量名、中文顯示名等等，都是根據具體情況來的。正如前文說所，埋點文檔沒有一個定式，但是都遵從基本原則。
在整理完埋點需求表格后，我們已經踏出重大的一步了！接下來，我們需要發起需求評審。正確表述目的，讓其他產品人員、開發、測試都提出自己的意見。有時候他們的意見能幫助我們完善埋點需求。
評審完成后，順利經過以下步驟，就可以上線了。然后在我們的埋點文檔中記錄下上線時間、狀態等重要信息，以后有增加，就繼續更新文檔即可。
這里需要注意的是埋點文檔不同于一般的PRD，PRD是針對本次迭代的功能進行描述，而埋點文檔需要基于歷史所有埋點，所以我們一般不會對原有埋點數據進行直接刪除或修改。如要刪除某個埋點，在狀態寫明“已停用”及”停用時間“即可。
前端代碼埋點有時依賴App發版來生效，我們無法保證用戶使用的版本一定是最新的版本，可能他還在使用老版本APP。如果我們直接修改了老版本的某個埋點事件，那么該事件統計的結果可能就是不準確的。
五、寫在最后
我們平時在網上會看到各類的大數據相關的架構圖，有的從產品層面出發，有的從技術層面出發。其中所分析的數據源，埋點數據都是重要的一個成員。埋點數據不僅是用戶行為分析、用戶畫像分析的基礎，也是我們建立數據倉庫的基礎之一。
隨之我們可以思考，這些各類數據最終會存儲到哪里呢，怎么清洗、轉換，怎么用于用戶畫像分析呢。隨著公司業務的不斷發展，我們累積了大量各種類型的數據，加以利用，我們能獲取商機提升公司業務競爭力。不加以利用，那么它們只是躺在數據庫中的冗余。
以上是我的一些個人學習和工作經驗，沒有試卷，也不是標準答案，如果對您有幫助或啟發就再好不過啦。
系列相關文章：
