數(shù)據(jù)要埋點(diǎn)
淺談數(shù)據(jù)埋點(diǎn)
|0x00 如何理解埋點(diǎn)
埋點(diǎn)是數(shù)據(jù)采集的專用術(shù)語(yǔ)，在數(shù)據(jù)驅(qū)動(dòng)型業(yè)務(wù)中，如營(yíng)銷策略、產(chǎn)品迭代、業(yè)務(wù)分析、用戶畫像等，都依賴于數(shù)據(jù)提供決策支持，希望通過(guò)數(shù)據(jù)來(lái)捕捉特定的用戶行為，如按鈕點(diǎn)擊量、閱讀時(shí)長(zhǎng)等統(tǒng)計(jì)信息。因此，數(shù)據(jù)埋點(diǎn)可以簡(jiǎn)單理解為：針對(duì)特定業(yè)務(wù)場(chǎng)景進(jìn)行數(shù)據(jù)采集和上報(bào)的技術(shù)方案。
數(shù)據(jù)埋點(diǎn)非常看重兩件事，一個(gè)是數(shù)據(jù)記錄的準(zhǔn)確性，另一個(gè)則是數(shù)據(jù)記錄的完備性。
先講數(shù)據(jù)的準(zhǔn)確性。數(shù)據(jù)埋點(diǎn)非常強(qiáng)調(diào)規(guī)范和流程，因?yàn)閰?shù)的規(guī)范與合法，將直接影響到數(shù)據(jù)分析的準(zhǔn)確性，如果準(zhǔn)確性得不到保障，那么所有基于埋點(diǎn)得出的結(jié)論，都是不可信的。辛辛苦苦做了很久的方案，一旦因?yàn)橐粋€(gè)疏忽的小問(wèn)題，導(dǎo)致下游集中投訴，其實(shí)非常劃不來(lái)。
道理每個(gè)人都懂，但現(xiàn)實(shí)情況中，數(shù)據(jù)埋點(diǎn)所面對(duì)的客觀環(huán)境，其實(shí)非常復(fù)雜，例如：
產(chǎn)品在移動(dòng)場(chǎng)景下，既有原生的IOS和安卓端，也有H5和小程序端，每種場(chǎng)景的技術(shù)棧不同，出現(xiàn)問(wèn)題的排查成本很高； 埋點(diǎn)準(zhǔn)確性的驗(yàn)證，需要人肉參與，不能保證完全正確，且一旦出現(xiàn)問(wèn)題，只能隨著下次發(fā)版來(lái)修復(fù)，修復(fù)問(wèn)題的時(shí)間成本很高。
因此本文有非常長(zhǎng)的篇幅來(lái)寫流程問(wèn)題，其實(shí)是非常有必要的。
再講數(shù)據(jù)的完備性。因?yàn)?span style="color: rgb(217, 33, 66);">埋點(diǎn)主要是面向分析使用，對(duì)用戶而言是個(gè)額外的功能，因此埋點(diǎn)的業(yè)務(wù)侵入性很強(qiáng)，很容易對(duì)用戶體驗(yàn)造成影響。別的不說(shuō)，僅僅是流量的消耗，就很容被用戶噴。因此，要提前想清楚，我們要采集哪些東西，因?yàn)樾薷姆桨傅某杀?，是傷不起的?/p>
通常情況下，我們需要記錄用戶在使用產(chǎn)品過(guò)程中的操作行為，通過(guò)4W1H模型可以比較好的保障信息是完備的。4W1H包括：
Who（誰(shuí)）； When（在什么時(shí)間）； Where（在什么位置）； What（看到了什么）； How（做了哪些操作）。
規(guī)定好記錄信息的基本方法之后，按照固定的頻率，如每小時(shí)、每天，或者是固定的數(shù)量，比如多少條日志，或者是網(wǎng)絡(luò)環(huán)境，比如在Wifi下上傳，我們就可以開(kāi)心的把埋點(diǎn)數(shù)據(jù)用起來(lái)了。
當(dāng)然，數(shù)據(jù)記錄的時(shí)效性也比較重要，但因?yàn)槁顸c(diǎn)數(shù)據(jù)通常量級(jí)會(huì)比較大，且各個(gè)端數(shù)據(jù)回傳的時(shí)間不同，因此想做到實(shí)時(shí)統(tǒng)計(jì)，還是需要分場(chǎng)景來(lái)展開(kāi)。在Flink技術(shù)日漸成熟的今天，全鏈路的實(shí)時(shí)采集與統(tǒng)計(jì)，已經(jīng)不是什么難題。
|0x01 埋點(diǎn)的技術(shù)方案
在埋點(diǎn)的技術(shù)方案中，首先要重視的，是用戶唯一標(biāo)識(shí)的建設(shè)。如果做不到對(duì)用戶的唯一識(shí)別，那么基礎(chǔ)的UV統(tǒng)計(jì)，都將是錯(cuò)誤的。
因此，在數(shù)據(jù)埋點(diǎn)方案中，有兩個(gè)信息是一定要記錄的，即設(shè)備ID+用戶ID。設(shè)備ID代表用戶使用哪個(gè)設(shè)備，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，瀏覽器的Cookie，小程序的OpenID等。用戶ID，代表用戶在產(chǎn)品中所注冊(cè)的賬號(hào)，通常是手機(jī)號(hào)，也可以是郵箱等其他格式。
當(dāng)這兩個(gè)信息能夠獲得時(shí)，不論是用戶更換設(shè)備，或者是同一臺(tái)設(shè)備不同賬號(hào)登錄，我們都能夠根據(jù)這兩個(gè)ID，來(lái)識(shí)別出誰(shuí)在對(duì)設(shè)備做操作。
其次，我們來(lái)看一下Web的數(shù)據(jù)采集技術(shù)。Web端數(shù)據(jù)采集主要通過(guò)三種方式實(shí)現(xiàn)：服務(wù)器日志、URL解析及JS回傳。
服務(wù)器日志：指Web服務(wù)器軟件，例如Httpd、Nginx、Tomcat等自帶的日志，例如Nginx的access.log日志等； URL解析：指訪問(wèn)服務(wù)器時(shí)，將URL信息及攜帶的參數(shù)進(jìn)行解析后，上傳服務(wù)器，例如訪問(wèn)百度首頁(yè)：https://www.baidu.com/s?ie=utf-8&wd=你好，我們可以獲得本次訪問(wèn)的word為“你好”； JS回傳：指在Web頁(yè)面上添加的各類統(tǒng)計(jì)插件，通過(guò)在頁(yè)面嵌入自定義的Javascript代碼來(lái)獲取用戶的訪問(wèn)行為(比如鼠標(biāo)懸停的位置，點(diǎn)擊的頁(yè)面組件等)，然后通過(guò)Ajax請(qǐng)求到后臺(tái)記錄日志。
瀏覽器的日志采集種類又可以分為兩大類：頁(yè)面瀏覽日志和頁(yè)面交互日志。
頁(yè)面瀏覽日志：別名為“展現(xiàn)日志”；指當(dāng)一個(gè)頁(yè)面被瀏覽器加載時(shí)所采集的日志，該類型為最基礎(chǔ)的互聯(lián)網(wǎng)日志，也是PV及UV統(tǒng)計(jì)的基礎(chǔ)。 頁(yè)面交互日志：別名為“點(diǎn)擊日志”；指當(dāng)頁(yè)面加載和渲染完成后，用戶可以在頁(yè)面上執(zhí)行的各類操作，以便量化感知用戶的興趣點(diǎn)。
除此之外，還有一些針對(duì)特定場(chǎng)合統(tǒng)計(jì)的日志，例如頁(yè)面曝光時(shí)長(zhǎng)日志、用戶在線操作監(jiān)控等，但原理都基于上述兩類日志，只是在統(tǒng)計(jì)上有所區(qū)分。
再次，我們來(lái)看下客戶端的數(shù)據(jù)采集。與網(wǎng)頁(yè)日志對(duì)應(yīng)的，是手機(jī)應(yīng)用為基礎(chǔ)的客戶端日志，由于早期手機(jī)網(wǎng)絡(luò)通訊能力較差，因而SDK往往采用延遲發(fā)送日志的方式，也就是先將日志統(tǒng)計(jì)在本地，然后選擇在Wifi環(huán)境下上傳，因而往往會(huì)出現(xiàn)統(tǒng)計(jì)數(shù)據(jù)延遲的情況?，F(xiàn)如今網(wǎng)絡(luò)環(huán)境好了很多，4G、5G流量充足，尤其是視頻類APP基本上都是一直聯(lián)網(wǎng)，因而很多統(tǒng)計(jì)能夠做到實(shí)時(shí)統(tǒng)計(jì)。
客戶端的日志統(tǒng)計(jì)主要通過(guò)SDK來(lái)完成，根據(jù)不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據(jù)類型的不同，可以分為頁(yè)面事件（類比頁(yè)面瀏覽）和控件點(diǎn)擊事件（類比頁(yè)面交互）。對(duì)于頁(yè)面事件，不同的SDK有不同的方式，主要區(qū)別為是在頁(yè)面創(chuàng)建時(shí)發(fā)送日志，還是在頁(yè)面瀏覽結(jié)束后發(fā)送日志，區(qū)別在于業(yè)務(wù)統(tǒng)計(jì)是否需要采集用戶的頁(yè)面停留時(shí)長(zhǎng)。
頁(yè)面事件的統(tǒng)計(jì)主要統(tǒng)計(jì)如下三類信息：
設(shè)備及用戶的基本信息，例如IMEI、用戶賬號(hào)等； 被訪問(wèn)頁(yè)面的信息，例如商品ID、瀏覽店鋪等； 訪問(wèn)的路徑信息，例如上一個(gè)頁(yè)面來(lái)源等。
最后，我們還需要考慮小程序等場(chǎng)景的埋點(diǎn)方案，小程序通常情況下，開(kāi)發(fā)者會(huì)聲明好相應(yīng)的方法，按照需求調(diào)用即可，例如微信提供了API上報(bào)和填寫配置兩種方案。
埋點(diǎn)其實(shí)還需要考慮數(shù)據(jù)上傳的方案，批量的數(shù)據(jù)可以通過(guò)Flume直接上報(bào)，流式的可以寫到Kafka，或者直接使用Flink來(lái)處理。這些框架相關(guān)的內(nèi)容不是本文考慮的重點(diǎn)，有興趣的可以自行查閱資料。
|0x02 埋點(diǎn)的流程規(guī)范
有了指導(dǎo)思路和技術(shù)方案后，我們就可以著手制定相應(yīng)的數(shù)據(jù)埋點(diǎn)流程規(guī)范了。
籠統(tǒng)上，流程規(guī)范會(huì)分成五個(gè)步驟，即需求評(píng)審、埋點(diǎn)申請(qǐng)、技術(shù)開(kāi)發(fā)、埋點(diǎn)驗(yàn)證、發(fā)布上線。
第一步，需求評(píng)審。
前文提到過(guò)，數(shù)據(jù)埋點(diǎn)的方案一旦確定，返工和排查問(wèn)題的成本都很高，但數(shù)據(jù)埋點(diǎn)之后的分析工作，又涉及到了PD、BI、算法、數(shù)據(jù)等多個(gè)角色。因此非常有必要，將需求內(nèi)容和數(shù)據(jù)口徑統(tǒng)一收口，所有人在一套口徑下，將需求定義出來(lái)，隨后業(yè)務(wù)側(cè)再介入，進(jìn)行埋點(diǎn)方案的設(shè)計(jì)和開(kāi)發(fā)。
以前文提到的4W1H模型為例，常見(jiàn)的記錄內(nèi)容如下：
Who：設(shè)備ID、用戶ID、手機(jī)號(hào)、微信識(shí)別碼等； Where：在Web、移動(dòng)端還是小程序下，如果是移動(dòng)端，GPS地址在哪，使用的是哪個(gè)APP； When：記錄日志的時(shí)間戳、日志上報(bào)的時(shí)間戳； What：操作系統(tǒng)、設(shè)備型號(hào)、網(wǎng)絡(luò)環(huán)境、APP版本、當(dāng)前頁(yè)面、展示內(nèi)容等信息； How：如果是搜索行為，則記錄關(guān)聯(lián)詞；如果是內(nèi)容點(diǎn)擊，則記錄內(nèi)容ID、內(nèi)容類型、列表位置；如果是交易動(dòng)作，記錄交易的商品ID、類型、數(shù)量；如果是支付過(guò)程，記錄付款的方式與付款金額。
最后我們統(tǒng)計(jì)時(shí)，按照上述約定，統(tǒng)計(jì)用戶在某個(gè)時(shí)間和地點(diǎn)中，看到了哪些信息，并完成了怎樣的動(dòng)作。上下游的相關(guān)人員，在使用這份數(shù)據(jù)時(shí)，產(chǎn)生的歧義或者是分歧，會(huì)小很多。
第二步，埋點(diǎn)申請(qǐng)。
當(dāng)下的熱門應(yīng)用，大多是以超級(jí)APP的形式出現(xiàn)，比如微信、淘寶、支付寶、抖音，超級(jí)APP會(huì)承載非常多的業(yè)務(wù)，因此技術(shù)方案上會(huì)十分統(tǒng)一。
因此，當(dāng)我們的技術(shù)方案確定后，通常要在相應(yīng)的埋點(diǎn)平臺(tái)上，進(jìn)行埋點(diǎn)申請(qǐng)。申請(qǐng)的內(nèi)容包括分配的SPM、SCM碼是什么，涉及到的平臺(tái)是哪些，等等。SPM、SCM是什么，有什么用，同樣可以自行查閱。
第三步，技術(shù)開(kāi)發(fā)。
當(dāng)需求確定、申請(qǐng)通過(guò)后，我們就可以開(kāi)始開(kāi)發(fā)動(dòng)作了，這里基本上是對(duì)研發(fā)同學(xué)進(jìn)行約束。埋點(diǎn)的開(kāi)發(fā)，簡(jiǎn)單講，是分成行為埋點(diǎn)和事件埋點(diǎn)兩個(gè)大類，每一類根據(jù)端的不同進(jìn)行相應(yīng)的開(kāi)發(fā)。具體的技術(shù)方案詳見(jiàn)前文01章節(jié)。
詳細(xì)的設(shè)計(jì)規(guī)范，是需要留文檔的，因?yàn)榇a不能反應(yīng)業(yè)務(wù)的真實(shí)意圖，而不論是事后復(fù)盤與業(yè)務(wù)交接，都需要完整的文檔來(lái)闡述設(shè)計(jì)思路。
第四步，埋點(diǎn)驗(yàn)證。
埋點(diǎn)的驗(yàn)證很關(guān)鍵，如果上線后才發(fā)現(xiàn)問(wèn)題，那么歷史數(shù)據(jù)是無(wú)法追溯的。
驗(yàn)證有兩種方式，一種是實(shí)時(shí)的功能驗(yàn)證，一種是離線的日志驗(yàn)證。
實(shí)時(shí)功能驗(yàn)證，指功能開(kāi)發(fā)好后，在灰度環(huán)境上測(cè)試相應(yīng)的埋點(diǎn)功能是否正常，比如點(diǎn)擊相應(yīng)的業(yè)務(wù)模塊，日志是否會(huì)正確的打印出來(lái)。通常而言，我們需要驗(yàn)證如下三個(gè)類型的問(wèn)題：
記錄正確：APP發(fā)生相應(yīng)的動(dòng)作，檢查日志是否打印正確，如：打開(kāi)頁(yè)面（行為埋點(diǎn)）、點(diǎn)擊按鈕（事件埋點(diǎn)）時(shí)，是否日志會(huì)記錄； 位置正確：查看SPM、SCM碼與平臺(tái)申請(qǐng)的是否一致； 內(nèi)容正確：設(shè)備ID、用戶ID等必須記錄的內(nèi)容是否正確，行為、事件記錄內(nèi)容是否與頁(yè)面實(shí)際發(fā)生的一致。
除去實(shí)時(shí)驗(yàn)證，我們也需要把日志寫到測(cè)試環(huán)境中，查看數(shù)據(jù)上報(bào)的過(guò)程是否正確，以及對(duì)上報(bào)后的數(shù)據(jù)進(jìn)行統(tǒng)計(jì)，側(cè)面驗(yàn)證記錄的準(zhǔn)確性，如統(tǒng)計(jì)基本的PV、UV，行為、事件的發(fā)生數(shù)量。
很多時(shí)候，數(shù)據(jù)是需要多方驗(yàn)證的，存在一定的上下游信息不同步問(wèn)題，比如對(duì)某個(gè)默認(rèn)值的定義有歧義，日志統(tǒng)計(jì)會(huì)有效的發(fā)現(xiàn)這類問(wèn)題。
第五步，發(fā)布上線。
應(yīng)用的發(fā)布上線通常會(huì)有不同的周期，例如移動(dòng)端會(huì)有統(tǒng)一的發(fā)版時(shí)間，而網(wǎng)頁(yè)版只需要根據(jù)自己的節(jié)奏走，因此數(shù)據(jù)開(kāi)始統(tǒng)計(jì)的時(shí)間是不同的。最后，應(yīng)用應(yīng)當(dāng)對(duì)所有已發(fā)布的埋點(diǎn)數(shù)據(jù)，有統(tǒng)一的管理方法。
大多數(shù)時(shí)候，數(shù)據(jù)埋點(diǎn)的技術(shù)方案，只需要設(shè)計(jì)一次，但數(shù)據(jù)準(zhǔn)確性的驗(yàn)證，卻需要隨著產(chǎn)品的生命周期持續(xù)下去，因此僅僅依靠人肉來(lái)準(zhǔn)確性驗(yàn)證是不夠的，我們需要平臺(tái)來(lái)支持自動(dòng)化的工作。埋點(diǎn)的準(zhǔn)確性，大體有兩種方法保障：一種是灰度環(huán)境下驗(yàn)證真實(shí)用戶數(shù)據(jù)的準(zhǔn)確性；另一種則是在線上環(huán)境中，驗(yàn)證全量數(shù)據(jù)的準(zhǔn)確性。因此，發(fā)布上線之后，后續(xù)的管理動(dòng)作，應(yīng)該是對(duì)現(xiàn)有流程的自動(dòng)化管理，因?yàn)閳F(tuán)隊(duì)大了，需要埋點(diǎn)的東西多種多樣，讓平臺(tái)自己測(cè)試、自動(dòng)化測(cè)試，就是很多測(cè)試團(tuán)隊(duì)必須走的路。
|0xFF 行業(yè)現(xiàn)狀
目前行業(yè)中，已經(jīng)有很多比較成熟的數(shù)據(jù)統(tǒng)計(jì)平臺(tái)，大家對(duì)于數(shù)據(jù)埋點(diǎn)也都有自己的方案。常見(jiàn)的有：GrowingIO、神策數(shù)據(jù)、百度統(tǒng)計(jì)、谷歌分析、友盟等。官網(wǎng)都有比較詳細(xì)的介紹，這里不再贅述。
數(shù)據(jù)埋點(diǎn)只是技能的一種，通過(guò)埋點(diǎn)的數(shù)據(jù)，如何去做分析，其實(shí)也很重要。做過(guò)互聯(lián)網(wǎng)的同學(xué)，基本都會(huì)有自己的寶藏庫(kù)，來(lái)看看業(yè)界的同行都是如何分析問(wèn)題的，著名的如艾瑞咨詢的數(shù)據(jù)報(bào)告。其實(shí)再高大上的報(bào)告，歸根結(jié)底，也是通過(guò)數(shù)據(jù)+模型來(lái)分析得到的結(jié)論。
最后說(shuō)說(shuō)自己做數(shù)據(jù)埋點(diǎn)方案的利弊。一些流量型的業(yè)務(wù)模式，使用第三方是沒(méi)有問(wèn)題的，因?yàn)榈谌酵ǔＬ峁┝撕軓?qiáng)大、很完備的功能，穩(wěn)定性也有保障，但缺點(diǎn)是，無(wú)法做平臺(tái)規(guī)則之外的數(shù)據(jù)埋點(diǎn)。但如果業(yè)務(wù)數(shù)據(jù)是非常敏感的，比如金融相關(guān)，那么還是建議自己做技術(shù)方案，且現(xiàn)有的數(shù)據(jù)埋點(diǎn)方法，都是基于流量分析平臺(tái)來(lái)做的，對(duì)于一些偏傳統(tǒng)的業(yè)務(wù)場(chǎng)景，其實(shí)并不是非常適用。
最后，數(shù)據(jù)埋點(diǎn)，只是一種技術(shù)或者是工具，想要得出有價(jià)值的分析成果，需要有有科學(xué)的分析模型做指導(dǎo)，也需要有正確的學(xué)習(xí)路線來(lái)堅(jiān)持。