数据格式

底层数据模型需要统一的数据格式，根据不同数据的应用场景，可选择合适的数据格式进行上报，具体描述信息如下。

数据类型有以下几种：

详细说明：

1. 支持上报 object 和 boolean （bool-是/否）数据类型的数据，但会被转化成 string 进行存储。

2. Profile 上报（用户属性上报） datetime说明：

   1. 支持常规的 "2020-07-07 01:22:33" 的形式，同时支持形如 “2020-07-07T13:46:08.342+08:00” 格式的支持，即 datetime 字符串自带时区的方式上报属性；

   2. 如果是形如 "2020-07-07 01:22:33" 的 datetime 上报，默认按应用级的时区；

   3. 如果您需要指定 timezone，需要上报 “2020-07-07T13:46:08.342+08:00” 格式的方式。

3. 一个属性的类型由首次导入的数据类型决定，产品界面应用管理-数据管理中，可查看现有环境中属性的数据类型。

• 不同属性数据类型，可计算的指标

• 不同属性数据类型，作为筛选条件可用的操作符

• 字符串类型可以选择“为空”和“不为空”用于匹配 null 或非 null。

• 日期类型属性有一个单独的筛选规则（如下表）：

说明
选择不同数据格式注意事项：

• 需要求和、平均值、按照区间范围筛选的必须要用int、float数值类型。

• 需要时间筛选条件的必须定义数据类型为datetime格式。

3.1 一般限制

• 单个应用的上报的事件数总量不限制；

• 单个应用支持元事件种类不超过1000个（不同应用之间互不影响，不含虚拟事件）；

• 单个事件的属性数量推荐300个以内，最多不超过500个（不同事件之间互不影响）；

• 用户属性的属性数量最多不超过 500个；

• 单个应用自定义事件公共属性数量不超过100个；

• 事件名建议不超过64个字符，最长不超过255个字符；

• 事件属性名和用户属性名称最长不超过64个字符；

• 属性值长度建议不超过255字符，特殊情况如url等最大支持1024字符；

• 事件属性名称禁止命名为user_unique_id、ssid、event_id；

• 属性名不允许和预置属性名称相同；预置属性文档可查看预置属性。

3.2 事件时间限制

使用客户端 SDK （iOS、Android）导入的数据，服务端默认只接收事件发生时间在接收时间向前 7 天内和向后24小时内数据。

3.3 命名限制

1. events表中，同一个属性名，不允许存在多个属性类型，只有一种属性类型。

2. users表中，同一个属性名，不允许存在多个属性类型，只有一种属性类型。

3. 同一个属性名，如果在events和users表中同时存在，在两表中数据类型可以相同，也可以不同。

3.4 属性长度和范围的限制

入库后可看到的数据格式分别如下：

• 私有化

{
    "time": 1606301031,
    "server_time": 1606249381,
    "local_time_ms": 1606301031000,
    "device_id": "6912716898461553676",
    "os": "ios",
    "params": {
        "package": "package",
        "app_version": "1.0.6",
        "device_model": "iphone 6s plus",
        "timezone": "8.0",
        "os_version": "10.3.2",
        "session_depth_range": "5",
        "session_id": "762891435873043",
        "network_carrier": "TELCEL",
        "language": "zh",
        "exit_page": "http://datarangers.com.cn/pages/index/3",
        "product_name": "default_to_b",
        "resolution": "375x667",
        "platform": "ios",
        "loc_country_id": "1814991",
        "app_channel": "线下扫码下载",
        "device_brand": "苹果",
        "browser": "chrome",
        "os_name": "ios",
        "loc_province_id": "1280239",
        "session_duration_range": "100-200",
        "client_ip": "118.213.201.135",
        "loc_city_id": "1279540",
        "browser_version": "68.0.3440",
        "network_type": "mobile",
        "duration": 117,
        "session_depth": 5,
        "screen_width": 375,
        "localtime_ms": 1606301031000,
        "screen_height": 667,
        "session_duration": 117,
        "is_login": 1
    }
}

• SaaS

{
        "user": {
            "ssid": "",                // SSID
            "user_unique_id": "",      // user_unique_id，存储于 string_profiles{'uuid'}
            "web_id": 0,               // 网页端的匿名ID，存储于 string_profiles{'web_id'}
            "device_id": 0,            // 移动端,小程序端的匿名ID
            "user_register_time": ""   // 用户首次事件触发时间
        },
        "params": {
            "language": "zh-CN",
            "region": "",
            "app_version": "unknown",
            "app_region": "",
            "app_channel": "",
            "app_language": "",
            "os_version": "10",
            "os_name": "10",
            "device_model": "Windows NT 10.0",
            "device_brand": "",
            "network_type": "",
            "network_carrier": ""
        },
        "items":{
            "sku": [{
                "id": "",
                "property_1": "",     // 当前item定义的属性1
                "property_1": "",     // 当前item定义的属性2
            }]
        },
        "event_name": "predefine_pageview",
        "app_id": "2174",             // string, rangers 中的应用id
        "app_name": "数据发现者",       // string, rangers 中的应用名
        "server_time": 1606783082,    // int(timestamp), 服务端收到事件的时间, 精确到 ms
        "time": 1606783080,           // int(timestamp), time = local_time_ms/1000，单位为秒。
        "event_date": 1606783080      // date, 基于 time 计算，但只精确到天
}

Q1： 各端数据类型传输不一致，系统如何处理？如何修改？

描述：例如IOS端先传入A属性的格式为数值类型，安卓端后传入A属性的格式为字符串类型，此时系统如何处理，结果会如何？
A2：一个属性的类型由首次导入的数据类型决定，如果后续传入不同数据类型的数据，系统会尝试做转换，如果转换成功，则入库。如果转换失败，则属性信息值为‘0’入库，相当于属性信息丢失，但事件正常上报。
具体转换成功信息如下表：

注意
需要在数据校验侧规避这一问题，如果发生，请错误端及时调整数据格式，否则会引发数据丢失。

Q2： 是否接受时间戳string的上报，会自动解析成datetime格式吗？

A3：时间戳不支持，只支持日期时间的格式。

Q3：datetime是否接受按天级别格式的数据，"yyyy-MM-dd"

A4：支持。（上报格式："yyyy-MM-dd"）

Q4： 埋点设计时，如何选择正确的数据类型？

Q5：为什么会一段的版本值？不是版本格式要求至少两段么？

默认情况下，系统在遇到被“.”切割为至少两段的数据时（例如 2.0），会自动判断其为版本类型。而对于已知的版本类型的字段，我们会将这个限制放开，允许没有“.”，例如：2 这样的值上报。因为在一些情况下，版本号只有一段。当然对于这种情况，你也可以选择将版本号作为 int 类型上报。