前言
近期，應PM要求，對應用的埋點方案進行了調研跋核，特在此寫個博客記錄分享一下岖瑰。
需求分析
首先我們需要清楚埋點的實際需求是什么？對于一個產(chǎn)品來講埋點無非就是想了解用戶的使用習慣和產(chǎn)品的使用情況砂代，從而從客戶和產(chǎn)品的角度去了解客戶群體蹋订，及其對產(chǎn)品的一些使用想法。本文將著重關注數(shù)據(jù)的收集而非數(shù)據(jù)分析刻伊。
數(shù)據(jù)處理
在這里辅辩，我們需要明確的一點是，數(shù)據(jù)處理的整個過程中娃圆，數(shù)據(jù)的收集是重中之重，它將是我們進行數(shù)據(jù)的分析的大前提蛾茉，因為采集的數(shù)據(jù)會直接影響到最后的分析結果讼呢。
因此，數(shù)據(jù)采集應具備以下幾點特性：
多元性
采集過程應從不同的維度去獲取數(shù)據(jù)谦炬。比如我們要采集用戶相關的部分數(shù)據(jù)悦屏。那么我們可以從身高、體重键思、興趣愛好等各個層次础爬、多維度的去采集對應數(shù)據(jù)。這樣的數(shù)據(jù)還原出來的用戶對像才更有活性吼鳞，對于今后的數(shù)據(jù)分析看蚜、包括描繪用戶畫像也更為有利。
準確性
準確性包含兩個層次的要求：1.數(shù)據(jù)采集過程的準確性：對于特定的流程分析赔桌，我們的埋點方案要具備一定的針對性供炎，避免無關因素的干擾。2.數(shù)據(jù)的客觀性疾党。我們不能代替客戶音诫，我們能做的只是觀察并記錄，臆想的數(shù)據(jù)對于我們毫無價值雪位。
時效性
對于采集的數(shù)據(jù)竭钝，它只能反映過去的某個時刻或者某段時間的客觀情況。得到的結果和結論也只能是對應過去的某個時間段而言雹洗∠愎蓿可能是受制于當時的網(wǎng)絡情況、社會環(huán)境等因素的影響时肿，才會呈現(xiàn)出這樣的結果穴吹。所以我們在采集數(shù)據(jù)的同時最好能給它打上時間標簽，方便今后的數(shù)據(jù)對比嗜侮。
ok港令，接下里進入正題－－埋點
什么是埋點啥容？
簡單的說，埋點就是定時顷霹、定點的數(shù)據(jù)采集咪惠，然后上報。
舉個簡單的??
如圖淋淀，比如我們在到達頁面A的時候遥昧，進行數(shù)據(jù)采集和上報，告訴服務器我是誰朵纷？我在哪里炭臭？我干了些什么？而后進入頁面B袍辞，進行相同的操作鞋仍，以此類推。最后后臺可以根據(jù)得到的數(shù)據(jù)還原用戶的各種行為搅吁，最終將這些數(shù)據(jù)呈現(xiàn)出來威创，方便運營等進行分析操作。（技術上講谎懦，這里實際上還包含數(shù)據(jù)存儲和傳輸?shù)葐栴}肚豺，不同的埋點方案的處理方式都不盡相同，這里就不做過多的闡述了界拦。）
埋點方案一：代碼埋點
代碼埋點是很多人一開始就會想到的方案吸申，也是目前最為人所知的一種方案。包括友盟在內(nèi)的一些服務商目前都在使用這種方案享甸。實現(xiàn)方式相信大家一看就明白呛谜，就是在需要數(shù)據(jù)采集的地方抓取數(shù)據(jù)，然后上傳枪萄。
要指出的是隐岛，這里的數(shù)據(jù)采集往往會以事件的方式進行。事件包含事件名稱瓷翻、事件參數(shù)等聚凹，簡單的點擊事件統(tǒng)計(比如統(tǒng)計點擊事件)僅需事件名稱即可，如果想抓住事件內(nèi)部的一些數(shù)據(jù)的話齐帚，比如電商領域的一些交易統(tǒng)計妒牙，就會在用戶點擊提交購買按鈕的時候在事件參數(shù)里傳遞總價等數(shù)值。在開發(fā)文檔里对妄，后者通常會被稱為自定義事件湘今，這也是代碼埋點最具靈活性的地方。
這種方案的優(yōu)點在于它的準確性和針對性剪菱。指哪打哪摩瞎，不浪費一發(fā)子彈拴签。如果項目較小或者還只是在項目初期，這種方案還算可以接受旗们，但是如果在較大的項目項目或者處于開發(fā)后期的項目來做蚓哩，對于程序員來講無疑是身心上的摧殘。一方面工作量太大上渴，這種特定的頁面的數(shù)據(jù)采集方案（PM：什么岸梨？不知道埋哪里？那就都埋了吧３淼）能偷懶的地方都沒有曹阔；另一方面，這種方案對代碼的入侵性太大隔披，很可能導致代碼高耦合赃份，并且這種方式采集的數(shù)據(jù)維度往往會太過單一。如果今后想從更高的層面或者其他角度去分析锹锰，很有可能需要重新埋點和發(fā)布版本。
埋點方案二：可視化埋點
代碼埋點將核心代碼和配置資源進行了分離。在每次啟動的時候都會有去請求最新的埋點配置渺蒿，他在一定程度上降低了代碼埋點的門檻痢士，只要客戶端集成之后，PM在web上就可以進行操作(讓PM自己玩去吧╮(╯▽╰)╭)
那么它是如何實現(xiàn)的呢茂装？
如圖怠蹂，簡單來說，客戶端集成SDK之后少态，在用戶使用的過程中會定時截圖城侧，同時獲取應用視圖的層級關系，傳到服務端彼妻。服務端會重新渲染頁面嫌佑，并判斷控件是否可以埋點，然后關聯(lián)對應的埋點事件侨歉，最后將配置信息傳回客戶端屋摇。
這種方式從某種程度上大大提升了應用的埋點靈活性，使用方便幽邓。當然它也有一定的局限性炮温，比如埋點的內(nèi)容有限，不能像代碼埋點一樣采用自定義事件,所以對于較為深入的行為分析要求牵舵，這種方案不能很好的實現(xiàn)柒啤。
埋點方案三：無埋點
無埋點的的技術方案倦挂，早在2013年就已提出了。它在客戶端集成之后白修，會主動的盡可能多的收集數(shù)據(jù)妒峦，甚至連要在那里埋點的問題都省略了，我們不用去設置配置文件兵睛，如果我們想要特定的數(shù)據(jù)直接去查詢即可（這就是為什么叫無埋點）肯骇。
與可視化埋點相比，無埋點主要解決的是數(shù)據(jù)的回溯問題祖很。比如笛丙，我們想要得到某個頁面的訪問數(shù)量，如果是可視化埋點假颇，就需要去配置一下埋點方案胚鸯，然后發(fā)布，一段時間之后才會得到對應的數(shù)據(jù)笨鸡。我們無法獲取到發(fā)布之前的某個時間內(nèi)的訪問情況姜钳。也就是說所有想得到的數(shù)據(jù)只有在配置文件發(fā)布之后才能看到。對于無埋點方案來講形耗，這些數(shù)據(jù)的采集早在SDK集成的時候就開始了哥桥。某天突然想要看下，查詢下就可以看到了。當然，它的缺點也是顯而易見的兼耀，采集的數(shù)據(jù)越多，對于數(shù)據(jù)傳輸和存儲的要求就會越高送滞。
其實，有時候對于某些檢測行為辱挥，我們并非一定要在客戶端做犁嗅。考慮到數(shù)據(jù)處理過程中的傳輸和存儲問題（本地數(shù)據(jù)存儲）晤碘，在服務端進行埋點和分析會顯得事半功倍愧哟。
一些國內(nèi)外的服務商
Google Analytics（Firebase Analytics）
https://firebase.google.com/docs/database/ios/start
Firebase Analytics是2016年在Google I/O上推出的針對移動應用的服務。
Flurry
https://developer.yahoo.com/flurry/docs/analytics/gettingstarted/technicalquickstart/ios/
Localytics
http://docs.localytics.com/dev/ios.html
Mixpanel
https://mixpanel.com/help/reference/ios
(支持可視化埋點)
Umeng
http://dev.umeng.com/analytics/ios-doc/integration?spm=0.0.0.0.t9tzbd
Growing IO
https://help.growingio.com/SDK/iOS.html
（國內(nèi)無埋點方案－無埋點的啟發(fā)性更好哦）
TalkingData
https://www.talkingdata.com/tracking/documents/AdTracking_SDK_iOS_%E9%9B%86%E6%88%90%E6%96%87%E6%A1%A3.pdf
以上都是集成文檔的鏈接哼蛆，各家都有自己的特點蕊梧。具體方案請視自己的情況而定。
自行搭建埋點服務
有時候我們也會遇到數(shù)據(jù)是有了腮介，但是當要把原始數(shù)據(jù)做導出分析時又遇到問題肥矢。自己產(chǎn)品的數(shù)據(jù)卻不能被我們自己擁有。
這里介紹兩款免費開源的私有化部署方案
1.cobub razor
傳送門：http://www.cobub.com
2.countly
傳送門：https://count.ly
總結：
不同的埋點方案都有各自的優(yōu)缺點，對于不同的業(yè)務需求甘改，一種埋點方案明顯無法滿足 旅东，所以往往我們需要結合多種方案進行處理。
最后十艾，希望本文能拓寬大家對于埋點的思路吧：）
若文章中有不對的地方望指正抵代，萬分感謝！
本文提到的服務商與本人沒有利益關系.
參考文章
1.http://www.itechdog.com/blog/event-tracking?utm_source=tuicool&utm_medium=referral
2.http://www.reibang.com/p/973d626fa19a
3.http://www.reibang.com/p/4e1b371ec46a
4.https://www.zhihu.com/question/41831617
