為什么要埋點(diǎn)？現(xiàn)在的互聯(lián)網(wǎng)公司越來越關(guān)注轉(zhuǎn)化、新增蕾管、留存枷踏，而不是簡單的統(tǒng)計PV、UV掰曾。而完整的數(shù)據(jù)采集是一切的前提旭蠕。
埋點(diǎn)包括在IOS、Android婴梧、H5下梢、小程序等前端埋點(diǎn)，也包括后端業(yè)務(wù)埋點(diǎn)塞蹭。這里僅僅講講這些年和產(chǎn)品經(jīng)理孽江、運(yùn)營撕逼上百個回合的前端埋點(diǎn)內(nèi)容。
說說手工埋點(diǎn)番电、可視化埋點(diǎn)岗屏、無埋
手動埋點(diǎn)（代碼埋點(diǎn)）
純手動寫代碼，調(diào)用埋點(diǎn)SDK的函數(shù)漱办，在需要埋點(diǎn)的業(yè)務(wù)邏輯功能位置調(diào)用接口上報埋點(diǎn)數(shù)據(jù)这刷，友盟、百度統(tǒng)計等第三方數(shù)據(jù)統(tǒng)計服務(wù)商大都采用這種方案娩井；
手動埋點(diǎn)讓使用者可以方便地設(shè)置自定義屬性暇屋、自定義事件。所以當(dāng)你需要深入下鉆洞辣，并精細(xì)化自定義分析時咐刨，比較適合使用手動埋點(diǎn)。
手動埋點(diǎn)的缺陷就是扬霜，項(xiàng)目工程量大定鸟，需要埋點(diǎn)的位置太多，而且需要產(chǎn)品開發(fā)運(yùn)營之間相互反復(fù)溝通著瓶，容易出現(xiàn)手動差錯联予，如果錯誤，重新埋點(diǎn)的成本也很高材原。這會導(dǎo)致整個數(shù)據(jù)收集周期變的很長沸久，收集成本變的很高，而且效率很低华糖。因?yàn)槭謩勇顸c(diǎn)需要開發(fā)人員完成麦向，所以每次有埋點(diǎn)更新，或者漏埋點(diǎn)客叉，都需要重新走上線發(fā)布流程，更新成本也高，對線上系統(tǒng)穩(wěn)定性也有一定危害兼搏。
手動埋點(diǎn)的技術(shù)本質(zhì)是什么呢卵慰？
我們看看從javascript中能輕松獲得哪些信息：
域名：document.domainURLdocument.URL
頁面標(biāo)題：document.title
分辨率：window.screen.height & window.screen.width
顏色深度：window.screen.colorDepth
Referrer：document.referrer
客戶端語言：navigator.language
除了上面的列舉的常規(guī)信息以外，還有大量的業(yè)務(wù)數(shù)據(jù)佛呻，都需要通過手動寫javascript去實(shí)現(xiàn)裳朋。
代碼手動埋點(diǎn)常用的方式有以下幾種：
命令式
$(document).ready(()=>{
// ... 這里是你的業(yè)務(wù)邏輯代碼
sendData(params); //這里是發(fā)送你的埋點(diǎn)數(shù)據(jù)，params是你封裝的埋點(diǎn)數(shù)據(jù)
});
// 按鈕點(diǎn)擊時發(fā)送埋點(diǎn)請求
$('button').click(()=>{
// ... 業(yè)務(wù)邏輯
sendData(params); //同上
});
聲明式
<button data-mydata="{key:'uber_comt_share_ck', act: 'click',msg:{}}">打車</button>
這里聲明了自定義屬性data-mydata吓著，你可以在你的SDK中去掃描和識別這些自定義屬性鲤嫡，并解析封裝數(shù)據(jù)，在SDK中按照自定義規(guī)則去綁定事件并發(fā)送埋點(diǎn)數(shù)據(jù)绑莺。
前端框架式
如果使用Vue或者React等前端框架暖眼，這些框架都有自己的各種生命周期，為了減少重復(fù)性的手動買點(diǎn)次數(shù)纺裁，可以再各個生命周期位置诫肠，根據(jù)你的需求封裝你所需的埋點(diǎn)，比如你是SPA單頁應(yīng)用欺缘，你希望在每一個頁面的componentDidMount埋點(diǎn)栋豫，并由此確定用戶已經(jīng)打開了頁面。
css埋點(diǎn)
.link:active::after{
content: url("http://www.example.com?action=yourdata");
}
<a class="link">點(diǎn)擊我谚殊，會發(fā)埋點(diǎn)數(shù)據(jù)</a>
這里用了很巧妙的css的某些特征丧鸯，這些可以出發(fā)發(fā)送請求的特征。
以上是比較常見的手動埋點(diǎn)方案嫩絮，當(dāng)然還有很多其他方式和有待挖掘的方案丛肢，也請大家補(bǔ)充
可視化埋點(diǎn)（框架式埋點(diǎn)，無痕埋點(diǎn)）
解決了純手動埋點(diǎn)的開發(fā)成本和更新成本絮记，通過可視化工具快速配置采集節(jié)點(diǎn)（圈點(diǎn)）摔踱，在前端自動解析配置，并根據(jù)配置上傳埋點(diǎn)數(shù)據(jù)怨愤，比起手動埋點(diǎn)看起來更無痕派敷，這里的配置數(shù)據(jù)可以設(shè)置過濾條件，避免針對所有元素（比如全埋點(diǎn)）撰洗，可以在調(diào)用開啟自動監(jiān)控API時通過設(shè)置一些特征屬性篮愉，來過濾不符合條件的元素，實(shí)現(xiàn)只針對某些元素進(jìn)行自動上報數(shù)據(jù)的需求差导。
比如國外比較早做可視化的是Mixpanel试躏，國內(nèi)比較早支持可視化埋點(diǎn)的有TalkingData，諸葛IO设褐，2017年騰訊的MTA也宣布支持可視化埋點(diǎn)颠蕴；相比于手動埋點(diǎn)更新困難泣刹，埋點(diǎn)成本高的問題，可視化埋點(diǎn)優(yōu)化了移動運(yùn)營中數(shù)據(jù)采集的流程犀被，能夠支持產(chǎn)品運(yùn)營隨時調(diào)整埋點(diǎn)椅您，無需再走發(fā)版流程，直接把配置結(jié)果推入到前端寡键，數(shù)據(jù)采集流程更簡化掀泳，也更方便產(chǎn)品的迭代。
可視化埋點(diǎn)中多數(shù)基于Xpath的方案西轩，Xpath是一門在XML文檔中查找信息的語言员舵，Xpath可用來在XML文檔中對元素和屬性進(jìn)行遍歷
比如上圖中標(biāo)識的位置，其中的Xpath：//*[@id="projects"]/a4/img藕畔，如果換成DOM的selector：#projects > a:nth-child(4) > img马僻。通過這些信息可以精準(zhǔn)定位到一個DOM節(jié)點(diǎn)，xpath方案分為精確路徑和概略路徑兩種做法劫流，精確路徑從被點(diǎn)擊的元素不斷向上冒泡查找到根節(jié)點(diǎn)巫玻，并記錄過程中每個節(jié)點(diǎn)的。如果用戶阻止了冒泡會導(dǎo)致失效祠汇，概略路徑是在前者的基礎(chǔ)僅僅向上查找白名單中的節(jié)點(diǎn)仍秤。但是如果DOM節(jié)點(diǎn)有任何變化，對應(yīng)的xpath數(shù)組就是被打亂可很，很容易影響采集诗力。
可視化埋點(diǎn)配置化能力相對手動埋點(diǎn)更強(qiáng)，是對手動埋點(diǎn)的補(bǔ)充而不是代替我抠，很多手動埋點(diǎn)點(diǎn)都可以通過好的規(guī)劃和架構(gòu)變?yōu)榭梢暬顸c(diǎn)苇本。
無埋點(diǎn)（自動埋點(diǎn)，全埋點(diǎn)）
無埋點(diǎn)并不是沒有任何埋點(diǎn)菜拓，所謂無只是不需要工程師在業(yè)務(wù)代碼里插入侵入式的代碼瓣窄，只需要簡單的加載了一段定義好的SDK代碼，技術(shù)門檻更低纳鼎，使用與部署也簡單俺夕，避免了需求變更，埋點(diǎn)錯誤導(dǎo)致的重新埋點(diǎn)贱鄙。
通過這個SDK代碼劝贸，前端會自動全量采集全部事件并上報埋點(diǎn)數(shù)據(jù)，能夠呈現(xiàn)用戶行為的每一次點(diǎn)擊逗宁、每一次跳轉(zhuǎn)映九、每一次登錄等全量、實(shí)時用戶行為數(shù)據(jù)瞎颗，這些數(shù)據(jù)傳到后端后件甥，可通過用戶分群捌议、漏斗對比等功能，分析不同訪問來源嚼蚀、不同城市腊嗡、不同廣告來源等多維度的不同轉(zhuǎn)化細(xì)節(jié)玫鸟，細(xì)而全。
圖中可以看到無埋點(diǎn)會發(fā)送大量的請求韵丑，因?yàn)闊o埋點(diǎn)會針對很多DOM節(jié)點(diǎn)添加事件僻孝。當(dāng)用戶在頁面中有交互時导帝，就會觸發(fā)大量的數(shù)據(jù)請求。
無埋點(diǎn)相比可視化埋點(diǎn)穿铆，在解決數(shù)據(jù)‘回溯’問題上更有又是您单，如果你想分析某一天某個控件的點(diǎn)擊情況，如果你沒有針對這個按鈕做可視化埋點(diǎn)荞雏，則只能從你針對這個按鈕做可視化配置的這一時刻之后再才有埋點(diǎn)數(shù)據(jù)虐秦，而無埋點(diǎn)，則總你部署SDK那一刻就一直有數(shù)據(jù)在收集凤优，無埋點(diǎn)做熱力圖也更有優(yōu)勢悦陋，無埋點(diǎn)可以告訴使用者這個界面上每個控件分別被點(diǎn)擊的概率是多大，通過熱力圖清晰可見筑辨。
無埋點(diǎn)的劣勢是自定義屬性不靈活俺驶，傳輸時效性差，數(shù)據(jù)可靠性欠佳棍辕，耗費(fèi)網(wǎng)絡(luò)流量暮现，還會增加服務(wù)器負(fù)載，而且兼容性也不佳楚昭。
據(jù)說Heap Analytics在2013左右較早推出了無埋點(diǎn)方案栖袋，但是網(wǎng)上有人透露百度在2009年就有類似技術(shù)，后來2011年抚太，百度質(zhì)量部也推出過一個內(nèi)部服務(wù)塘幅，用以錄制安卓 App 的全部操作，通過回放定位App崩潰的原因凭舶；豌豆莢也在2013年左右在自己的 App 內(nèi)晌块，也記錄了所有控件操作情況。國內(nèi)GrowingIO在2015年也較早支持了無埋點(diǎn)方案帅霜，后面神策等其他第三方也陸續(xù)支持了此技術(shù)匆背。
我們看看神策和Mixpanel對無埋點(diǎn)的實(shí)現(xiàn)方案。
神策：根據(jù)官方的介紹身冀，設(shè)置AutoTrack之后钝尸，SDK就會自動解析HTML頁面上的( a 括享、 button 、 input )標(biāo)簽珍促。 并記錄這些標(biāo)簽的點(diǎn)擊情況铃辖，一旦頁面某一個按鈕發(fā)生了點(diǎn)擊行為，SDK就會去采集此按鈕的一些信息猪叙，例如: 這個按鈕的標(biāo)簽類型娇斩，這個按鈕的文本內(nèi)容，這個按鈕的 name 穴翩，這個按鈕的 id 犬第、 class 名，還有一些按鈕特有的屬性如 href等芒帕。
Mixpanel： 設(shè)置AutoTrack之后歉嗓，SDK會監(jiān)測頁面上的所有 form表單 、 input標(biāo)簽 背蟆、 select和textarea標(biāo)簽 產(chǎn)生的 submit 鉴分、 change 、 click 事件带膀，并采集這些標(biāo)簽上的屬性一起上報志珍。
無埋點(diǎn)確實(shí)發(fā)送的埋點(diǎn)數(shù)量很巨大，比如知乎上就有很多人質(zhì)疑無埋點(diǎn)解決方案本砰。很多用戶對無埋點(diǎn)發(fā)送大量埋點(diǎn)請求表示不理解碴裙，但是由于無埋點(diǎn)技術(shù)方案的限制，無埋點(diǎn)的可交互元素眾多点额，每一次交互都會發(fā)送請求舔株，所以會導(dǎo)致網(wǎng)絡(luò)請求過重。神策等官方文檔中也建議無埋點(diǎn)最好使用在那些按鈕不是很多的还棱，相對簡單的頁面载慈。
數(shù)據(jù)采集能力比較
比如這個頁面，點(diǎn)擊確認(rèn)按鈕珍手，如果使用無埋點(diǎn)和可視化埋點(diǎn)办铡，在這里可能只能獲取到某時刻某個人點(diǎn)擊了確認(rèn)，提交了一個訂單琳要，僅此而已寡具。如果你希望拿到里面的首付款，月供稚补，車型車款童叠、用戶詳情等深度業(yè)務(wù)信息，就只能靠手動埋點(diǎn)獲取课幕。
無埋點(diǎn)和可視化埋點(diǎn)雖然使用和部署都很簡單厦坛，但是在數(shù)據(jù)精確度和詳細(xì)程度的獲取能力上代碼埋點(diǎn)更強(qiáng)大五垮。一般來說，我們的產(chǎn)品都是根據(jù)業(yè)務(wù)場景混合使用三種埋點(diǎn)模式來完成我們的數(shù)據(jù)收集杜秸。
感性認(rèn)識一些數(shù)據(jù)上報格式和接入代碼
上報方式提到過放仗，基本就是json、url params撬碟、head等诞挨，為了數(shù)據(jù)分析的關(guān)聯(lián)性，會帶上cookie小作、還有一些數(shù)據(jù)可能是在localstorage等具有生命周期管控的客戶端存儲里亭姥。
GA的接入代碼：
GA的上報格式：
Talkingdata的接入代碼：
Talkingdata的上報格式：
埋點(diǎn)技術(shù)除了剛才的方式劃分，還可以劃分為前端埋點(diǎn)和后端埋點(diǎn)顾稀，后端埋點(diǎn)數(shù)據(jù)更可靠、更集中（且沒有前端的多端問題）坝撑、更實(shí)時静秆。這篇文章主要是討論前端埋點(diǎn)。
根據(jù)工作中對埋點(diǎn)的對比和整理巡李，我們簡單比較部分埋點(diǎn)方案：
對于語義明確的UI事件抚笔，自動埋點(diǎn)的數(shù)據(jù)一般會比手動埋點(diǎn)更加準(zhǔn)確，更貼近用戶行為侨拦，也更節(jié)省開發(fā)成本殊橙，侵入性更低。
主要是因?yàn)樽詣勇顸c(diǎn)語義簡單明確狱从，不像手動埋點(diǎn)由于開發(fā)習(xí)慣膨蛮、代碼風(fēng)格、人的理解誤差季研、分支處理等各種不確定因素變得沒那么清晰明了敞葛。
比如：“下單”事件，自動埋點(diǎn)的PV肯定是>=手動埋點(diǎn)的与涡，而UV差別可能不大惹谐。分析開發(fā)代碼發(fā)現(xiàn)在onClick Listener中包含其他未覆蓋到的分支，差別很可能就在代碼分支當(dāng)中驼卖。如果更進(jìn)一步分析下代碼可以發(fā)現(xiàn)氨肌，為什么開發(fā)不在分支當(dāng)中埋點(diǎn)？可能這個分支會認(rèn)為用戶的這一次點(diǎn)擊是“無效”的酌畜，但這只是程序邏輯的看法怎囚，用戶可能不這么認(rèn)為，用戶很可能會覺得很奇怪沒反應(yīng)檩奠，然后再點(diǎn)一次桩了。這些手動埋點(diǎn)不易察覺的細(xì)節(jié)附帽，自動埋點(diǎn)都能記錄，所以說井誉，自動埋點(diǎn)在這些情況下會更貼近真正的用戶行為蕉扮。
自動埋點(diǎn)可降低原來手動埋點(diǎn)的個數(shù)和復(fù)雜性，使之更簡化
比如：進(jìn)入“商品詳情頁面”（展現(xiàn)）颗圣，目前包括5個手動埋點(diǎn)喳钟，實(shí)際上用自動埋點(diǎn)只需要一個就夠了，而且自動埋點(diǎn)不會遺漏在岂。從數(shù)據(jù)來看奔则，一個自動埋點(diǎn)的PV已經(jīng)超過5個手動埋點(diǎn)之和。
自動埋點(diǎn)可采集界面環(huán)境數(shù)據(jù)蔽午，但是數(shù)據(jù)不夠純易茬，需要進(jìn)一步去噪
自動埋點(diǎn)能采集到大部分用戶“看到的而且有用數(shù)據(jù)”。比如：“價格”這一屬性及老，手動埋點(diǎn)可直接定義“amout: 5.2“來輕松獲取數(shù)據(jù)抽莱，而自動埋點(diǎn)獲取的是一串文本： “價格預(yù)估5.2元”，若要獲取精確的5.2這個數(shù)值骄恶，就需要進(jìn)一步解析食铐。
自動埋點(diǎn)無法替代手動埋點(diǎn)，但可大大減少手動埋點(diǎn)工作量可預(yù)想的是僧鲁，在用戶行為分析上虐呻，自動埋點(diǎn)可以滿足很大一部分需求函數(shù)級的埋點(diǎn)無法用自動埋點(diǎn)代替，后臺非UI的事件也無法用自動埋點(diǎn)代替寞秃，自動埋點(diǎn)無法攜帶當(dāng)時的業(yè)務(wù)場景數(shù)據(jù)，這些都表明了自動埋點(diǎn)無法完全替代手動埋點(diǎn)蜕该。
但單就用戶行為分析來講，自動埋點(diǎn)是可以覆蓋用戶的一些基本行為路徑的堂淡，并能做一些較淺層次的分析。如果需要探究用戶行為背后的原因绢淀、或需要進(jìn)一步深入分析行為的時候，就是需要更多的后臺邏輯事件皆的、需要攜帶更多屬性值的時候，就需要通過手動埋點(diǎn)來完成。所以栖雾，但是深層次的分析是你的重點(diǎn)伟众，就需要使用手動埋點(diǎn)來解決。
埋點(diǎn)類型雖然當(dāng)前也就這幾類解決方案凳厢，而且真實(shí)的使用請求會根據(jù)業(yè)務(wù)混合使用多種埋點(diǎn)類型账胧。但是我們除了選擇好埋點(diǎn)類型外，要展開埋點(diǎn)工作先紫，面臨的溝通協(xié)調(diào)治泥，如何準(zhǔn)確多團(tuán)隊(duì)達(dá)成共識，并確保各方對業(yè)務(wù)和埋點(diǎn)深度理解遮精，做要的工作和面臨的挑戰(zhàn)會更大居夹。想要做好埋點(diǎn)工作，埋點(diǎn)需求的整理很重要仑鸥，且需要遵守一定的原則吮播，所以我們引用滴滴內(nèi)部Omega團(tuán)隊(duì)針對這些原則的整理（本來很多內(nèi)容均采用了Omega團(tuán)隊(duì)的日常工作整理，Omega是滴滴內(nèi)部服務(wù)的強(qiáng)大數(shù)據(jù)采集和分析平臺眼俊，期待Omega開源或開放的一天，在此感謝滴滴Omega團(tuán)隊(duì)的深度沉淀）：
理清楚了埋點(diǎn)的思路粟关，要讓埋點(diǎn)順利進(jìn)行疮胖，且不影響線上功能，則需求嚴(yán)格的埋點(diǎn)規(guī)范和治理方案闷板。
埋點(diǎn)規(guī)范
某些企業(yè)澎灸，保守估計，手動埋點(diǎn)的錯誤率可能會高達(dá)50%遮晚，比如一些簡單頁面的進(jìn)入應(yīng)該埋在 viewDidAppear（didMount...）性昭，按鈕點(diǎn)擊應(yīng)該埋在 onClickListener等等都經(jīng)常被開發(fā)弄錯。埋點(diǎn)工作本身并不難县遣，是純粹的體力活糜颠，但是要展開一個好的埋點(diǎn)工作，需要BI先梳理萧求，然后再傳達(dá)給RD其兴，然后RD再去開發(fā)實(shí)現(xiàn)，最后應(yīng)該經(jīng)過測試驗(yàn)收夸政，因?yàn)闆]有統(tǒng)一的標(biāo)準(zhǔn)元旬，每個人的理解不一樣，就很容易弄錯，后面會和大家在詳細(xì)聊聊埋點(diǎn)規(guī)范的問題匀归。
我們了解的一些大公司穆端，像Facebook等硅谷公司已經(jīng)將埋點(diǎn)看得與產(chǎn)品設(shè)計同等重要，新功能還在設(shè)計階段就先把衡量指標(biāo)及埋點(diǎn)梳理好徙赢，而具體負(fù)責(zé)埋點(diǎn)的RD也是團(tuán)隊(duì)中最資深的RD（如果不是專職的話）狡赐，RD需要每天不斷的與BI溝通確保語義一致枕屉。
而我待過的滴滴、陸金所等公司的現(xiàn)狀是西潘，埋點(diǎn)的RD很多時候都是隨機(jī)任務(wù)分工的喷市，甚至經(jīng)常被安排給實(shí)習(xí)生品姓，埋點(diǎn)質(zhì)量難以保證箫措。還有一種情況是產(chǎn)品為了快速上線需求斤蔓，一味追求上線速度弦牡，在需求評審階段沒有梳理和提出埋點(diǎn)需求，上線后臨時插入埋點(diǎn)需求喊儡，在未經(jīng)過分析理解和測試驗(yàn)收的情況下匆匆加入埋點(diǎn)代碼艾猜，而且測試經(jīng)常也不重視測試（提出免測），導(dǎo)致埋點(diǎn)錯誤淤毛，甚至是業(yè)務(wù)代碼錯誤等線上問題低淡。這種情況下自動埋點(diǎn)既能減少溝通開發(fā)的工作量瞬项，又能降低埋點(diǎn)出錯的概率囱淋。所以，自動埋點(diǎn)更適合公司在埋點(diǎn)規(guī)范沒有完全建立皂吮，埋點(diǎn)質(zhì)量普遍不高的階段蜂筹。但是公司體量到一定程度后艺挪，RD和產(chǎn)品經(jīng)理將會更頻繁的和手動埋點(diǎn)接觸兵扬，我們作為一個手動埋點(diǎn)的深度用戶團(tuán)隊(duì)周霉，談?wù)勎易约旱膶κ止ぢ顸c(diǎn)的痛點(diǎn)梳理：
- 埋點(diǎn)混亂
- 常常埋錯俱箱，漏埋
- 業(yè)務(wù)變化后狞谱，老埋點(diǎn)數(shù)據(jù)失去意義
- 埋點(diǎn)數(shù)據(jù)無人使用跟衅，浪費(fèi)資源
- 數(shù)據(jù)團(tuán)隊(duì)播歼、研發(fā)團(tuán)隊(duì)、產(chǎn)品團(tuán)隊(duì)協(xié)作配合難度大
- 很多時候不太重視數(shù)據(jù)蹈集，而是重視業(yè)務(wù)的快速上線
- 埋點(diǎn)語義不明確拢肆，同一個按鈕存在多種描述郭怪，不易檢索
- 無用/重復(fù)埋點(diǎn)太多刊橘，干擾了正常埋點(diǎn)數(shù)據(jù)
- 大量存量埋點(diǎn)Owner離職或者轉(zhuǎn)崗伤为，導(dǎo)致大量僵尸埋點(diǎn)信息
那么如何避免以上問題呢？建立一個好的規(guī)范非常重要叙甸，包括命名規(guī)范和流程規(guī)范裆蒸。
埋點(diǎn)命名規(guī)范
我們當(dāng)前的做法是埋點(diǎn)名稱只能是由字母僚祷、數(shù)字辙谜、下劃線組成感昼，并保證在應(yīng)用內(nèi)唯一定嗓，比如sw是展示，ck是點(diǎn)擊凌简。
常用規(guī)則的舉例如下：
比如行為埋點(diǎn)：{團(tuán)隊(duì)|業(yè)務(wù)|角色}{組件|頁面}{具體元素}_{動作}
示例：
yourteam_fc_all_msg_ck
autoplatform_flowtab_sw ： autoplatform代表業(yè)務(wù)線雏搂，flowtab 代表功能，sw代表頁面操作铅碍，sw是展示胞谈，ck是點(diǎn)擊
uber_comt_share_ck ：uber業(yè)務(wù)線烦绳，comt評價組件配紫，share分享按鈕躺孝，ck點(diǎn)擊
埋點(diǎn)流程規(guī)范
如果你發(fā)現(xiàn)每天有大量埋點(diǎn)錯誤反饋，并導(dǎo)致很多錯誤的分析結(jié)論惧眠，一個錯誤的分析結(jié)果還不如沒有數(shù)據(jù)分析結(jié)果氛魁。造成這個問題的原因包括：
- 前端埋點(diǎn)涉及復(fù)雜的交互秀存，難以找準(zhǔn)埋點(diǎn)位置羽氮；
- 埋點(diǎn)的驗(yàn)收流程不完善档押，沒有經(jīng)過測試和產(chǎn)品經(jīng)理的測試和驗(yàn)收汇荐，驗(yàn)證不完備掀淘；
好的埋點(diǎn)需求應(yīng)該和業(yè)務(wù)功能需求同等重要革娄，也需要經(jīng)歷軟件開發(fā)的整個生命周期，如果能嚴(yán)格按照一個規(guī)范的流程處理埋點(diǎn)匆浙，以上問題會得到更好的解決厕妖。
規(guī)范內(nèi)容
需求階段：
確定埋點(diǎn)信息言秸，核心包括五方面信息：事件ID举畸、埋點(diǎn)名稱、埋點(diǎn)描述跋核、埋點(diǎn)屬性以及截圖砂代。
舉例：
- 快車頁面打車的埋點(diǎn)信息為：
- 埋點(diǎn)ID為：gulf_p_f_home_order_ck
- 埋點(diǎn)名稱為：呼叫快車
- 埋點(diǎn)描述：在快車首頁點(diǎn)擊呼叫快車按鈕泊藕。
如何落地：
如果不按照規(guī)則和流程埋點(diǎn)將不會上報相關(guān)數(shù)據(jù)难礼，制定強(qiáng)制規(guī)定蛾茉。
開發(fā)什么功能：
埋點(diǎn)全文檢索能力谦炬、自動找到重復(fù)埋點(diǎn)（語義相近或者數(shù)據(jù)相近）功能。
開發(fā)階段：
務(wù)必和開發(fā)溝通础爬，并讓開發(fā)在完全理解業(yè)務(wù)語義的情況下看蚜，在前端按照埋點(diǎn)代碼規(guī)范進(jìn)行埋點(diǎn)供炎。
舉例：
比如針對商品購買按鈕，在前端點(diǎn)擊方法的第一行調(diào)用SDK惨奕，最好也傳入文本字面描述梨撞。
如何落地：
靜態(tài)代碼檢查蜓氨。
開發(fā)什么功能：
開發(fā)探測每個埋點(diǎn)對應(yīng)到的代碼文件和代碼行穴吹，開發(fā)根據(jù)人均事件量級進(jìn)行監(jiān)控報警功能。
測試階段：
務(wù)必和測試溝通啥容，并讓測試在完全理解業(yè)務(wù)語義的情況下咪惠，通過CodeReview和埋點(diǎn)測試兩種方式對埋點(diǎn)正確性進(jìn)行驗(yàn)證遥昧。
舉例：
比如針對商品購買按鈕埋點(diǎn)炭臭，需要檢查埋點(diǎn)測試中上傳數(shù)據(jù)中事件ID袍辞、屬性是否符合定義搅吁，另外觸發(fā)時機(jī)是否正確。
如何落地：
規(guī)定如果未經(jīng)測試的埋點(diǎn)不允許上報埋點(diǎn)數(shù)據(jù)肚豺。
開發(fā)什么功能：
提供所見即所得的埋點(diǎn)測試平臺详炬。
驗(yàn)收階段：
確保相關(guān)人員在完全理解業(yè)務(wù)語義的情況下呛谜，可以通過與自比較和他比較的方式來進(jìn)行驗(yàn)證隐岛。
舉例：
自比較驗(yàn)證：同一APP某一個業(yè)務(wù)線的購買冒泡數(shù)量一定要小于所有業(yè)務(wù)線的冒泡數(shù)合計聚凹；
他比較驗(yàn)證：前端某業(yè)務(wù)點(diǎn)數(shù)量和對應(yīng)服務(wù)端數(shù)據(jù)應(yīng)該基本相當(dāng)妒牙。
如何落地：
規(guī)定如果未經(jīng)驗(yàn)證的埋點(diǎn)不允許上報埋點(diǎn)數(shù)據(jù)湘今。
開發(fā)什么功能：
提供埋點(diǎn)實(shí)時數(shù)據(jù)查詢剪菱。
清理階段：
確認(rèn)完全理解語義的情況下孝常，可對業(yè)務(wù)發(fā)生巨大變化或者不在維護(hù)的埋點(diǎn)進(jìn)行廢棄构灸。
舉例：
百度糯米合并餓了么后，埋點(diǎn)在經(jīng)歷產(chǎn)品大改版后已經(jīng)和其他業(yè)務(wù)線合并稠氮，需要廢棄之前的遺留埋點(diǎn)括袒。
如何落地：
3個月以上未被使用的埋點(diǎn)锹锰、1個月以上數(shù)據(jù)為0的埋點(diǎn)自動廢棄恃慧。3個月后使用次日會自動開啟采集渺蒿。
開發(fā)什么功能：
根據(jù)規(guī)則提供針對未使用埋點(diǎn)的計算茂装、并自動廢棄。
可以看出城侧，規(guī)范要落地，需要整個公司的共識豆茫，也需要從上而下的壓力揩魂，還有強(qiáng)勢的制度火脉。比如針對全公司個部門做評分忘分，評分規(guī)則基于埋點(diǎn)和數(shù)據(jù)分析抽象出來白修。
另外我們在前端埋點(diǎn)中也遇到過一些注意事項(xiàng)兵睛，整理如下祖很，希望對大家有所幫助。
注意事項(xiàng)：
一些埋點(diǎn)安全性問題：
如果你使用普通的http 協(xié)議胚鸯，在數(shù)據(jù)傳輸?shù)倪^程存在被劫持(包括不限于：JS代碼注入等)的可能性姜钳，造成H5頁面中出現(xiàn)諸如：未知的廣告或者原網(wǎng)頁被重定向等問題哥桥。為了降低此類事件發(fā)生的可能性拟糕，建議最好使用https 協(xié)議（倡導(dǎo)全站https），以確保數(shù)據(jù)傳輸過程的完整性侠草，安全性梦抢。
版本迭代的時候埋點(diǎn)需要注意什么？
- 如果是公用模塊哼蛆，可以非常放心安全的全量遷移埋點(diǎn)腮介；
- 如果是新增模塊，那就需要注意是否遵循了最新的埋點(diǎn)規(guī)范甘改，有沒有重復(fù)的埋點(diǎn)命名存在十艾，埋點(diǎn)是否符合業(yè)務(wù)邏輯忘嫉；
- 如果是下線模塊案腺，那就需要評估下線后對數(shù)據(jù)的影響范圍劈榨，而且要第一時間充分周知相關(guān)方同辣，讓各方參與評估；
- 如果是更新模塊跌前，需要評估在原有埋點(diǎn)上需要修改的埋點(diǎn)內(nèi)容抵乓，是否需要重新埋點(diǎn)灾炭，刪除不需要的埋點(diǎn)，而且要修改功能的數(shù)據(jù)承接田弥。
關(guān)于埋點(diǎn)上報的解決方案
一般會實(shí)現(xiàn)上個模塊偷厦，Event收集器只泼，Event緩存器请唱，和Event上報器过蹂。
Event上報模式
除了用戶個人不希望耗費(fèi)流量以外酷勺，也可能會因?yàn)槿蹙W(wǎng)及斷網(wǎng)情況，如果確保數(shù)據(jù)不丟失勋功，基于這些問題而誕生的上傳策略狂鞋，來設(shè)計如何上報已收集的所有事件數(shù)據(jù)潜的。上報一般包括針對內(nèi)存實(shí)時數(shù)據(jù)的上報和本地持久化數(shù)據(jù)上報兩個部分啰挪，分別介紹一下它們的上報策略與實(shí)現(xiàn)方式：
內(nèi)存埋點(diǎn)數(shù)據(jù)的實(shí)時上報
針對內(nèi)存埋點(diǎn)數(shù)據(jù)的上報策略一般如下：
基于時間間隔：每隔 n秒（時間間隔可以根據(jù)公司的業(yè)務(wù)情況自定義）
基于數(shù)據(jù)條數(shù)：每累積 n條數(shù)據(jù)（條數(shù)可以自定義）
不間斷實(shí)時上報亡呵，如果是低頻率，數(shù)據(jù)量小下硕，實(shí)時性要求高的數(shù)據(jù)可以不設(shè)限制
上述條件滿足時梭姓，便會觸發(fā)從內(nèi)存中讀取數(shù)據(jù)，并執(zhí)行上傳操作罪既。Native可以創(chuàng)建了一個并發(fā)隊(duì)列琢感，H5會基于瀏覽器并發(fā)發(fā)送猩谊。
本地持久化數(shù)據(jù)的延遲上報
為了盡早的上傳本地持久化埋點(diǎn)數(shù)據(jù)祭刚，以防用戶卸載 App或者關(guān)閉瀏覽器造成本地數(shù)據(jù)的丟失涡驮，針對本地持久化數(shù)據(jù)的上傳策略如下：
Native相關(guān)：
App 冷啟動
App 進(jìn)入前臺
App入后臺
HTML5捉捅、Hybrid相關(guān)：
localstorage棒口，瀏覽器關(guān)閉埋點(diǎn)數(shù)據(jù)并不會被刪除无牵，如果用戶再次訪問厂抖，會啟動上報
基于Native提供的bridge忱辅，讓Native幫忙持久化數(shù)據(jù)墙懂，并在再次進(jìn)入時，啟動上報
這里也可以創(chuàng)建一個單獨(dú)的串行隊(duì)列碧库，來實(shí)現(xiàn)對本地持久化數(shù)據(jù)的逐個上報。
作者：譙洪敏
鏈接：https://www.imooc.com/article/27151
來源：慕課網(wǎng)
本文原創(chuàng)發(fā)布于慕課網(wǎng) 旅挤，轉(zhuǎn)載請注明出處粘茄，謝謝合作
