所谓埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑。那么埋点方案又该如何设计呢？首先来定义一下通用的数据模型和格式, 便于在每个应用中可重复使用, 统一ETL处理。
数据模型和格式
用户行为数据格式
用户行为数据[Action]代表的是历史上已经发生过用户行为事件，一般来说不应该需要进行更新 [比如登录,注册,战斗,消费等等
数据上报Json格式
{
"type": "action", // type为action, 代表是event事件
"event": "$register",// 事件名字
"uid": "01cc9e2b80b5c37281b3c3f4974f8ef6", // 账号唯一ID
"uid_type": "guest", // 账号类型
"time": 1435290195610, // 上报的13位时间戳
"properties": { //事件属性
"device_no": "dsfhksdfsklljljdh",
"device_name": "oppo",
"device_type": "idfa",
"os": "ios", // 操作系统
}
}
设备行为数据格式
没有用户ID, 只有设备ID时的行为, 比如应用商店的点击,曝光,下载和启动游戏激活等事件
数据上报Json格式
{
"type": "device",// 必选, 事件为event[不可更改的日志],
"event": "$ad_view",// 必选, 广告事件名字
"device_no": "device_no10",// 设备唯一id
"device_type": "idfa",// 获取设备的类型
"device_name": "device_no1_name",// 设备名
"time": 13243423432,// 上报的时间戳
"properties": {// 投放渠道包信息填写
"os": "ios", // 操作系统
"media": "今日头条",// 广告媒体
"optimizer": "小小",// 广告优化师
"advertiser": "大大" // 广告商
}
}
用户属性数据格式
记录和收集用户画像，描述用户的长期属性（也即 Profile)，比如金币，等级等，可以增删改
{
"type": "profile_set", // type为profile_set, 代表是user实体设置
"uid": "01cc9e2b80b5c37281b3c3f4974f8ef6", // 唯一账号id
"uid_type": "guest", // 账号类型
"time": 1435290195610, // 上报的时间戳
"properties": { // 变化的用户属性
"level":33,
"vip": 3
}
}
数据上报服务设计
以上数据格式, 可以满足不同应用的埋点, 那么数据采集有几种方式可以选择, 一种是采集Log日志，另一种是设计数据接收服务。
采集Log日志的方式, 需要过滤掉很多无效日志, 同时每台服务器需要部署采集器，而接收服务可以集中处理所有有效数据, 统一打印日志, 采集到Kafka, 以下对该服务的设计做一个简单分析。
- 可以接收批量数据, 减少QPS
- 对IP进行统一解析并拆分为地区和网络信息
接口协议
请求方式
- https://xxxxxx/data_api/events_report
- Method: POST
- Content-Type: application/json
请求参数:
| 字段 | 数据类型 | 是否必选 | 备注 |
|---|---|---|---|
| apiKey | string | 是 | 接口验证key, 生成算法:md5(EventReport_$appId_secret) |
| appId | int | 是 | 应用唯一id, 由数据中心提供 |
| timezone | string | 是 | 时区，示例：Asia/Shanghai（不要使用 utc+8 方式） |
| dataList | []map[string]interface{} | 是 | 上报数据格式 []map[string]interface{} , 具体下文见数据模型和格式 |
| compression | string | 否 | 压缩算法, 默认是none代表不压缩 |
返回参数
http.StatusCode != 200, 说明参数解析有问题
| 参数名 | 类型 | 说明 |
|---|---|---|
| code | int32 | 0为正常, 1000为异常，1001 为用户请求参数错误 |
| message | string | 显示正常或异常信息 |
| data.fail_index | int32 | 显示上报失败的数据条数index |
接口案例
{
"apiKey": "6a35d36770b4b2e34d2d0af6cf7daeec",
"appId": 2,
"timezone": "Asia/Shanghai",
"dataList": [
{
"type": "action", //代表是类型, 从上面三种数据格式中确认
"event": "$register", // 事件名字
"uid": "01cc9e2b80b5c37281b3c3f4974f8ef6",// 唯一账号id
"uid_type": "guest", // 账号类型
"time": 1435290195610,// 上报的时间戳, 13位毫秒级
"properties": {
"device_no": "dfjsdfgjsfs",
"device_name": "oppo",
"device_type": "idfa"
}
},
{
"type": "action", //代表是类型, 从上面三种数据格式中确认
"event": "$login", // 事件名字
"uid": "01cc9e2b80b5c37281b3c3f4974f8ef6",// 唯一账号id
"uid_type": "guest", // 账号类型
"time": 1435290195610,// 上报的时间戳, 13位毫秒级
"properties": {
}
}
],
"compression": "none"
}
技术方案
1.apiKey在创建游戏的时候生成, 可更改, 缓存到Redis。
2.批量处理数据, 解析IP, 打印日志
数据上报SDK
- 将数据模型进行封装, 封装具体接口调用过程, 用户无需关心具体实现
- 数据上报封装成批量, 定时, 异步的方式, 提供传输性能
- 错误处理只限于内部代码, 无需抛给调用者, 打印错误日志即可。
架构设计
开源代码
Go SDK: https://gitee.com/carollia/data-sdk-go
Java SDK: https://gitee.com/carollia/data-sdk-java
Lua SDK: https://gitee.com/carollia/data-sdk-lua
系列文章
第一篇: Ambari自动化部署
第二篇: 数据埋点设计和SDK源码
第三篇: 数据采集和验证方案
第四篇: ETL实时方案: Kafka->Flink->Hive
第五篇: ETL用户数据处理: kafka->spark->kudu
第六篇: Presto分析模型SQL和UDF函数
