0x00 前言
了解產品
梳理舊需求
梳理舊埋點
熟悉埋點流程
0x01 了解產品
所謂磨刀不誤砍柴工，埋點設計是和產品密切相關的，對產品熟悉可以極大的加快埋點設計的進度。了解產品可以從以下方面入手
在感知的基礎上，將產品的提供的功能抽象出幾個實體，然後畫出這些實體是如何隨著使用者的操作進行流動的，西什麼樣的形式展現的，提供了哪些互動入口。
多個產品經理溝通下，詢問下產品目前的定位，近期的計畫，和未來的規劃，這些資訊可能暫時對你的幫助不大，但當你設計埋點的時候，這些資訊貴潛意識的影響你的設計方法，以更好的相容未來產品的改變。
0x02 梳理舊需求
埋點的很大一部分用途是為了做報表呈現當前產品的**狀態，比如整體的新增、活躍、留存、回流，以及各個功能模組的使用情況。通過對舊需求的梳理，你能明白產品關注哪些指標，是從哪些角度進行分解的，有哪些度量方式此外嘗試著將這些指標梳理成體系，比如哪些是技術指標，哪些是業務指標，哪些是故障指標等，對需求的梳理也是同樣的邏輯。
0x03 梳理舊埋點
0x04 熟悉埋點流程
要做好一件事，必須知道其具體流程，埋點雖然聽起來簡單，其實也是乙個系統性的工程，需要各方共同參與。以當前主流的前端**埋點為例，埋點牽涉到產品經理、資料產品經理、資料開發、業務開發、資料測試五個角色，在一些企業的設定中可能並沒有資料產品的角色，其角色就會有資料開發來兼任，此外很多的資料測試也是由業務測試來兼職的。但不管角色的多少還是兼職，埋點所遵循的流程改動並不大。埋點開發的通用流程如下圖所示：
角色職責
資料產品經理：負責進行埋點轉化，對埋點的完整性負責，其一般有兩個轉化參考點,一是策劃文件，根據相應的改動增加相應的**、點選等埋點事件，另乙個參考就是報表需求文件，通過完善已有的埋點(常見的有增加引數、增加引數值等)或者增加新的埋點來支撐報表需求。
資料開發：根據產品輸出的埋點轉化文件，進行埋點設計，具體體現為埋點引數名、引數值、上報時機等，對埋點的準確性負責。業務開發：根據資料開發輸出的埋點設計文件，根據響應的觸發時機，將事件相關的設計的附屬資訊按指定的格式進行上報，對埋點植入的正確性負責、對採集資料的完整性負責（漏掉一些上報時機是很常見的事）。資料測試：根據業務開發的上報，通過測試用例抓包的方式驗證資料的上報是否和埋點設計的一致，驗證一致後發起埋點驗收報告。
注意
0x05 總結
本文對埋點之前的準備工作和埋點開發的流程做了簡要的介紹，需要強調的是埋點是乙個系統工程，需要參與各方高效的協同，這也是提高埋點質量的前提。
《七天資料埋點之旅》指引篇
資料埋點是乙份上手容易精通難的典型例子，可以說人人都可以埋點，但是埋點質量差異巨大，而這份差異隨著時間推移會加速放大。埋點設計的複雜性不亞於系統設計，其應用的場景 牽涉的方面和背後的思考也是相對複雜的。資料埋點的質量是依賴於日誌採集為源的資料系統的根基，所以埋點是整個資料體系中很值得深耕的方面。目前...
七天用Go寫個docker（第二天）
linux cgroup提供了對一組程序及子程序的資源限制，控制和統計的能力，這些資源包括cpu，記憶體，儲存，網路等。通過cgroup，可以方便的吸納之某個程序的資源占用，並且可以實時監控程序和統計資訊。cgroup完成資源限制主要通過下面三個元件 說半天概念，估計大家也是雲裡霧裡，我直接在liu...
ESC七天訓練營 第二天
詳見部落格，一下略過.https www.劉竹.cn 290.html 使用lamp來搭建 ubnutu16.04 apache php7.1 linux apache httpd mysql php 在映象中選擇lamp環境 ubnutu16.04 apache php7.1 或者 更換系統盤la...