数据埋点设计和SDK源码

所谓埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑。那么埋点方案又该如何设计呢？首先来定义一下通用的数据模型和格式, 便于在每个应用中可重复使用, 统一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, 以下对该服务的设计做一个简单分析。

1. 可以接收批量数据, 减少QPS
2. 对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

1. 将数据模型进行封装, 封装具体接口调用过程, 用户无需关心具体实现
2. 数据上报封装成批量, 定时, 异步的方式, 提供传输性能
3. 错误处理只限于内部代码, 无需抛给调用者, 打印错误日志即可。

架构设计

开源代码

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