At a glance: Cohort analytics in Data Locker contains aggregated data of all elements in the advertising hierarchy. Reports contain data of users attributing in the previous 365 days.This report is available to advertisers who have raw data or Cohort API, or both as part of their subscription. It means that a Data Locker subscription isn't required for this report.
Cohort analytics in Data Locker
In some cases, attribution raw data in AppsFlyer is restricted due to media source data sharing policies or your privacy-preserving policies. The restriction includes all attribution-related fields like campaign and adset. Cohort reports provide you with aggregated data that can be used as an alternative to raw data.
See attached example report below.
Enable Data Locker
The report is available to Data Locker, Cohort API, and raw data subscribers. To enable the report in Data Locker, complete one of the following procedures.
Do you currently get data via Data Locker? | Procedure |
---|---|
Yes |
|
No |
|
Related reading: Differences between Cohort flavors | Cohort dashboard | Cohort API
You can load the data into your BI systems and use them as part of your campaign performance and optimization processes.
Metrics available
The metrics available are revenue, unique users performing an event and the number of event occurrences. To calculate cost-related metrics like ROI, and ROAS you need both revenue and cost metrics. Revenue metrics are in Cohort, and cost metrics are provided by ROI360 Cost ETL.
Cohort analytics facts
Reports available |
The following reports are available for download. The reports types are described in more detail in Cohort dashboard.
|
Reporting period | Users converting during the previous 365 days. In other words, each day the reports include the user converting during the previous 365 days. |
Report structure | The structure of each report is the same. See report structure. |
Report delivery | See Enable Cohort reports in Data Locker. |
Data freshness |
|
Impact of partner retention policies |
Consider that some partners implement a data retention policy. In this case, events occurring after the end of the retention period are disregarded in the Cohort reports. Example: SRN A has a data retention policy of 180 days. User events until day 180 are attributed to SRN A. Events that occur after 180 days are disregarded. Note: The events display in the Overview dashboard as organic. |
Report structure
The report is comprised of dimensions and metrics.
The format of the fields is as follows:
- Dimensions: String. The maximum length of the string is dynamic and in most instances depends on how you populate the elements of the advertising hierarchy
- Metrics: Number. Note! The selected_currency field format is string.
Dimensions
Field name |
Description |
||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
app_id |
-- | ||||||||||
media_source |
-- | ||||||||||
conversion_type |
Possible values: install, re-engagement, re-attribution |
||||||||||
attributed_touch_type |
Possible values: click, impressions, pre-install, unknown, tv, null |
||||||||||
days_post_attribution |
|
||||||||||
event_date |
|
||||||||||
conversion_date |
|
||||||||||
event_name |
Identifies the event. Some event names have a specific meaning while others relate to in-app events set by the advertiser in the app.
|
||||||||||
campaign |
Campaign hierarchy Consider: Campaign name changes not supported. Consequently, multiple names can be associated with a given campaign ID. |
||||||||||
campaign_id |
Campaign hierarchy | ||||||||||
adset |
Campaign hierarchy | ||||||||||
adset_id |
Campaign hierarchy | ||||||||||
ad |
Campaign hierarchy | ||||||||||
ad_id |
Campaign hierarchy | ||||||||||
channel |
Campaign hierarchy. [Updated October 27, 2021] At present, Meta ads doesn't populate channel in data provided via the Google Install Referrer mechanism. |
||||||||||
site_id |
Campaign hierarchy | ||||||||||
is_primary_ attribution |
Use to identify and deduplicate retargeting data. | ||||||||||
geo |
The ISO country code derived from the user IP address. | ||||||||||
agency |
|
||||||||||
install_app_store |
Android apps only: The Android store from where the app was downloaded. Populated by advertisers implementing multi-store Android attribution. If blank, it means Google Play Store. |
||||||||||
keywords |
Word(s) used in the user's online search. As reported by the ad network |
||||||||||
keyword_id |
[Field available starting April 27, 2022] Keyword ID returned by the ad network. |
Metrics
Field name |
Description | Format |
---|---|---|
unique_users |
Number of unique users performing the event |
Number |
revenue_usd |
|
Number |
event_count |
Number of event occurrences |
Number |
selected_currency |
3-letter currency code (USD, EUR) set by you in the app settings. Format ISO-4217. This is the same currency used to display revenue in Cohort in the user interface. |
String |
revenue_selected_currency |
|
Number |
BI developer considerations
Scope of data in the report
The reports contain user attributions, installs, re-attributions, and re-engagements, and their related in-app events.
If you use the unified view in your data loading process, you must use logic to split the data between campaign types, which means, user attribution (installs) and retargeting (re-engagements). To do so, use the conversion_type and is_primary_attribution field. See Double attribution of retargeting events.
Field-level considerations
- Use post-attribution days to enable easy calculation of retention metrics.
- Calculating unique users using campaign name and campaign ID dimensions: If you can disregard campaign name granularity, you can sum unique count on campaign ID and the metrics are correct.
- You can aggregate the data using the campaign hierarchy fields.
- Revenue in USD is calculated using the exchange rate on the event day.
- Ad revenue events are included where available but can update with a lag of up to 3 days.
General considerations
The data of all apps is provided in a single file. Use the App ID field to segregate data per app or set Data Locker to segregate by app.
Calculating the number of unique users per cohort
To calculate the number of unique users per cohort by conversion type, for example, the number of users installing the app you must filter the data so that conversion_type=install
and event_name=af_conversion
. Sum the event_count column. You can add dimensions by including additional columns. To calculate the number of installs per day, group by conversion_date
.
This is illustrated by the SQL statement and Excel visual that follows.
SQL statement
SELECT app_id,
conversion_date,
media_source,
event_name,
conversion_type,
Sum(event_count) AS total
FROM 'REPLACE_TABLE_NAME'
WHERE app_id='REPLACE_APP_ID'
AND conversion_type='install'
AND event_name='af_conversion'
GROUP BY 1, 2, 3, 4, 5
Excel example
Additional information
Traits and limitations
Trait | |
---|---|
Cost data | Not available. Use Cost ETL. |
Campaign name changes | Not supported. |
Data freshness | Daily UTC. Reports are in the Data Locker date-time (dt) folder of the reporting day by 10:00 UTC of the next day. |
Ad revenue |
|
Currency | USD and app-specific currency are both avaialble per row |
Organic data | Available |
Days post-conversion (install, re-attribution, re-engagement) |
365 days.
|
Agency transparency |
|
App segregation | Supported |
SKAN data | Not included. Meaning, the data provided by iOS postbacks. |
Reinstalls | Not included. |