简介
功能名称：分析模型支持切换分析时区
简称：切换时区分析
本功能为高级功能
本功能为高级功能，默认不开启，请联系客户成功开启功能。
物理时间、显示时间
在使用本功能之前，需要首先理解物理时间、显示时间与时区这三个概念。
- 物理时间：在经典的牛顿力学的范畴下，时间是一个绝对的标尺和概念，一个人无论在地球的何处，大家本质上在都是一个绝对的物理时间轴之上的，不存在有的人的时间线和其他人不一样这样的可能性，所谓的「天涯共此时」，也便是相同含义。常见的物理时间标准就有 unix 时间戳，其含义是从 1970 年 1 月 1 日（UTC/GMT 的午夜）开始所经过的秒数，不考虑闰秒。
- 显示时间：由于地球是一个球，不同地区的人们过着日升而出，日落而归的生活，为了方便各自地区的人自己生活，划分了时区这个概念。大部分地球人使用的显示时间尽管是同一个标准（公元纪年和 24小时），但是处在不同时区的人，在同一个物理时间看到的显示时间是不一样的。我们生活中常见的「北京时间」和「纽约时间」接近 12 小时（考虑到夏令时，不一定是 12 小时）的时间差，其实就是描述这个现象的。这也意味着，虽然显示时间是一个统一的标准，但是显示时间必须依赖于时区这个信息才能转化成物理时间。
结论：物理时间更像是一个火星人看地球的时候的视角，平时生活在地球上的人，感知的更多的是显示时间，但是如果涉及到跨国业务，就会遇到时区转化问题。
客户端（显示）时间、服务端（显示）时间
在开启切换时区分析的功能后，显示的时间也会出现两种概念。
由于物理时间这个标准本身是地球人类看不懂的，所以尽管神策分析在存储的时候，是按照物理时间进行存储，在界面展示时间的时候，还是会把物理时间转换成显示时间。
但是物理时间转化成显示时间的时候，是需要依赖于「时区」这个信息的，所以我们就会遇到一个问题，用什么时区作为转化的依据，下面就提供了两种思路。
- 客户端（显示）时间：以用户当时客户端的时区作为依据，将物理时间转化成显示时间
- 服务端（显示）时间：以服务端人工配置一个固定的时区为依据，将物理时间转化成显示时间
两者都是通过时区和物理时间转化成显示时间，区别在哪呢？
| 类别 | 描述 | 举例 | 典型场景 |
|---|---|---|---|
| 按照客户端时间显示 | 以用户当时客户端的时区作为依据，将物理时间转化成显示时间 不同的用户上报的时区有可能是不一致的 | 用户 A 在美国纽约时间的 1 月 1 日中午 12 点做了事件 A 用户 B 在北京时间的 1 月 1 日中午 12 点做了事件 A 尽管这两个事件发生的实质上的物理时间是不一致的 但是分析模型在展示的时候会把两个事件视作为同时发生 | 一个应用的用户分在在全球各地，需要查看用户在一天当中的活跃时段，并且是根据客户所在的时区来查看。 |
| 按照服务端时间显示 | 以服务端人工配置一个固定的时区为依据，将物理时间转化成显示时间 不论客户上报的时区是什么样的，都以服务端配置的固定的时区为准 | 用户 A 在美国纽约时间的 1 月 1 日中午 12 点做了事件 A 用户 B 在北京时间的 1 月 1 日中午 12 点做了事件 A 这两个事件发生的实质上的物理时间是不一致的 假定服务端配置的固定时区为北京时间 分析模型在展示的时候会展示用户 B 的事件先发生，用户 A 的事件后发生，并且在展示的时候会把用户 A 的事件的发生时间转化成北京时间来显示。 | 一个股票交易系统，尽管用户可能遍布全球，但是因为开市的时间是根据交易所所在的时区决定的，所以需要按照交易所所在的时区来查看分析。 |
神策分析支持在如下分析模型按照上面两种时间模式进行展示：
- 事件分析
- 漏斗分析
- 留存分析
- 分布分析
- 用户路径
- 间隔分析
- 归因分析
功能介绍
请确保你已经升级到对应的 SDK 版本
- Android：v4.1.0+
- iOS：v2.0.9+
- Web：v1.15.9+
- 微信小程序：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 的事件后发生，并且在展示的时候会把用户 B 的事件的发生时间转化成北京时间来显示。 | 一个股票交易系统，尽管用户可能遍布全球，但是因为开市的时间是根据交易所所在的时区决定的，所以需要按照交易所所在的时区来查看分析。 |
支持保存为概览
在切换时区的情况下，我们也支持保存分析结果为概览。
切换时区分析的局限性
运算速度较慢
无论是使用客户端时区进行查看、还是根据服务端时区进行查看，只要不是使用的默认时区，分析运算速度都会变慢。
可能会导致计算不准确的情况
在使用 「客户端时区」 的时候，查询条件中涉及到日期类型的用户属性时，计算结果会不准确。因为这些带有日期信息的用户属性只保存了属性上报时的物理时间，而没有存储这个属性上报时用户所在的时区，所以在参与运算的时候，这些用户属性的日期会转换成服务器所在时区的显示时间然后参与运算。