項目背景
來到我司的時候，雖然是一家在線教育行業，但基本沒有互聯網的基因，剛剛開始做數據埋點的工作。而且只是聚焦在上課教室內的核心指標埋點。當時對埋點這件事，有了一個基礎的技術框架，也有了一個比較簡陋的流程。但存在以下問題：
1需求環節：寫prd的時候也比較繁瑣，一個事件有時候上報字段多大20個。內容多了很容易出錯。經常會範的錯誤：漏埋點，埋點關鍵字錯誤，上報字段值不明確等；
2.開發環節：僅定義了數據上報的API接口格式，但各端SDK規範沒有統一（比如上報操作系統是;有些端上報IOS，有些上報ios；有些端開發者打錯上報關鍵字，如device打錯成devcie，上報值使用全角輸入法，時間戳未按照規範上報成毫秒。）；
3.測試環節：測試環節比較耗時耗力，除了要測試觸發場景是否有投遞數據，也需要檢查數據質量，數據是否符合要求；而數據質量測試未得到重視，很多錯誤在測試環節都沒有測試出來（比如有些字段數據爲空）。
解決方案
爲了優化埋點工作，圍繞着前面提到的痛點，我們了一套解決方案-三駕馬車：1埋點模型（SDK）；2埋點管理平臺；3埋點流程。一切都是爲了減低埋點的門檻，提高埋點的效率
解決方案三駕馬車
1.埋點模型
埋點模型採用Protobuf數據格式上報，並封裝成統一埋點SDK，一方面：定義枚舉值，解決上報值和關鍵字不規範的問題。另一方面：上報的信息進行歸類，簡潔明瞭。 我們定義了三種數據結構。
接口調用場景
具體每個類的數據結構如下：
message BaseInfo {
//系統上報時間戳-毫秒(由銀河服務端生成)
int64 sysTime = 1;
//客戶端上報時間戳-毫秒
int64 time = 2;
//會話Id，一段會話的唯一標識（客戶端每次啓動APP到下一次啓動APP之間生成一個會話id）
//生成規則：16位隨機數+13位時間戳+3位(端表示pc:001 android:002 ios:003 web:004 server:005)
string sessionId = 3;
//設備唯一標識
string uuid = 4;
//公司標識
Company company = 5;
//sdk版本
SDKVersion sdkVersion = 6;
//用戶ID
string userId = 7;
//用戶類型
UserType userType = 8;
//日誌類型
LogType type = 9;
string eventId = 10;//事件ID (產品經理提供)
NetType netType = 11;//網絡類型
OperatorType operatorType = 12;//網絡運營商類型
int32 requestCnt = 13;//接口請求次數，默認爲1
string business = 14;//業務類型 (產品經理提供)
//來源:安卓、iOS、pc、web、server
Os os = 15;
string channel = 16; // 渠道來源(針對前端的落地頁url編碼，H5商城的來源渠道)
//APP版本號
string appVersion = 17;
//APP類型：yimi/bubugao/yuxuepai
string appType = 18;
//設備型號，標示手機品牌+型號
string deviceInfo = 19;
//設備操作系統版本號
string osVersion = 20;
AppAction appAction = 21;
//信息,崩潰信息
string info = 22;
int64 stayTime = 23; //頁面停留時間
}
教室內信息
message LiveInfo {
//課程id
string lessonId = 1;
//課程類型
LessonType lessonType = 2;
//服務器IP
string serverIp = 3;
//用戶ip
string userIp = 4;
}
其他信息
message ExtraInfo {
//額外字段key
string key = 1;
//額外字段value
string value = 2;
}
2.埋點管理平臺
管理工具的目的有
1).是爲了解決產品經理產出需求時容易犯的問題（漏埋點，埋點關鍵字錯誤，上報字段值不明確）；
2).作爲埋點元數據，用於管理已有埋點，同時後期基於埋點元數據的擴展應用包括埋點自動測試、事件分析模型。
3).同時作爲產品的PRD文檔，給到開發/測試使用。
圍繞這兩個目的，我們設計的埋點管理由兩個模塊構成：事件屬性管理+元事件管理。
A.事件屬性管理：建立前面的埋點模型的基礎上的。我們可以增/刪/改/查事件屬性，事件屬性的字段維度除了常規信息，關鍵還有一個埋點類型（base/live/extra）。事件屬性的新增由數據產品管理，這樣能對公司所有的埋點字段規範從源頭上有所控制（包括字段的數據類型，字段的取值範圍）
事件屬性錄入
事件屬性列表頁
B.元事件管理：實現事件的增/改/查。產品經理只需要對一個事件的屬性做勾選，包括（業務線，上報端，事件類型，事件名稱，任務編號），就可以自動生成必須要上報的預置字段屬性（基於【上報端】+【事件類型】匹配事件屬性）。而另外如果有其他要上報的字段，再單獨勾選。這樣非常快捷傻瓜，且基本不會出現操作失誤。
事件錄入頁面
元事件列表頁
3.埋點流程
最開始的數據埋點，基本就是數據產品經理作爲公司唯一個出口，設計併發起所有的數據埋點需求；這樣做的好處是有一個人統籌埋點的發起和應用。但是缺點非常明顯，業務線那麼多，一個人根本不可能管得過來。而且也只有業務產品經理，知道哪些要做埋點，怎麼埋點。所以新流程中埋點由業務產品經理自己發起，數據產品只是設計工具和做技術指導。
1：埋點由業務線產品經理髮起，在埋點管理平臺上完成埋點錄入；
2：爲了保證字段的規範統一，需要新增的字段統一由數據產品添加；
3：通過埋點事件的任務編號，產品，開發，測試串聯起來；
埋點流程
可優化點
後續埋點元數據基礎上急需擴展出一個埋點自動測試平臺，這樣才能進一步提到埋點質量；