Project time zone
Multi-time zone management
For projects that span multiple time zones (for example, when users come from different time zones or the business operates overseas), AE can uniformly identify and record the time of reported events so that offset information isn't lost. During analysis, you can also specify a time zone to convert data reported worldwide to the time in that time zone for calculation.
For example, for a global project headquartered in San Francisco, to view data reported by users in both the Middle East and East Asia in San Francisco time, simply set the display time zone to the San Francisco time zone.
Configure the project time zone
Project Admins and above can manage the project time zone configuration in Settings.
(1) By default, the time zone configuration is turned off, which means data is calculated and displayed based on the original time of the reported data.
(2) After you turn on Time Zone Converter, you can start configuring the project time zone. Turning on multiple time zones may affect existing assets. For the specific impact, refer to the prompts in the interface.
(3) Set the time zone offset property
Select the property that records time zone information in the reported data as the Time Zone Offset Property. Use numeric data to record the number of hours by which the event time is offset from UTC. The value must be an integer in the range of -12~14.
Note that multi-time zone features don't work properly in projects without a time zone offset property. Complete the configuration as soon as possible after you turn on Time Zone Converter.
If you report data with a client SDK (Android SDK v2.2.0 / iOS SDK v2.2.0 / JS SDK v1.2.0 / Unity SDK v1.4.3 or later, or other client SDKs), AE automatically collects time zone information with #zone_offset by default. You can directly select Default time zone offset (the #zone_offset property) as the time zone offset property. If this property isn't reported, you need to manually select a numeric property as the time zone offset property.
If you have enabled Real Time applications, including features such as Real-time Alerts, the time zone offset property supports only event properties that Flink can parse. Using properties that Flink can't parse causes Real-time Alerts to malfunction. The impact is shown when you configure the property. Confirm it before you submit the configuration or change.
(4) Configure the user time zone property
Collecting the time zone where users are located helps you analyze user distribution and plan Engage pushes. After you configure the user time zone property, you can use the Push by user time zone feature in the Engage module. All user properties except custom properties are supported. Property values can be valid time zone values from -12 to 14, including non-integer time zone values. If the reported property isn't a valid time zone value or isn't numeric, you can upload a mapping code list to map reported values to time zone values. Once you confirm the use of a code list, property values not in the code list are treated as invalid values.
(5) Select the project display time zone
Select the target time zone to use in analysis. You can set your most frequently used time zone as the default time zone, which becomes the initial default time zone that project members use in analysis.
For example, if your headquarters is in San Francisco (UTC-08:00) and you standardize global data on that time zone, you can set UTC-08:00 as the project display time zone.
(6) How display time is calculated after time zone offset
Display time = Event time + (Display time zone - Event time zone)
Note:
Because time zones are used in the calculation of assets such as cohorts and tags, deleting or changing time zones causes these assets to be recalculated, which consumes a large amount of resources. Don't delete or change the time zone configuration casually.
Be careful when you turn off the multi-time zone switch after turning it on. Before you turn it off, make sure that the calculation logic of related dashboards, reports, cohorts, and tags still meets your expectations after time zones are turned off, so as to avoid data errors and wasted resources.
Best practices
Standardize overseas data with a common time zone
Standardize the global data generated by products released overseas on one fixed time zone. For example, offset all data to UTC±00:00 to avoid data crossing day boundaries because of time zones.
Handle non-calendar-day campaign data
Non-calendar-day campaigns are campaigns whose start and end times don't follow the local calendar day change, for example, a campaign that starts and ends at 3 AM local time. In analysis, you may need to use 3 AM as the date cutoff point. In this case, you can use the time zone editing feature to set a time zone that corresponds to the cutoff point and switch to it during analysis, which meets the retention or revisit analysis needs of such campaigns.
View data for overseas teams
If your organization includes overseas teams, use the time zone settings feature. Configure the time zones where these teams are located as optional time zones, and team members can switch to the corresponding time zone when viewing data, which better fits the habits of overseas teams. At the same time, set the default time zone to the common time zone that all teams use for communication and discussion. This preserves each team's habits while keeping collaboration efficient.