1? 埋點(diǎn)定義
埋點(diǎn)也叫事件追蹤（Event Tracking）。是針對(duì)特定用戶行為或事件進(jìn)行捕獲、處理和發(fā)送的相關(guān)技術(shù)及其實(shí)施過程。在數(shù)據(jù)分析過程中，數(shù)據(jù)采集是第一步，而埋點(diǎn)是數(shù)據(jù)采集的重要方式。
用戶使用產(chǎn)品時(shí)，填寫\產(chǎn)生的業(yè)務(wù)信息（如電商類的交易數(shù)據(jù)、商品數(shù)據(jù)）會(huì)由業(yè)務(wù)系統(tǒng)加密儲(chǔ)存在數(shù)據(jù)庫里。但行為數(shù)據(jù)（一個(gè)用戶在app/H5里面干了什么，看了哪些頁面，點(diǎn)了哪些按鈕）是不會(huì)被這些系統(tǒng)存儲(chǔ)，這時(shí)候就需要采用埋點(diǎn)：植入一段代碼或SDK。
2? 埋點(diǎn)分類
埋點(diǎn)方式可以分為代碼、可視化、全埋點(diǎn)的方式，也可以分為前端代碼埋點(diǎn)和后端代碼埋點(diǎn)（前端指客戶端，后端指服務(wù)端。前端埋點(diǎn)用來記錄用戶在客戶端的操作行為，后端埋點(diǎn)用來記錄客戶端進(jìn)行服務(wù)器請(qǐng)求的日志）。前后端埋點(diǎn)同時(shí)存在的話，相同的數(shù)據(jù)指標(biāo)可以相互印證，當(dāng)一方出現(xiàn)問題，可以通過另一方發(fā)現(xiàn)；不同的數(shù)據(jù)指標(biāo)可以相互補(bǔ)充。但需要注意的是，畢竟技術(shù)原理不一樣，存在一定范圍的差異是正常的，不應(yīng)太糾結(jié)。
我工作遇到的項(xiàng)目，一方面是需要做精細(xì)化深度分析，一方面是介于數(shù)據(jù)安全（金融數(shù)據(jù)）考慮，常采用的是代碼埋點(diǎn)（還會(huì)把常用公共參數(shù)的代碼封裝成一個(gè)組件，這樣的好處是可以復(fù)用多個(gè)項(xiàng)目，免去重復(fù)開發(fā)）。但是這種方式往往周期較長，過程復(fù)雜繁瑣，需要經(jīng)歷梳理業(yè)務(wù)、設(shè)計(jì)埋點(diǎn)、測(cè)試/上線流程，需要業(yè)務(wù)產(chǎn)品開發(fā)測(cè)試多人協(xié)作。
2.1 代碼埋點(diǎn)（又叫手動(dòng)埋點(diǎn)）
開發(fā)通過植入N行代碼，在界面初始化時(shí)，初始化埋點(diǎn)SDK，用戶觸發(fā)事件或頁面時(shí)，調(diào)用相應(yīng)SDK，通過接口發(fā)送數(shù)據(jù)。因?yàn)槭鞘謩?dòng)編碼產(chǎn)生的，所以設(shè)計(jì)自由度高，功能強(qiáng)大，可自定義事件和屬性，能精準(zhǔn)監(jiān)控對(duì)象，采集豐富數(shù)據(jù)。
1）前端埋點(diǎn)
應(yīng)用場(chǎng)景：需自定義埋點(diǎn)事件屬性才能滿足記錄用戶在客戶端的操作行為\分析業(yè)務(wù)環(huán)節(jié)
優(yōu)點(diǎn)：·需采集全面完整的事件屬性數(shù)據(jù)
? ? ? ? ? ?·有些不需要請(qǐng)求服務(wù)器行為，只能使用前端埋點(diǎn)，如：頁面停留時(shí)長
缺點(diǎn)：·需前端開發(fā)，人力成本高
? ? ? ? ? ?·會(huì)產(chǎn)生延遲上報(bào)和10%左右的漏報(bào)丟失（如客戶端未聯(lián)網(wǎng)、數(shù)據(jù)打包上報(bào)、用戶刪除行為數(shù)據(jù)等原因造成）
? ? ? ? ? ? ·若客戶端是APP，需要用戶主動(dòng)更新版本，新版本埋點(diǎn)才會(huì)生效。
2）后端埋點(diǎn)
應(yīng)用場(chǎng)景：?·采集非點(diǎn)擊、不可視行為
? ? ? ? ? ? ? ? ? ?·需整合用戶屬性信息和行為的數(shù)據(jù)
? ? ? ? ? ? ? ? ? ?·前后端都能采集到的信息，優(yōu)先選后端方式
? ? ? ? ? ? ? ? ? ? 比如：搶群微信紅包（紅包人數(shù)小于群人數(shù)，即非人人可得）等等需要請(qǐng)求服務(wù)器，否則用前端埋點(diǎn)可能會(huì)產(chǎn)生用戶端顯示獲得紅包，但實(shí)際紅包已經(jīng)被發(fā)完了，就會(huì)被用戶投訴。
優(yōu)點(diǎn)： ·支持用戶身份信息和行為的整合
? ? ? ? ? ?·實(shí)時(shí)采集、無延時(shí)上報(bào)、數(shù)據(jù)準(zhǔn)確
? ? ? ? ? ?·發(fā)版即生效，不需要前端和用戶更新
缺點(diǎn)：?·需服務(wù)端開發(fā)，人力成本高
? ? ? ? ? ? ·不能直接采集發(fā)生在前端，不請(qǐng)求服務(wù)器的行為數(shù)據(jù)，獲取前端屬性需接口開發(fā)
2.2 全埋點(diǎn)（又叫無埋點(diǎn)，屬于前端埋點(diǎn)）
復(fù)用同一套全面的SDK埋點(diǎn)方案，先采集所有控件的數(shù)據(jù)，有選擇的配置需要分析的控件。（可視化埋點(diǎn)是先選擇要采集數(shù)據(jù)的控件）
應(yīng)用場(chǎng)景：?·分析或統(tǒng)計(jì)需求簡(jiǎn)單，不需要對(duì)埋點(diǎn)事件進(jìn)行自定義傳參
? ? ? ? ? ? ? ? ? ?·需頻繁\緊急上線的H5運(yùn)營活動(dòng)
優(yōu)點(diǎn)：·省去設(shè)計(jì)開發(fā)埋點(diǎn)的工期和人力，只要部署SDK，即可采集數(shù)據(jù)
? ? ? ? ? ?·可獲得全量數(shù)據(jù)進(jìn)行分析，便捷的通過各種熱力圖等快速分析
缺點(diǎn)：?·傳輸數(shù)據(jù)大，消耗數(shù)據(jù)存儲(chǔ)資源
? ? ? ? ? ?·不能自定義交互事件
? ? ? ? ? ? ·一般借助第三方公司提供的埋點(diǎn)SDK，有數(shù)據(jù)安全隱患，且不便于改善丟包問題
2.3 可視化埋點(diǎn)
可視化埋點(diǎn)是把核心代碼和配置、資源分開，通過部署在產(chǎn)品上的基礎(chǔ)代碼對(duì)產(chǎn)品的所有交互元素進(jìn)行解析，并在可視化頁面進(jìn)行設(shè)定，界面啟動(dòng)時(shí)后端（服務(wù)端）更新配置和資源。用戶產(chǎn)生操作行為后，根據(jù)配置上報(bào)相關(guān)內(nèi)容。
應(yīng)用場(chǎng)景：?·分析或統(tǒng)計(jì)需求簡(jiǎn)單，不需要對(duì)埋點(diǎn)事件進(jìn)行自定義傳參
? ? ? ? ? ? ? ? ? ?·需頻繁\緊急上線的H5運(yùn)營活動(dòng)
優(yōu)點(diǎn)：·節(jié)省開發(fā)、更新埋點(diǎn)的工期和人力
? ? ? ? ? ?·降低門檻，業(yè)務(wù)、運(yùn)營可通過可視化界面配置和統(tǒng)計(jì)埋點(diǎn)
? ? ? ? ? ?·不受版本迭代影響
缺點(diǎn)： ·覆蓋功能有限，
? ? ? ? ? ? ·不能自定義交互事件
? ? ? ? ? ? ·不能支持內(nèi)容瀑布流式交互
? ? ? ? ? ? ·一般借助第三方公司提供的埋點(diǎn)SDK，有數(shù)據(jù)安全隱患，且不便于改善丟包問題
3 埋點(diǎn)步驟：
數(shù)據(jù)分析流程：
以下以某電商頁面為例
3.1 梳理業(yè)務(wù)
了解業(yè)務(wù)需求，明確跳轉(zhuǎn)邏輯是埋點(diǎn)的前提。一般通過產(chǎn)品需求文檔\原型圖+APP/H5實(shí)測(cè)，對(duì)觸發(fā)場(chǎng)景進(jìn)行枚舉.
1）頁面功能
列舉頁面功能，有助于思考頁面的功能，和期望用戶達(dá)成的行為。
2）核心業(yè)務(wù)流程
找到核心業(yè)務(wù)流程，便于進(jìn)一步明確數(shù)據(jù)觀測(cè)需求。
如：此頁面期望通過展示“用戶近期瀏覽的商品”+“熱門商品”結(jié)合“低價(jià)”“正品保證”激起用戶購買欲，進(jìn)而點(diǎn)擊商品詳情頁，完成下單支付購買。
由此梳理出幾個(gè)轉(zhuǎn)化關(guān)鍵
3.2 確定指標(biāo)
先梳理指標(biāo)需求，不是每個(gè)頁面、每個(gè)按鈕都要埋點(diǎn)，這會(huì)給開發(fā)增加很多負(fù)擔(dān)，甚至影響產(chǎn)品體驗(yàn)。且有的需求龐大復(fù)雜，應(yīng)根據(jù)項(xiàng)目上線緊急情況，迭代完成。
此外，很多指標(biāo)，可以有多種計(jì)算口徑，究竟用哪一種合適呢？如果能抓住實(shí)際業(yè)務(wù)的重心，不同角色關(guān)注的重心，就可以有理有據(jù)的根據(jù)實(shí)際情況進(jìn)行口徑的制定和設(shè)計(jì)。否則，最后拍腦袋定下的，很可能會(huì)傳遞錯(cuò)誤的效果信息。
舉個(gè)例子，電商訂單狀態(tài)包括：未付款、取消、拒收、待發(fā)貨、配送中、確認(rèn)收貨等，那么實(shí)際銷售總金額的條件應(yīng)該計(jì)算包含哪些訂單狀態(tài)下的銷售金額呢？實(shí)際上如果監(jiān)測(cè)對(duì)象是運(yùn)營，則訂單拒收及之后的狀態(tài)與運(yùn)營側(cè)的關(guān)系不大，所以給運(yùn)營制定的實(shí)際銷售總金額計(jì)算口徑，應(yīng)該是包含拒收及之后狀態(tài)的訂單實(shí)際金額之和。而如果涉及到拉新推薦返現(xiàn)，計(jì)算傭金等，那么實(shí)際銷售總金額肯定得是訂單狀態(tài)為已確認(rèn)收貨，甚至要疊加已過退貨期的條件才能計(jì)算，否則不僅會(huì)影響分析的準(zhǔn)確性，還可能會(huì)讓羊毛黨鉆空子（比如反復(fù)下單支付后不斷退款以白嫖傭金）
3.3 埋線設(shè)計(jì)
1）埋點(diǎn)拆解
為了使埋點(diǎn)文檔更加高效，降低迭代成本，減少溝通成本。一般埋點(diǎn)設(shè)計(jì)會(huì)按照“Key-Value”鍵值對(duì)的組合形式來唯一描述一個(gè)埋點(diǎn)：
1）先劃分最小原子維度?Key：事件、頁面、模塊等
2）再確定每個(gè)Key 的 Value ，一個(gè)Key可以對(duì)應(yīng)多個(gè)Value，
3）但Key-Value 唯一確定一個(gè)埋點(diǎn)
事件：比如 點(diǎn)擊／頁面曝光?等
? ? ? ? ? 點(diǎn)擊：用戶每點(diǎn)擊一下按鈕就會(huì)記為一次點(diǎn)擊事件。
? ? ? ? ? ?曝光：當(dāng)用戶成功進(jìn)入某頁面時(shí)記錄一次，刷新頁面也會(huì)增加一條記錄（home鍵切后臺(tái)再進(jìn)入頁面，不記）。
頁面：ABCD各種頁面，比如首頁、訂單頁、購物車頁面等
模塊：示實(shí)際產(chǎn)品復(fù)雜程度的需要添加，頁面上各種模塊分區(qū)，比如? 廣告位，搜索框等。
2）埋線文檔
重點(diǎn)：事件描述模型：5w2h——(who,when,where,how,what)?
記錄了誰在某個(gè)時(shí)間點(diǎn)、某個(gè)地方、用某種方式、做了某一件事情(某個(gè)行為)
Who：唯一標(biāo)識(shí)?？梢允?用戶ID、設(shè)備ID、平臺(tái)id（微信...）、自己產(chǎn)品后臺(tái)生成的賬戶id(user_id)...
When：事件發(fā)生的時(shí)間，時(shí)間戳，至少精確到秒
Where：位置、環(huán)境、IP（解析國家、省、市）、注冊(cè)位置
How：事件發(fā)生時(shí)的狀態(tài)。進(jìn)入渠道、跳轉(zhuǎn)的上級(jí)頁面、網(wǎng)絡(luò)(wifi\4g\3g)、屏幕分辨率等，瀏覽器、SDK版本、操作系統(tǒng)，
What：用戶行為描述。操作（停留、滑動(dòng)） 了什么首頁、模塊。如搜索(搜索關(guān)鍵字、搜索類型)、購買(商品名稱、商品類型、購買數(shù)量、購買金額、 付款方式)等。
埋點(diǎn)規(guī)范：
埋點(diǎn)工作需要多崗位協(xié)同完成。為了能高效準(zhǔn)確的傳達(dá)埋點(diǎn)需求，需要在團(tuán)隊(duì)內(nèi)部制定且共識(shí)形成一套統(tǒng)一的規(guī)范。同時(shí)，由于埋點(diǎn)工作往往需要分階段多次迭代，所以要包含上文中的重點(diǎn)信息5w2h事件描述模型，還應(yīng)有一些其他信息，包括不限于以下內(nèi)容，才能便于維護(hù)好埋點(diǎn)文檔，便于下次迭代順利銜接。
1.埋點(diǎn)編號(hào)：數(shù)字
2.埋點(diǎn)需求名稱(中)：能夠唯一標(biāo)識(shí)、準(zhǔn)確描述事件。如 搜索頁搜索按鈕點(diǎn)擊。
3.事件?(中/英) —頁面 ?(中/英)? —模塊 ?(中/英)? ：即上文提到的key value 。能夠準(zhǔn)確定義參數(shù).
4. 公共參數(shù) 共有的常規(guī)事件（設(shè)備ID、sessionid會(huì)話、頁面、模塊、按鈕、事件）會(huì)設(shè)置為公共參數(shù)，?封裝成一個(gè)SDK，復(fù)用和自動(dòng)采集
5. 自定義參數(shù)。?滿足不同業(yè)務(wù)的特殊需求，制定的擴(kuò)展字段。 備注合理參數(shù)的范圍，例舉參數(shù)的值。?注意通用性。
6. 備注：增刪改查時(shí)間(版本)，埋點(diǎn)文檔變更版本的時(shí)間點(diǎn)，便于追溯或回滾版本。
3.4日志上報(bào)
用戶每一個(gè)操作行為，會(huì)上報(bào)一組帶有數(shù)據(jù)的字段，包含了將要發(fā)送的完整的數(shù)據(jù)信息，形成對(duì)應(yīng)日志。日志一般包含以下字段，簡(jiǎn)單舉例，根據(jù)公司業(yè)務(wù)自行增刪：
{
"batch_id":"批次ID",
"analyse_time":"報(bào)文解析時(shí)間",
"remote_host":"設(shè)備公網(wǎng)IP",
"device_id":" 設(shè)備ID",
"?user_id":?"用戶ID?",?
"?app_key":?" 唯一key?",??
"version_code":"業(yè)務(wù)埋點(diǎn)版本"
"subversion_code":"業(yè)務(wù)埋點(diǎn)子版本"
"init_time":"SDK初始化時(shí)間"
"sdk_type":"SDK初始化時(shí)間"
......
}
