项目背景
来到我司的时候，虽然是一家在线教育行业，但基本没有互联网的基因，刚刚开始做数据埋点的工作。而且只是聚焦在上课教室内的核心指标埋点。当时对埋点这件事，有了一个基础的技术框架，也有了一个比较简陋的流程。但存在以下问题：
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：通过埋点事件的任务编号，产品，开发，测试串联起来；
埋点流程
可优化点
后续埋点元数据基础上急需扩展出一个埋点自动测试平台，这样才能进一步提到埋点质量；
网友评论