1 寫在之前
接上一章的架構圖，我們知道我們只是起了個頭，後續還有待完善的部分。
這一章節暫時不講，我們在上一章成果的基礎上，講述一下整個數據收集的相關故事，以及期間的一些收穫和思考。
主要是和研發團隊之間的“愛情火花”。
在數據生態的第一環中，最核心的問題就是基礎數據的收集，這是一切的後續數據挖掘、使用的前提。
而說到數據收集，通過埋點的數據收集則又是重要的一環，這就必然避免不了與客戶端開發人員的交互。
這也是“愛恨情仇”的源頭。
所以，在這裏就引出了一個話題，如何進行跨部門的高效合作，以及如何推動項目的有效進行。
此外，對於數據埋點收集，也有很多需要注意的事項，如何建立一個比較合理完善的埋點體系，也是一個值得研究的問題。
分享之前我還是要推薦下我自己創建的大數據學習交流Qun: 710219868 有大佬有資料， 進Qun聊邀請碼填寫 南風（必填 ）
有學習路線的分享公開課，聽完之後就知道怎麼學大數據了
2 數據埋點體系的建設
在講故事之前，我們先來理一下埋點這個事情。
(1) 建立埋點體系的核心目的在哪?
我們建立整個埋點體系，其核心目的是什麼？我們希望通過點位數據的觸發，來掌握用戶操作的一舉一動。
說白了，就是收集用戶的任何操作的反饋數據，然後基於此做一些價值挖掘方面的事。
例如：
-
基本的產品活躍狀態監控，留存分析、流失分析、新增變化、忠誠分析、渠道分析等。
-
基本信息獲取，例如機型、網絡類型、操作系統，IP地域等，繪製基礎用戶人羣畫像。
-
推薦系統，根據用戶行爲操作，爲用戶繪製興趣畫像，進行精準的興趣推薦。
-
查看頁面的按鈕點擊分佈，提升主路徑的轉化效果，刪減頁面殭屍按鈕，產品做減法，優化用戶體驗。
-
-
主路徑流失分析，漏斗模型，提升轉化效果。
-
搜索效果分析，掌握用戶的搜索熱點，幫助進行數據運營
-
其實還有很多很多其他數據方面的應用。
我們通過真實的基礎數據收集，進一步的進行加工整理，能夠從中獲取很多有用的信息，用於精準化運營、洞察性運營，提升用戶體驗，優化我們的產品。
只要想象力足夠，收集的信息足夠完全，我們是可以通過數據做很多事情的。
但前提是收集的數據足夠多，足夠準確！
(2) 維護一張埋點數據編碼表
說到收集的數據足夠多，足夠準確，我們維護了近一千個點位的操作數據收集。
相信對於第三方數據分析平臺熟悉的童鞋，可能會有所瞭解。
除了之前提到的機型、操作系統、分辨率、ip、網絡模式等基礎數據的收集，跟操作嚴格綁定的有頁面編號、內容id、用戶id、操作類型、控件id等相關數據，共34個屬性。
我們用一個excel表維護起所有的點位定義，進行屬性編碼化，維護起頁面編碼表、按鈕控件編碼表、操作類型編碼表等等。
最終在我們這裏展現的是一個近1000*34的上報維度表，後續所有的埋點以及點位測試，都是圍繞於這一張點位上報表進行。
這也是數據測與研發測初期產生的“矛盾點”，量太他孃的大了。
(3) 爲何不使用第三方數據分析平臺？
或許有人問了，爲何不使用第三方的數據分析平臺呢？諸如友盟+、神策、GrowingIO等之類的。
其實使用多了你就會知道了，第三方的數據分析平臺，能夠給你帶來的大部分都是一些常規性的分析，諸如流失、留存、渠道、用戶成分等等。
想要做到更定製化，甚至對數據應用的更深、挖掘的更深，相對來說比較難的。
並且，對於部分對於數據保密性要求較高的公司來說，企業的數據上報的第三方的數據分析公司的服，務中，總是存在風險的。
在大數據人才市場緊迫的前期，很多中小型企業對於第三方數據分析平臺的依賴會較大。
在大數據市場進一步發展之後，相信很大一部分企業都會建立起自己的數據團隊，用於公司的全面數據化。
所以，從這個角度來說，埋點相關的體系建設也是一件不可避免的事。
而之前炒的略火的無埋點技術，從個人瞭解的信息來說，可能應對常規的數據分析工作應該是足夠了。
但同樣，想對數據做更多的深層挖掘，必然無法繞開對數據的精細收集。
(4) 原子操作上報而不是關係鏈上報。
此外，對於埋點體系的建設，有一個很重要的注意點就是：我們上報的一定是原子操作。
不過本身就是一個矛盾點所在，舉個例子，如果我們需要對一個用戶的真實操作路徑分析，記錄路徑關係鏈，我們在做真實的路徑轉化時，就很方便，因爲關係鏈路都以及記錄下來了。
確實很多公司就是這麼幹的。
而如果記錄的是原子操作，想要匯聚成一個訪問鏈路，則需我們自己根據時間序列，把事件串起來，進行一步一步分析。
表面看起來，記錄關係鏈對我們分析是更友好的，因爲對於後期的關係跳轉挖掘是很方便的。
但是，想要維護起關係鏈就很麻煩了，特別是對於那種產品迭代速度很快的產品，邏輯關係是經常變化的。
那麼，你把邏輯關係一起上報，維護的成本就很大了。
而對於原子操作，我不care邏輯關係，我只需要操作了這個點位，我就上報這個點位的原子信息即可，有新增點位添加埋點即可，邏輯關係再怎麼變化都不影響。
3 與研發之間的“愛恨情仇”
對於很多初建數據團隊的公司來說，數據層面的很多事，很多人都無法理解，包括研發團隊。
比如...
(1) 你們給我們增加了很多“額外的”工作量！
埋點的點位上報事件，對於業務端來說，並不是直接可見的，所以，很多人會認爲這個事情是“額外的”工作量，又不是業務邏輯，有什麼卵用呢，還這麼多工作量。
特別是在前期，第一波埋點梳理的時候，數百個點位，將會花費客戶端以及H5前端人員巨多的時間，看到數據編碼表，直至眩暈！
在數據推行的前期，不止是研發團隊，就連業務端的人員，對於數據的意識也沒有想象中的瞭解。
所以，在開發團隊，特別是客戶端以及涉及到埋點的H5前端來說，花費這麼多的人力去做數據收集、埋點這個事情，就變得極其的不可理解，甚至是微有“抵觸”的。
(2) 數據團隊的“竇娥之冤”！
但對於數據團隊來說，自己也不是業務團隊呀，說白了這些數據收集過來，自己又不是最終受益者，數據的加工處理者而已，也是個苦力。
所以，老實講來，數據團隊也挺“冤”的。
打個簡單的比喻，一般的業務開發工作就如耕種一些產出能直接食用的作物，用戶採摘了就能直接食用。
而對於埋點，就如耕種的是麥子，採摘的人是麪粉加工人員，採摘了之後需要加工成麪粉甚至是做成麪包，麪食，用戶纔可以食用。
所以，對於對底端“耕地”的開發人員來說，能夠直接提供給用戶，種了次數比較多輕車熟路的，能夠量化成果的其他“作物”是比較喜歡的。
而離用戶距離較遠，用戶不能直接食用，且第一次種的“麥子”，就相對沒有這麼喜歡了。
(3) 到底該誰來測試數據埋點的完整性？
關於數據埋點，還有一個比較巨大的爭執點：誰來爲埋點數據的準確性以及完整性買單。
數據埋點一旦出現故障，整個數據化運營線就崩了，特別是在運營人員&各個決策者在形成以數據量化結果，以數據驅動決策的習慣之後。
但是，之前我們也說過了，點位的繁多，誰參與測試都會崩潰。各種“矛盾心理”，讓數據上報是否完全、是否準確這個事情變得更難辦。
研發團隊不想在埋點這個事情上，浪費過多的人力物力；測試團隊對於數據技能要求略高的埋點完整性測試，顯得略微乏力；而對於數據團隊來說，無法將更多的人力放在每次繁重而又略顯枯燥的測試工作中。
以上種種，造成了幾個團隊之間爲“埋點”的事情，“憂心忡忡”，“愛恨交加”！
相信很大一部分開始涉及數據化的公司，都會遇到這個矛盾點。
那麼，如何解決這個問題，其實說白了就是跨團隊合作的問題。
4 如何有效跨團隊的合作
(1) 合作事務的邊界之爭。
在跨團隊合作的事情上，一個需要注意的問題就是確定事務的邊界。
一旦協商了邊界，確定了好雙方的邊界，雙方按照約定好的邊界交互，並行進行開發即可。
沒必要跨界好心多做一些事情，因爲這會擾亂友方團隊的規劃；當然，更不能將自己要做的事情打折，這會由於己方耽擱整個項目的進度。
而雙方一旦確立邊界，嚴格按照邊界進行開展即可，當然，如果遇到問題也是可以協商的，但絕不是推諉。
-
數據團隊負責爲客戶端以及H5前端人員提供上報接口，制定接口規範，制定埋點體系規範，確定什麼地方該上報，該上報什麼數據。
他無需關注這些基礎信息怎麼獲取，接口怎麼調，數據怎麼封裝。
而客戶端以及前端團隊則需要根據埋點體系規劃需求文檔，在該上報的點位，按照文檔獲取到相關的信息，進行封裝，調用上報接口進行上報即可。
他無需關注這個數據上報上去之後怎麼存儲，怎麼清洗，怎麼處理，怎麼挖掘。
雙方的邊界就在於埋點上報接口，只要雙方確定這個問題無誤即可開展埋點上報的合作。
所以，就個人認爲來說，開發人員不應該把因爲頁面邏輯結構雜亂，不好埋點的問題拋給數據，這屬於內部技術能解決的問題，但可以協商暫緩或者說換其他方案，而不是單純的把問題拋出來。
每個人應該把邊界內的事情做好，而不是拋給友隊。
再來回想一下關於數據埋點完整性測試的問題。一旦出現故障，對於業務影響巨大，這是一個巨大的鍋，該誰來背？
測試團隊對於這種數據埋點完整性測試這種對於垂直技能要求性略高的活，不太想接，也無力接。
客戶端團隊&前端團隊倒是可以通過抓包，拿到他們調用接口封裝的數據，校驗準確性，但是他們也不想花費過多的時間在上面。
而數據團隊雖然說是數據的直接接受者，但並不想爲埋點端的失誤背過多的書，但又是故障的第一壓力承受者。
所以，幾方下來，很矛盾。
但最終問題是需要解決的，並且也解決了。
埋點完整性測試的工作由數據與研發一同擔保，研發需要爲埋點失誤買單，而數據則做測試達標的校驗人，如果出現問題，同樣是需要揹負責任，並且產品項目端也參與進來，將測試流程納入發佈流程中，預留足夠的時間去埋點以及測試。
多方來保證埋點的完整性，確保將風險降低到最低，這是一個合理的處理方式。
當然，爲了確保數據完整性測試更加的效率、準確，數據團隊開發了埋點測試服務，實時的根據操作動態反饋上報的數據，進行校驗，進一步提升了埋點這個事情的效率。
(2) 適當的站在對方角度上思考問題。
其次，在跨部門合作的項目中，能夠儘量站在的爲友隊角度思考問題，這是一個良性的狀態。
還是以此舉些栗子。
其實一開始埋點體系的規劃中，上報中一些跳轉的上報，是攜帶父子跳轉邏輯關係的，確實有不少埋點是這樣設計的，另一方面也是後續追蹤數據更方便。
其中一個客戶端開發童鞋反饋說，這種記錄邏輯關係上報，一旦業務邏輯關係變化，涉及到埋點上報都需要重寫，對於客戶端的童鞋來說，是一個巨大的工作量。
後續進行了詳細的思考之後，我決定改變體系上報的規劃，這也就有了上面的那個注意點，數據的原子上報，這樣客戶端的童鞋只需要維護單一的頁面上報即可，而不需要管下一個面跳轉到哪裏。
雖然，這樣做對加大數據端對數據的處理複雜度，但是我們不能單純的爲了自己方便，而增加其他友隊的工作量。
需要從實際的情況出發，進行問題的思考。
在後續的埋點項目中，數據測也會與業務端進行充分的溝通，確保一些不重要的點位進行移除，以降低客戶端以及前端童鞋的埋點工作量。
而客戶端與前端的童鞋在埋點工作上，也更盡責，更加配合，使得埋點的錯誤率大大的降低，埋點完整性測試的花費大大的降低。
所以，整個埋點的事情，從一開始的略微“爭鋒相對”，到後面雖然不能說是“相親相愛”，但最起碼算是有共識，算是“通力合作”，在一起爲做好一件事情而努力！
整個事情的推動，需要我們設身處地的去思考，想辦法的去最理性的解決問題，這纔是跨團隊合作的真諦！
(3) 關於跨團隊合作項目推動執行的思考。
在整個事件的過程中，對於跨團隊項目的推進這個事情上，有很深的感悟。
還是數據埋點的事，其實一開始之所以會走的這麼艱難，還有一個重要的原因就是，一開始沒有強需求方去推動，或者說沒有項目管理的角色去把控。
因爲數據化的建設，在前期整個公司都沒有意識到問題的重要性。
所以，整個數據化的建設，包括數據意識的養成，都是數據團隊在push的。
這也就造成了埋點這個項目，push方是數據團隊，但又不是真的業務需求方，也不是項目管理方(我們的產品端把控項目進度以及整體規劃)。
名不正言不順，掌控不了整體的排期，所以整件事情纔會不尷不尬。
所以，在業務團隊對數據化的好處認識到一定程度上，我們將業務需求的驅動權交給了業務方，讓業務方來決定哪些點位的優先級更高，這樣研發團隊更能體會到自己做的事情其實是很重要的，很多人care的，成就感與存在感。
其次，整個進程的把控交給項目規劃方，也就是產品端做，產品端在整體排期中預留足夠的時間去做數據埋點，而不是像之前那樣，遊離在項目把控之外。
這也是前期埋點質量得不到保證的一大原因，因爲沒有合理範圍內的時間去做這件事。
而數據團隊則作爲業務團隊與研發團隊的橋樑，將實際的數據業務需求轉換爲可執行的埋點方案，push到研發測，最後再把控上報的質量。
所以，整個事情是多個部門協力在做，各司其職，業務端驅動，產品全局規劃、數據進行需求轉換以及把控質量、研發進行底層埋點。
只要多思考，多想想，找出問題所在，多嘗試，問題總會解決的。
5 結語
基礎的數據收集的越詳細，後期對於數據應用的擴展就越方便。
因爲你有足夠多、足夠詳細的用戶真實行爲數據，能夠讓你更加充分、更加有依據的去解析用戶的行爲，進而爲用戶做更多有針對性的策略。
如何進行埋點體系的建設至關重要，每個細節的設計都是爲了後續更方便的點位維護，以及應用挖掘方向的擴展。
期間，你也必然會遇到很多與其他團隊協作方面的事，所以，也希望團隊協作的一些想法能夠給你帶來些許幫助。
更多的相互理解、更理性的問題思考、更合理的分工搭配，都是跨團隊項目合作更高效的前提。
