SKAdNetwork FAQ

Yes, users opting into app tracking via ATT will be tracked via SKAdNetwork in parallel.

This means that you will always get aggregate data via SKAdNetwork, and additionally receive device-level data via tracking links for the same user if they opt in. Unfortunately, due to Apple's intentional SKAdNetwork design limitations, there is no way to deduplicate these two data sources. This is why we expect SKAdNetwork will quickly become the standard option for transactional purposes like billing, with the limited amount of device-level data still being useful for deeper insights and campaign optimization.

Currently, SKAdNetwork only supports App Installs. This means nothing will happen and no SKAdNetwork postback will be sent if the app is already installed.

The first call to registerAppForAdNetworkAttribution() generates the notification if the device has attribution data for that app, and starts a 24-hour timer. Subsequent calls to this method have no effect, and there is no need to worry about duplicates.

However, it's critical to ensure only one source is managing updateConversionValue(_:) calls. If you have more than one party making these updates, your data will quickly become messy because each party will likely define the meaning of a given conversion value differently.

The Branch SDK sets a default "expiration" on conversion-value updates to avoid this issue. This means that after a set number of hours, we will stop calling updateConversonValue() even if the user continues to perform qualifying events. This is in order to prevent the scenario where the timer keeps looping, preventing a postback for conversion being sent.

For SDK versions v.0.35.0 → v1.38.0, this expiration is 72 hours. Beginning with SDK v1.39.0, the default timer is set to 24 hours, based on guidance from major networks including Google, Facebook, and Snap.

If you want to customize the default, see this FAQ item: How do I change the Branch SDK's default conversion-value update window?

Unfortunately, there is no geographical data available through SKAdNetwork. This is by Apple's design.

If understanding the location of your downloads is important to you, we recommend that you run geo-targeted campaigns with your ad networks and utilize the campaign IDs to help identify which regions your installs are coming from.

The conversion-value parameter is not required. This value is updated via the updateConversionValue(_:) method (if you are using Branch's built-in SKAdNetwork functionality, our SDK calls this method automatically on your behalf), and if this method is not called, the conversion-value value in the SKAdNetwork postback will simply not be set.

Note that the conversion-value parameter will only be provided in the SKAdNetwork postback if it passes Apple's secret privacy thresholds.

SKAdNetwork does not provide attribution for owned and organic installs. The SKAdNetwork attribution method is specifically for app install campaigns.

The SKAdNetwork campaign-id parameter is specified when the ad is shown inside a publisher app. This parameter is limited to a total of 100 values (the integers 1-100), the meaning of which is typically defined by the advertiser and ad network in collaboration.

This means that each advertiser is limited to a total of 100 values per ad network.

transaction-id: A unique ID for the install/ conversion to help with deduplication and validation.

attribution-signtature: Apple’s own attribution signature in the postback, to be used for cryptographic verification of the postback.

For more information on the parameters in the SKAdNetwork postback, see this Apple documentation page.

Apple will only ever send one SKAdNetwork postback per install.

If an install is the furthest a customer goes through the conversion funnel within Apple's conversion timer windows, then you as the advertiser will received an install postback. If a customer also purchases within Apple's conversion timer windows and you decide to register this as a conversion event with a conversion value, the postback you receive will have the appropriate conversion value attached, and this can also be counted as an install.

Once a postback has been sent by Apple, no additional postbacks will be sent for post install conversions. Therefore, if a conversion does not happen within Apple's windows then you may never see a postback with that conversion information to be attributed to the campaign.

SKAdNetwork data is completely separate from any device-level attribution data collected via tracking links. With the expected low rate of ATT opt-in, SKAdNetwork will be the only reliable data source for billing, etc.

However, there are still advantages tracking links, including device-level attribution data (for opted-in users) and deferred deep linking (regardless of user opt-in status), and many ad networks are supporting both attribution methods in parallel.

This means that you will always get aggregate data via SKAdNetwork, and additionally receive device-level data via tracking links for the same user if they opt in. Unfortunately, due to Apple's intentional SKAdNetwork design limitations, there is no way to deduplicate these two data sources. This is why we expect SKAdNetwork will quickly become the standard option for transactional purposes like billing, with the limited amount of device-level data still being useful for deeper insights and campaign optimization.

Apple has provided the following details about attribution windows on this page. Note that none of these can be customized.

SKAdNetwork supports limited view-through attribution beginning with v2.2 in iOS 14.5.

For more information, please read this blog post.

We have published a blog post with SKAdNetwork conversion-value best practices here.

No, you should not attempt to call updateConversionValue(_:) with a conversion value of 0.

While this is not clear from Apple's current documentation, we have confirmed with multiple sources that the 0 value is actually reserved by SKAN for install events.

To do this, you will need to use the 100 campaign-id values SKAdNetwork provides.

The future of ad fraud on iOS is unclear at this point, since SKAdNetwork adoption is still very low. Here are some early hints on what we expect:

• SKAdNetwork will make 'stupid fraud' (things like basic click spamming) go down significantly, because Apple will be vouching that every conversion happened on a legitimate device.

• More sophisticated techniques (device farms, etc.) will likely still be possible with SKAdNetwork. Unfortunately, due to how opaque the system is, we expect these techniques will be far more difficult to catch.

We're constantly monitoring the situation, and will be working on initiatives to detect and prevent fraud as we start to see real campaign data come in through the SKAdNetwork system.

The SKAdNetwork postback is sent by iOS in the background, which means the app does not need to be active for the postback to be sent.

Yes, the app must be active for updateConversionValue(_:) to fire. This means if the user doesn't open the app for over 24 hours, the SKAdNetwork looping timer will expire and the postback will be sent, even if the user opens the app at hour 26 and performs an event that would otherwise trigger a conversion value update.

Apple has not shared details about how they do this process. It's possible they are using some sort of validation based on unique device ID (accessible only to Apple) or valid iCloud account.

SKAN involves two different timers:

• Conversion window timer. This timer starts at 24 hours when the app is launched for the first time. It resets back to 24 hours each time the conversion value is successfully updated. Once this timer expires, all data in the postback is final and cannot be updated.

• Randomization delay. This begins when the conversion window timer expires. Its length is up to 24 hours, arbitrarily chosen by iOS. At the end of this delay, the device sends the postback.

(Note: these terms are not official from Apple's documentation, but we find them useful to avoid confusion)

This means the earliest an ad network can possibly receive the SKAN postback is slightly over 24 hours after install, and that assumes no conversion-value updates are made. Many large networks are currently recommending that conversion value updates be limited to the first 24 hours after install.

There are two main ways ad networks are sharing SKAdNetwork data with MMPs:

• Forwarding the raw SKAN Postbacks. This is the most common flow, and involves the network resending the individual conversion reports that iOS devices send to them. When ad networks forward these postbacks directly, MMPs are able to process and cryptographically validate the individual reports (as recommended by Apple), filling their traditional role of independently verifying data and ensuring trust by all parties.

• Providing pre-aggregated data via an API. This approach is being used mostly by the largest walled garden networks (often referred to as SANs, or Self Attributing Networks). In this flow, the network collects individual SKAN postbacks, cryptographically validates them internally, and then provides only pre-generated results to MMPs via an API endpoint. This means that MMPs won't be able to 'check the homework' of networks using option 2. In addition, not every network sharing data via API is providing all the data dimensions reflected in the SKAdNetwork postbacks.

To see which method is being used by a given network, please refer to this list.

Note: While individual SKAdNetwork postbacks are not technically 'aggregate data' (because each one corresponds to a single install — for more about the difference, please see What's the difference between device-level and aggregate data?), the design of the SKAN system ensures that the data inside each postback is already at an aggregate level of detail.

SKAdNetwork will send a single postback that includes both the app install and conversion-value (the conversion-value will only be included if it passes Apple's secret privacy threshold). This postback will be sent at least 24 hours after the app install is registered by the advertised app.

This depends on how you have integrated SKAdNetwork.

• If you are using Branch to manage your conversion value mappings, you do not need to release a new version of your app.

• If you are managing your conversion values via custom in-app code, it will likely be necessary to release a new app version.

On this page, Apple mentions a limit of 15 view-through impressions per source app.

This means for a given source (publisher) app, iOS will only store 15 SKAdNetwork impressions at a time. That could mean 15 impressions for the same advertised app, or one each for 15 different advertised apps.

SKAdNetwork view-through impressions “expire” after 24 hours if they don’t lead to an install. But, the oldest one will expire before the 24 hours if the source app serves the user a 16th impression. This could present a problem for a high-density ad implementation (i.e., if a game shows view-through ads for 16 different apps over the course of a 1-hour play session, the first touch point will be discarded).

It's not clear why Apple chose this limit, other than perhaps for technical simplicity.

Access to Ads and SKAdNetwork reporting/configuration is available to customers of Branch's Performance product.