背景
产品经理想要实时查询一些指标数据,在新版本的APP上线之后,我们APP的一些质量指标,比如课堂连接掉线率,课堂内崩溃率,APP崩溃率等指标,以此来看APP升级之后上课的体验是否有所提升,上课质量是否有所提高,为下一步的APP升级做准备。
客户端埋点 1.0版本设计 流程按照需求打点,如果想知道某一指标如进入教室成功率,点击进入教室这一动作上报数据,进入教室结果上报数据,同时上报课程id,用户id等属性。
缺点埋点规范全靠Excel,产品经理编写Excel埋点文档,开发按照文档埋点,测试按照文档测试。出现如下几类问题,
产品经理埋点文档编写失误,漏埋点,埋点关键字错误,上报字段值不明确等;
埋点开发者打错上报关键字,如device打错成devcie,上报值使用全角输入法,时间戳未按照规范上报成毫秒。
测试人员,不重视测试环节,只是粗略看下埋点是否存在,并未进行埋点质量的测试。
大数据开发进行数据清洗落地时,遇到未按照json格式上报的脏数据,由于上报值不规范,很多数据增加了清洗的难度和不确定性。
优点整个流程跑起来了,有些计算指标具有参考意义。
2.0版本设计 规范埋点上报经过调研,我们2.0采用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; } 埋点元数据界面基于1.0的一些缺点,我们进行了改造,开发了一个埋点元数据录入的界面,产品经理只需要在上面录入想要的埋点,规范上报值。开发者和测试者都可以在这个界面查看埋点的信息。
埋点测试流程规范重新规划了埋点的测试流程,粗略流程如下