数据时效和适用时区

推荐用于

营销人员 开发商 代理商 广告平台

最近更新： 2024年03月27日 03:43

概要：数据时效是指从事件发生到数据呈现之间的时间间隔。

时区

数据时效及分应用的指定时区

数据时效

AppsFlyer平台使用的数据时效性分为多种不同类型，如每日更新或实时更新，用于展示并提供数据。每种数据都有其专用的数据时效性。

例如事件面板中的数据时效性如下：

指标KPI：实时更新
平均KPI：每天更新

时区

在AppsFlyer平台中，一天的开始时间为00:01，结束时间为24:00。默认时区为UTC（协调世界时）。您可以在应用配置中将默认时区改为您需要的特定时区。

日期和时区原理

UTC时间没有冬/夏令时之分，因此不会发生变化。

东/西半球

东半球：UTC以东的时区格式为UTC+ 。
西半球：UTC以西的时区格式为UTC -。

分应用的指定时区

您可以在后台的应用配置中为相关应用设置特定的时区。设置完毕后，AF按日期对数据分组时会使用指定时区的当地时间，而非UTC。

例如

北京：如果某应用的指定时区设置为北京时间（即UTC +8），则AF对该应用的数据分组时，以UTC时间16:01为一天的开始，到UTC时间第二天的16:00为这一天的结束。

洛杉矶：如果某应用的指定时区设置为洛杉矶时间（即UTC -8），则AF对该应用的数据分组时，以UTC时间08:01为一天的开始，到UTC时间第二天的08:00为这一天的结束。

时区设置准则

确保应用配置中的指定时区与您在其他归因平台（如Google和Meta ads）中使用的时区一致。
如果您有多个应用，建议对齐所有应用的时区设置。如需查看具体应用的时区设置，请从AF后台进入配置 > 应用配置。
AF的大部分报告和数据提取工具都支持分应用的指定时区，包括多应用报告（前提是所有相关应用的时区一致）。

每日更新的数据

部分报告和下拉列表每天更新一次，即数据时效为每日更新或每日处理。每日更新的数据处理原则如下：

将具体某天（如星期一）的数据收集到存储桶中。这一天的开始时间是应用配置中指定时区的00:01，结束时间是24:00。
当天午夜过后的两小时内接收到的数据仍会保存到当天的存储桶中。举例来说，周二凌晨02:00之前接收到的数据都会被保存到周一的存储桶中。
该存储桶于当地时间02:00关闭，不再纳入新的数据。
无论事件实际在何时发生，02:00之后接收到的数据都会被收集在下一个存储桶中。
无论您为相关应用配置了哪个特定时区，AF都会在数据存储桶关闭后的UTC时间凌晨两点开始处理每日更新的数据。为了便于理解，我们会说数据处理从UTC时间午夜开始。也就是说，AF会等到UTC时间午夜开始处理相关存储桶中的数据。

东半球和UTC时区：

从当天数据收集结束到AF开始处理数据最多可能需要等待11个小时，具体时长取决于指定时区的当地时间。比如：
- 北京时间（UTC+8）：一天结束后需等待8个小时，然后AF开始处理数据
- 柏林时间（UTC+1）：一天结束后需等待1个小时，然后AF开始处理数据
- UTC：一天结束后立即开始处理数据
相关数据会在处理流程启动后的8-20小时内呈现在报告中，具体用时取决于报告类型。比如北京的数据从当地时间16:00开始可用，而柏林的数据则从当地时间09:00开始可用。

西半球：

从当天数据收集结束到AF开始处理数据最多可能需要等待23个小时。比如：
- 洛杉矶时间（UTC -8）：一天结束后需等待16个小时，然后AF开始处理数据
- 纽约时间（UTC -5）：一天结束后需等待19个小时，然后AF开始处理数据
相关数据会在处理流程启动后的8-20小时内呈现在报告中，具体用时取决于报告类型。例如，洛杉矶的数据会从事件发生两天后的当地时间00:01起开始可用，而纽约的数据会从事件发生两天后的当地时间03:01起开始可用。
举例说明
- 对于洛杉矶时间（UTC -8）星期一发生的事件，AF会在UTC时间星期二的午夜开始进行每天一次的处理更新，即洛杉矶时间的星期二16:01。
- 8小时后，即洛杉矶时间的星期三00:01，数据处理完毕。在实际场景中，洛杉矶的广告主会在星期三早晨开始上班时看到星期一的数据。

数据时效类型

更新频次	数据呈现时间	说明
滚动更新（即实时）	事件发生后的15–60分钟内	AF会持续处理相关数据，这种处理方式区别于分批处理，比如每天处理一次的方式。滚动更新的数据会在事件发生后的15–60分钟内更新，具体如下：归因（激活、再归因、再互动）：15-30分钟应用内事件：30-60分钟
实时报告	请求报告后的数分钟内	数据在事件发生后的几分钟内更新。
每日更新	UTC时区：事件发生当天UTC时间午夜过后的8小时内东半球：事件发生当天UTC时间午夜过后的9-20小时内西半球：事件发生当天UTC时间午夜过后的21-32小时内	AF对相关数据每天处理一次。这类数据的呈现时间取决于广告主在应用配置中设定的时区。不支持应用配置中指定时区的数据会按UTC时间呈现数据可能按天呈现，也可能会使用其他的呈现频次，具体请见相关数据的说明文档。
EOD	按应用配置中的指定时区在每天结束时呈现	以日历日（calendar day）为准的当天的结束时间，也就是第二天的00:01。比如周一记录到的数据会从周二的00:01开始呈现，与应用配置中的指定时区无关。
一天更新多次（当日）	平均每4小时更新一次	相关数据每天收集6次，平均每4小时收集一次。对于未购买ROI360的客户，SRN的点击和展示数据每天收集3次。 Cost ETL数据每天发送4次，平均每6小时发送一次。
广告收入	取决于对接和报告类型	详见广告收入说明文档。
PBA每日更新	UTC时间当天结束后的11-12小时内	PBA面板和报告按UTC时间每天更新一次。每天处理一次的数据包括前一天接收到的事件。转化发生后的最初7天内，PBA可能会发现与该转化相关的其他事件，并对KPI和媒体渠道的归因结果进行回滚更正。 7天过后该回滚路径关闭，不再更新。真实数据确定后，会在原始数据报告的final_data字段中呈现。详细示例
SKAN	从AF接收回传到面板和报告中呈现数据的时间节点说明请见此文档	某一天接收到的回传会在UTC时间当天结束时处理，相关数据会在UTC时间次日的11:00呈现。举例来说，周一接收到的iOS回传数据会在周二早晨呈现在面板和报告中，同样也会在周二早晨向渠道发送回传。报告和面板中的激活日期根据回传送达时间计算，详情请见SKAN转化值操作台说明文档。
Data Locker每日更新	UTC时间当天结束后的8-10小时内	相关数据每天处理一次。呈现在事件发生当天的h=23文件夹中。比如周一的数据会在UTC时间周二的08:00–10:00出现在周一的h=23文件夹中。 SKAN数据的送达时间可能会更迟一些（详见上文所列的SKAN说明文档）

数据时效性和时区支持

相关数据	呈现方式	数据时效性（详见上一节的更新频次信息）	按应用指定时区显示数据
激活	KPI	滚动更新	✓
应用打开（sessions）、点击、展示、忠诚用户	KPI	归因链接：滚动更新 SRN：一天更新多次	✓
应用内事件收入	KPI	滚动更新	✓
广告收入	KPI	广告收入	✓
广告消耗（成本）	KPI	归因链接：滚动更新（最迟点击后2小时内更新） API：一天更新多次广告消耗数据上传：最迟上传后4小时内更新	✓
卸载	KPI	每天更新一次。AppsFlyer每24小时向相关应用发送静默推送消息。卸载时间是指AppsFlyer发送静默推送并发现该应用已卸载的时间，而非实际的卸载时间。	x
面板中的应用内事件	下拉列表	下拉列表中显示的应用内事件名称每天更新一次。这不会影响相关数据本身的时效性。例如 Push API、面板和受众共享中的应用内事件下拉列表。	✓
数据概览面板	页面	滚动更新	✓
Protect360面板	页面	每日更新	✓（1）
SKAN面板	页面	每日更新	x
活跃数据面板	页面	KPI：滚动更新平均值：应用配置中指定时区的午夜更新	✓ 例外情况：MAU数据按UTC时间更新
事件面板	页面	滚动更新	✓
(空白行）		(本行有意留空）
留存	页面	留存KPI分为日度和周度两种颗粒度，每种颗粒度的数据时效性有所不同。日度留存KPI：每天更新一次周度留存KPI：一周从星期一开始，到星期天结束。留存数据在UTC时间星期一的12:00计算。周度KPI不支持应用配置中的指定时区，这一因素可能会造成极细微的数据差异，可忽略不计。	日度：✓ 周度：x
组群	页面	滚动更新	✓（2）
自定义面板	页面	滚动更新	✓（3）
受众共享	页面	每24小时向渠道发送一次更新数据。用户分组每天更新一次，最多涵盖90天的设备数据	✓
SDK信息页	页面	每天更新一次	x
实时提醒	页面	常规KPI：使用应用配置中的指定时区在午夜时处理在当地时间的07:00发送。 Protect360提醒消息中的信息按UTC时间每天更新一次。	✓
导出数据	页面	滚动更新需要注意的例外情况：广告收入原始数据：每天更新一次 Protect360：汇总报告：每天更新一次已拦截的假量原始数据：滚动更新归因后识别的假量原始数据：每天更新一次自然应用内事件：事件发生后的数小时内更新	✓
Pull API	API	Pull API的数据时效性于导出数据一致	✓ 默认UTC
数据透视表	页面	每天更新一次	✓ 周度留存KPI：x
Master API	API	每天更新一次	✓（3）
Data Locker	API	详见Data Locker说明文档	x UTC
回传	API	滚动更新	不适用
Push API	API	滚动更新	✓ 分情况
服务器到服务器的应用内事件	API	滚动更新	不适用
备注：（1）AppsFlyer账户下的相关用户可访问的所有应用都必须在应用配置中使用相同的时区设置。如果时区设置不一致，就会自动还原到默认的UTC时区。（2）时区设置还原到UTC时，群组数据呈现一定的特点和局限性，详见此文档。（3）所有选定应用在应用配置中的指定时区必须一致，否则就会自动还原到默认的UTC时区。