埋點的意義

用戶數(shù)據(jù)的收集一直是持之以恒的話題。在最早的時候，開發(fā)商或者開發(fā)者沒想要那么多數(shù)據(jù)，他們最想要的是用戶診斷日志。因為網(wǎng)絡不發(fā)達和軟件分發(fā)的模式，導致用戶遇到問題就很難定為和解決。所以要么上門，要么你把日志拷給他。我想最早的用戶數(shù)據(jù)最多是軟硬件環(huán)境和出錯日志。

到了我使用PC的年代，當操作系統(tǒng)遇到問題時，用戶已經(jīng)可以選擇發(fā)送日志給微軟了。當然網(wǎng)絡依然不發(fā)達，除了一些大型應用外，其它的都不考慮這條用戶和開發(fā)商之間的通道。而事實上很長很長一段時間，除了操作系統(tǒng)在收集用戶信息，其它軟件，惡意軟件除外，壓根都沒想到過。

到了互聯(lián)網(wǎng)web 2.0時代，網(wǎng)頁埋點被慢慢應用起來。原因大致有二，一用戶已經(jīng)不再貧窮，他們的網(wǎng)絡很好，他們的選擇很多。二，開發(fā)商也意識到用戶體驗的重要性，他們需要收集數(shù)據(jù)來推進體驗。那個時候還沒有想用數(shù)據(jù)進行大數(shù)據(jù)分析，當然有利用用戶信息推送廣告的廣告系統(tǒng)。所以當時的埋點一般都為性能埋點和頁面流轉(zhuǎn)埋點。這種思想也催生了GA 這種偉大的產(chǎn)品。網(wǎng)站的線上監(jiān)控的理念和產(chǎn)品也應運而生。到今天各種APM 公司，傳統(tǒng)網(wǎng)站依然是重度用戶。

當時互聯(lián)網(wǎng)廣告也很火，這里不得不提一下cookie，網(wǎng)頁端用戶信息載體。有一天，你在北京上某個網(wǎng)站，突然給你推了條上海的酒店廣告。那很多可能你最近查詢了上海旅行和住宿信息，這些信息在cookie里，上傳后被廣告系統(tǒng)處理，然后你就變成了前面出現(xiàn)的廣告的target?？梢哉f，如果沒有cookie，互聯(lián)網(wǎng)廣告行業(yè)估計就不會那么有意思。

時光荏苒，一不小心到了移動時代。我記得我和小伙伴們做的第一款手游集成了友盟來收集用戶的手機信息，
游戲的日活，用戶的登錄登出，打開時長等等。我們當時其實沒有把這些數(shù)據(jù)用起來，一來對用戶數(shù)據(jù)不敏感，二來沒有專業(yè)BD ，也分析不出個蛋來。

我后來換了個工作，去做移動廣告，就是谷歌的admob，蘋果的iAd 同種類型的。大家應該都知道移動應用端已經(jīng)失去了cookie ，開發(fā)者無法隨心所欲的收集用戶信息，要來定位一個用戶就異常困難。移動廣告講轉(zhuǎn)化率，用戶A 通過點擊廣告下載了某應用，怎么判斷他又安裝了該應用呢？這是個大難題。我們那個時候的轉(zhuǎn)化率誤差很大，開發(fā)每天都在改進算法，增加緯度。而這些算法基于的就是客戶端的埋點信息的收集。

后來我加入阿里，又到支付寶，更加體會到埋點的重要性，我們后續(xù)會講。

哪些端需要埋點？

昨天有同事問服務端要埋點嗎？我的看法是你想要的信息是否容易獲??？我們知道客戶端埋點是因為客戶端的行為不受控制，信息不易獲取，所以大量采用埋點。如果你的服務端也有類似問題，比如大規(guī)模集群，那你要看某個特定日志必然困難重重，這個時候就需要服務端埋點或者說服務端監(jiān)控，不過就不是埋點那么簡單粗暴了。這個可以了解下 oneAPM 的技術。
個人覺得，到用戶手上的產(chǎn)品，即客戶端都需要埋點。在民眾生活中露出的無非是三張屏幕：

• 電腦顯示屏
• 手機屏幕
• 電視屏幕

所以不要覺得沒人關心你，軟件開發(fā)商無時無刻不在關心你。

哪些場景需要埋點？

我主要講下我略微了解的客戶端埋點，埋點是藝術活，埋的好，可以給你帶來漂亮的報表，有錢途的業(yè)務模型等等。埋的不好，數(shù)據(jù)沒有用，還占資源。

我們從需求出發(fā)，業(yè)務人員想要知道哪些業(yè)務使用量大，開發(fā)人員想了解產(chǎn)品的性能，穩(wěn)定性，老板想要pv,uv。人人都是產(chǎn)品經(jīng)理，人人都會提需求。那我們不妨把這些需求歸類為：

• 用戶行為：記錄用戶使用過程中的行為，用于產(chǎn)品和運營人員分析PV和點擊等產(chǎn)品數(shù)據(jù)。
• 質(zhì)量監(jiān)控：記錄客戶端閃退、異常、性能等質(zhì)量數(shù)據(jù)，用于技術和運營人員監(jiān)控質(zhì)量異常。
• 運行跟蹤：記錄程序運行過程中打印的日志，這部分日志會存在手機上，用于開發(fā)人員分析問題。

運行跟蹤不適合埋點，從說明也能看出，這個類似于windows的診斷日志，只有用戶出問題，主動要求診斷的時候才會用到。

如何埋點？

如何埋點，其實涉及到一個非常龐大的監(jiān)控系統(tǒng)的設計，這方面我沒有任何經(jīng)驗，我從使用者的角度來推敲下。

1. 模型設計
   對于每種類型的埋點，需要建立好可擴展的模型，大家應該關注到上面圖片中的可擴展信息，再最初的時候，可能一下子無法想到所有的信息，所以我們需要自己方便擴容的模型。
2. 埋點規(guī)范
   也許我們有很多客戶端，應用A，應用B。如果埋點規(guī)范不統(tǒng)一，那么埋點信息上傳之后，就可能需要多套系統(tǒng)來解析了。這就非常的不劃算了。需要結(jié)合設計好的模型，給出基本的埋點規(guī)范，當然也要給客戶端足夠多的發(fā)揮空間。
3. 自動埋點和主動埋點
   無論是網(wǎng)頁應用還是移動應用，想要別人遵守規(guī)則，最好的辦法就是給你一個sdk，集成到你的應用中去就可以了。所以我們可以把一部分埋點行為在sdk中做掉，比如上圖中的手機信息。然后開發(fā)者需要調(diào)用sdk中的接口進行主動埋點，那些業(yè)務埋點就需要借助這些接口了。
4. 上傳機制
   我們不可能時時上傳埋點信息，如果那樣，簡直就是流氓軟件，流量小偷了。合理的上傳策略，比如間隔半小時上傳一次，在用戶在使用 wifi 情況下上傳，壓后臺時候上傳。只有做到用戶無法感知的上傳，才算是合格的埋點。
5. 日志保留時間
   如果我們一直沒有成功上傳，日志越攢越多，那肯定會占用不少空間，這對手機的影響是非常大的。所以制定策略，無論是定時清除，還是定量清除，總之不能讓用戶在他的手機里發(fā)現(xiàn)日志怪獸。
6. 展示平臺
   相信海量埋點上傳之后，肯定會用到數(shù)據(jù)庫，針對埋點模型設計好的數(shù)據(jù)模型，可以更好的幫助數(shù)據(jù)同學做出多維度的報表。有了數(shù)據(jù)之后， 怎么做，就是每個公司自己的事情。

埋點之后，測試要干什么？

其實有了這些埋點后，在灰度期間，上線初期就可以關注收集的數(shù)據(jù)，發(fā)現(xiàn)問題就能及時修復。那么測試需要干嘛呢？

1. 首先在發(fā)布前要保證埋點是正確的。
2. 發(fā)布之后，要時刻關注監(jiān)控大盤，無論你是主動去數(shù)據(jù)庫撈數(shù)據(jù)，還是去已經(jīng)做好的監(jiān)控大盤。
3. 拉取性能數(shù)據(jù)和之前版本做比較，拿數(shù)據(jù)證明質(zhì)量是否改善。
4. 在發(fā)布一段時間后，拉取各種數(shù)據(jù)，去噴開發(fā)，pd們！

拋磚引玉

我對這塊的理解也就差不多那么多。監(jiān)控是永恒和未來，而埋點是一切數(shù)據(jù)的來源。我先拋出這塊磚頭，看看其他高手或者內(nèi)家有沒有經(jīng)驗分享。