简介
功能名称：分析模型支持切换分析时区
简称：切换时区分析
本功能为高级功能
本功能为高级功能，默认不开启，请联系客户成功开启功能。
物理时间、显示时间
在使用本功能之前，需要首先理解物理时间、显示时间与时区这三个概念。
- 物理时间：在经典的牛顿力学的范畴下，时间是一个绝对的标尺和概念，一个人无论在地球的何处，大家本质上在都是一个绝对的物理时间轴之上的，不存在有的人的时间线和其他人不一样这样的可能性，所谓的「天涯共此时」，也便是相同含义。常见的物理时间标准就有 unix 时间戳，其含义是从 1970 年 1 月 1 日（UTC/GMT 的午夜）开始所经过的秒数，不考虑闰秒。
- 显示时间：由于地球是一个球，不同地区的人们过着日升而出，日落而归的生活，为了方便各自地区的人自己生活，划分了时区这个概念。大部分地球人使用的显示时间尽管是同一个标准（公元纪年和 24小时），但是处在不同时区的人，在同一个物理时间看到的显示时间是不一样的。
上图中UTC+10时区最早进入5月27日，UTC-3最晚进入5月27日。图中的竖线，用Unix时间戳表示绝对时间，大家可以看到，相同时刻，不同时区的时间是不一样的。
客户端（显示）时间、服务端（显示）时间
所以尽管神策分析在存储的时候，是按照物理时间进行存储，在界面展示时间的时候，还是会把物理时间转换成显示时间。
我们在分析时，可以指定一个具体的时区。比如分析师需要5月27日的订单数量这个指标，那么可以
- 按照UTC-05:00这个时区口径来分析
- 按照“客户端时区“来分析
| 类别 | 描述 | 举例 | 典型场景 |
|---|---|---|---|
| 按“客户端时区” | 按照事件发生的时区来聚合分析 | UTC+8（北京地区）的11月11日的订单数量，加上UTC-5（美国区）的11月11日的订单数量 | 看双11活动，各个地区当地的11月11日的订单数量 |
| 按照UTC-05:00 | 以固定的时区口径来聚合分析 | 按照UTC-5看某天的营收 | 公司财务口径按照某一时刻，过去某个时间段的营收 |
神策分析支持在如下分析模型按照上面两种时间模式进行展示：
- 事件分析
- 漏斗分析
- 留存分析
- 分布分析
- LTV分析
- Session分析
- 用户路径
- 间隔分析
- 归因分析
功能介绍
请确保你已经升级到对应的 SDK 版本
- Android：v4.1.0+
- iOS：v2.0.9+
- Web：v1.15.10+
- 微信小程序：v1.13.24+
- QQ 小程序：v0.6.0+
- 今日头条小程序：v0.6.0+
- 百度小程序：v0.8.0+
- 支付宝小程序：v1.0.13+
如果有服务端埋点事件，并且需要按照客户端时间显示
注意，如果满足如下两个条件，需要关注本步骤，否则可以直接跳过：
- 条件 1、在埋点中有服务端埋点的事件
- 条件 2、这些事件也需要按照客户端时间进行显示分析
如果确定你满足了上述条件，需要对服务端事件自行做一些改造，具体改造内容如下：
- 请在对应的服务端埋点事件中增加 $timezone_offset 这一属性
- 属性值规则如下：
- 采集的是时区偏移量，单位是分钟，数值类型，例如北京时区的 $timezone_offset 是 -480
请务必按照上述要求操作，否则可能会导致数据出错，分析结果异常。
【步骤 1】核心逻辑与配置方法
项目设置中配置分析中可用的时区选项：多时区设置
【步骤 2】在分析模型界面切换时区
在界面选择切换时区
什么场景下该使用哪个时区？
| 类别 | 描述 | 举例 | 典型场景 |
|---|---|---|---|
| 按照客户端时间显示 | 以用户当时客户端的时区作为依据，将物理时间转化成显示时间 不同的用户上报的时区有可能是不一致的 | 用户 A 在美国纽约时间的 1 月 1 日中午 12 点做了事件 A 用户 B 在北京时间的 1 月 1 日中午 12 点做了事件 A 尽管这两个事件发生的实质上的物理时间是不一致的 但是分析模型在展示的时候会把两个事件是作为同时发生 | 一个应用的用户分在在全球各地，需要查看用户在一天当中的活跃时段，并且是根据客户所在的时区来查看。 |
| 按照服务端时间显示 | 以服务端人工配置一个固定的时区为依据，将物理时间转化成显示时间 不论客户上报的时区是什么样的，都以服务端配置的固定的时区为准 | 用户 A 在美国纽约时间的 1 月 1 日中午 12 点做了事件 A 用户 B 在北京时间的 1 月 1 日中午 12 点做了事件 A 这两个事件发生的实质上的物理时间是不一致的 假定服务端配置的固定时区为北京时间 分析模型在展示的时候会展示用户 B 的事件先发生，用户 A 的事件后发生，并且在展示的时候会把用户 A 的事件的发生时间转化成北京时间来显示。 | 一个股票交易系统，尽管用户可能遍布全球，但是因为开市的时间是根据交易所所在的时区决定的，所以需要按照交易所所在的时区来查看分析。 |
支持保存为书签、概览跟业务模型
在切换时区的情况下，我们也支持保存分析结果为书签、概览跟业务模型。对应的时区口径会在概览、报表等可视化组件中展示。
切换时区分析的局限性
运算速度较慢
无论是使用客户端时区进行查看、还是根据服务端时区进行查看，只要不是使用的默认时区，分析运算速度都会变慢。
可能会导致计算不准确的情况
在使用 「客户端时区」 的时候，查询条件中涉及到日期类型的用户属性时，计算结果会不准确。因为这些带有日期信息的用户属性只保存了属性上报时的物理时间，而没有存储这个属性上报时用户所在的时区，所以在参与运算的时候，这些用户属性的日期会转换成服务器所在时区的显示时间然后参与运算。