Data Locker中广告平台可用的SSOT报告

请按本节所述流程设置Data Locker。若您对Data Locker的设置做出了更改，新的设置会在3小时内生效。 

前期准备：

完成以下一个或多个云存储配置流程：

• AWS存储桶
• GCS存储桶
• 【Beta】Yandex存储桶
• BigQuery数据仓库

Data Locker的设置方式如下：

1. 登录到您的AppsFlyer合作伙伴面板。
2. 进入以下页面：
   • 广告主： 报告 > Data Locker。
     
   • 营销合作伙伴：点击 帐户菜单 > Data Locker。
3. 按照Data Locker设置说明中的第3-16步进行操作。

由代理指定（启用）的广告平台：代理无法授权，必须让广告主代其授权。

如需向广告平台开放SSOT数据，广告主需完成以下操作：

1. 在AppsFlyer后台左侧的菜单栏中，选择协作 > 对接渠道。 
2. 搜索并选择相关渠道。 
3. 点击设置对接。界面会跳转到对接设置页。
4. 确认启用该渠道开关已开启。如果该开关未打开，AppsFlyer就不会共享数据。
5. 进入授权选项卡。
6. 为广告平台开放以下权限：
   • 访问汇总转化数据。
   • 访问汇总应用内事件数据。
   • 访问汇总收入数据。
7. 点击保存权限。 
8. 通知广告平台您已为其开放相应权限。
9. 如果您有多个应用与该渠道对接，需为各个应用分别完成上述流程。 

AppsFlyer的数据模型可推算出基础SKAN数据无法提供的信息。

• null值：Apple为了保障用户隐私，会在SKAN中将实际值替换为“Null”值，再进行上报。为了填补数据缺口，SSOT会通过数据模型对这些null值进行推算。详情请见此文档。
• 激活后的监测窗口期更长：SKAN对用户激活后两天以外的行为无法提供粒度较细的数据，这方面的局限性会导致数据不准确。为了确保数据质量，我们会对激活后更长一段时间内产生的事件独立用户及收入进行建模推算。了解详情

国家/地区（Geo）数据：由于SKAN的数据颗粒度限制，国家/地区数据通常不可用。在这种情况下，我们会通过模型推算这些数据，帮助您进行有效的数据分析。了解详情

如果您需要对最近几个激活日期内产生的数据进行分析，这时较长期的激活后指标（如激活后7天）可能尚未达到完备状态。这种情况下，相关指标仍然可用，但其数据不完整。

请充分考虑下列事项：

• 每当有可用数据出现时，该报告就会立即呈现这些数据。
• 激活后两天内的指标会在5天后达到完备状态。
• 激活后七天内的指标会在7天后达到完备状态。在激活后的15天内，我们的模型会不断对这些数据进行精细化处理。

出现不完整数据的原因有以下几种：

• 数据成熟度：如果激活日期与当前日期之间的时间段短于您要分析的时间段，则相关数据仍在累计中，尚不完整。
• SKAN延时：SKAN在发送数据时会有随机的延时。比如激活后2天内的用户行为数据最多可能会在激活后的96小时（即4天）后方才送达。
• 模型推算数据的处理节奏：我们会对激活后2天以上的SKAN数据进行建模推算，并在激活日期的7天之后生成首个推算值。在激活后第2到7天这段时间内，AppsFlyer传统归因模式的数据已达到可用状态，但SKAN的模型推算数据尚不可用。

示例（假设激活日期为1月1日）：

• 1月2日：AppsFlyer尚未收到SKAN数据。激活后2天内的数据与激活后7天的数据相同，且两者都不完整，由AppsFlyer传统归因模式的数据组成。
• 1月3日：AppsFlyer接收到部分SKAN数据。激活后2天的数据不完整，但这时其中包含部分SKAN数据。激活后7天的数据尚不包含模型推算的SKAN数据（首个模型推算值将在激活日期起的7天后可用）。因此在激活后的2到7天内，激活后7天的指标值可能低于激活后2天的指标值。
• 1月6日：AppsFlyer己接收到激活后2天的完整SKAN数据，包括延时最长的回传。此时，激活后2天的指标已充分涵盖完整数据，但激活后7天的指标值尚不完整。
• 1月8日：激活后7天的SKAN模型推算数据已生成完成。我们的模型会持续细化该数据，一直到1月16日为止。 

• 主文件夹按报告类型整理归类。可能出现的文件夹名称为：“ssot_unified”、“ssot_retargeting”和“ssot_user_acquisition”。
• 这些文件夹下的子文件夹则按照激活日期整理归类。

报告版本

• 每个激活日期的文件夹中都包含多个版本的数据，每天一次写入Data Locker。
• 每个版本都反映该激活日期的最新累计数据。
• 报告中包含该激活日期的所有可用数据。比如在4月18日，各个激活日期文件夹中的最新版数据包含截至4月18日的所有可用数据。
• 提示：建议您总是处理最近期的那一版数据，以确保数据准确性。

每个激活日期文件夹下最多可容纳15个版本的报告。激活日期的15天后，所有指标都已充分覆盖完整数据，并已打磨完毕。详情请见此处说明。

SSOT报告的路径格式如下：

<bucket-name>/t=<ssot_unified OR ssot_retargeting OR ssot_user_acquisition>/install_date=<yyyy-mm-dd>/version=<unix timestamp>/<parquet file number>

广告主存储桶中的文件夹层次结构示例：

bucket
|
└── t=ssot_unified
    |
    ├── install_date=2024-05-05
    |   |
    |   └── version=1714890235
    |   |    |
    |   |    ├── part-00000-4762858-d62a-446e-b499-dd05f2d5434d-c000.csv.gz
    |   |    |
    |   |    ├── part-00001-4762858-d62a-446e-b499-dd05f2d5434d-c000.csv.gz
    |   |    │
    |   |    └── part-00002-4762858-d62a-446e-b499-dd05f2d5434d-c000.csv.gz
    |   |
    |   |
    |   └── version=1714890286
    |        |
    |        ├── part-00000-1d295376-d024-4321-8d34-1fbb37cbb58d-c000.csv.gz
    |        |
    |        ├── part-00001-1d295376-d024-4321-8d34-1fbb37cbb58d-c000.csv.gz
    |        │
    |        └── part-00002-1d295376-d024-4321-8d34-1fbb37cbb58d-c000.csv.gz
    |   |
    .   . 
    .   .

说明：

• t：报告主题（类型）。
• install_date：用户激活相关应用的日期。也就是说报告按用户激活应用的日期呈现激活后的用户行为数据，而不是按用户行为发生的日期来呈现数据。
• 报告版本：使用Unix时间戳来表示相关版本的创建时间。

您可以将统一、UA和再营销报告分别导入您的BI系统。如果您选择同时导入这三种报告，则需要自行筛选不同视图的数据：

• 统一报告：使用is_primary_attribution=true或null来筛选数据。
• 用户获取报告：使用conversion_type=Install来筛选数据。
• 再营销报告：使用conversion_type=re-engagement或re-attribution来筛选数据。
• 统一视图：如果您在数据入库的过程中使用统一视图，可以按投放类型来拆分数据：

• 使用conversion_type=install、re-engagement或re-attribution（在SKAN中为re-downloads）来筛选数据。
• 详情请见《再营销事件的双重归因》。

• 对于转化（激活、再互动等），该维度的值为0。
• 对于收入和应用内事件，相关数据会被分为两个预定义群组，目前仅限激活后“2”天和“7”天。

为了确保您能对应用内事件和收入进行准确分析，建议使用days_post_attribution维度来筛选数据。详见下文说明。

一种常见的错误查询方式是运用过于简单的逻辑将一系列维度的收入值进行加总。由于这种方式会重复统计部分收入（days_post_install=2的收入和days_post_install=7的收入之间有重叠），因此得出的数据不准确。这个例子同样也适用于特定应用内事件的独立用户数分析。

请务必注意以下几点：

• 最新版本：总是查询各激活日期下最近期的版本，以确保您在数据分析中使用的是最新最准确的数据。
• 收入计算：以美元为单位的收入指标是根据事件当天的汇率计算的。
• 归因分析：带有event_name=af_conversion的记录即表示对转化的归因（包括激活、再归因/SKAN中的re-downloads以及再互动）。归因到的转化数量呈现在独立用户指标下，这些字段的收入指标为空，days_post_attribution的值为0。
• 面板对比：对比面板中的激活数时，请使用重新下载（redownloads）和激活（install）这两种转化类型的总和，因为面板会将这两种类型的转化都计为激活（install）。
• 应用内事件分析：event_name不等于“af_conversion”的记录即表示应用内事件。完成该事件的独立用户数呈现在独立用户指标下，而这些事件带来的收入则呈现在收入指标下。
• 转化类型：您可以使用这个维度来区分拉新和再营销转化。请注意，SKAN数据还有另一层细分（区分激活与redownloads）。与SSOT面板中的数据进行对比时，需注意在面板中这类转化都计为激活。
• 广告收入事件：这类数据可用时会在相应的记录内呈现。
• 分应用取数：所有应用的数据都集中在一个文件中。您可以使用App ID字段来区分各应用的数据，或将Data Locker设置为按应用区分数据。

本节列举了一些通过Data Locker拉取数据并用于BI的常见使用场景，且每个示例都配以相关的SQL语句及Excel表格数据，作为更直观的说明。

SELECT install_date, SUM(unique_users) AS total_attributions
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND af_c_id = '4475903638579'  -- Change to your specific campaign
    AND app_id = 'YOUR_APP'
GROUP BY install_date;

SELECT install_date, conversion_type, SUM(unique_users) AS total_conversions
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND af_c_id = '4475903638579'  -- Change to your specific campaign
    AND conversion_type IN ('install', 're-download')  
-- The dashboard sums both under the install field
    AND app_id = 'YOUR_APP'
GROUP BY install_date, conversion_type;

SELECT install_date, conversion_type, geo, SUM(unique_users) AS total_conversions
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND conversion_type IN ('re-attribution', 're-engagement')  
-- Both types are relevant for re-targeting
    AND app_id = 'YOUR_APP'
GROUP BY install_date, conversion_type, geo;

SELECT install_date, attribution_method, media_source, SUM(unique_users) 
AS total_installs
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND conversion_type = 'install'
    AND app_id = 'YOUR_APP'
GROUP BY install_date, attribution_method, media_source;

SELECT install_date,
       af_adset,
       SUM(revenue_usd) AS total_revenue_day_7
FROM ssot_unified
WHERE media_source = 'facebook'
    AND days_post_attribution = 7  -- Choose a specific post-install period (cohort)
    AND app_id = 'YOUR_APP'
GROUP BY install_date, af_adset;

SELECT install_date,
       SUM(IF(days_post_attribution = 2, revenue_usd, 0)) AS total_revenue_day2,
       SUM(IF(days_post_attribution = 7, revenue_usd, 0)) AS total_revenue_day7
FROM ssot_unified
WHERE app_id = 'YOUR_APP'
GROUP BY install_date;

SELECT install_date, media_source, SUM(revenue_usd) AS total_purchase_revenue
FROM ssot_unified
WHERE event_name = 'af_purchase'  -- Change to your specific event
    AND days_post_attribution = 7  -- Choose a specific post-install period (cohort)
    AND app_id = 'YOUR_APP'
GROUP BY install_date, media_source;

SELECT install_date,
  SUM(IF(days_post_attribution = 2 AND 
event_name = 'af_complete_tutorial', unique_users, 0)) 
  / SUM(IF(event_name = 'af_conversion', unique_users, 0)) 
AS conversion_rate_day2_af_tutorial_conversion
FROM ssot_unified
WHERE conversion_type = 'install'  
-- Choose the conversion types for the sample group you want to measure
    AND app_id = 'YOUR_APP'
GROUP BY install_date;

SELECT install_date,
       af_c_id,
       SUM(IF(days_post_attribution = 2, revenue_usd, 0)) 
       / SUM(IF(event_name = 'af_conversion', unique_users, 0)) AS ARPU_day2,
       SUM(IF(days_post_attribution = 7, revenue_usd, 0)) 
       / SUM(IF(event_name = 'af_conversion', unique_users, 0)) AS ARPU_day7
FROM ssot_unified
WHERE conversion_type = 'install'  
       -- Choose the conversion types for the sample group you want to measure
    AND app_id = 'YOUR_APP'
GROUP BY install_date, af_c_id;

SELECT install_date, media_source, SUM(skan_duplicates)
FROM ssot_unified
WHERE app_id = 'YOUR_APP'
    AND event_name = 'af_conversion'
GROUP BY install_date, media_source;

SELECT install_date, media_source, SUM(skan_duplicates)
FROM ssot_unified
WHERE app_id = 'YOUR_APP'
GROUP BY install_date, media_source;