Introduction: SKAdNetwork and SKAN
Singular’s iOS SDK simplifies SKAdNetwork integration, supporting SKAN 4.0 features like multiple postbacks, hierarchical source IDs, and coarse-grained conversion values. Based on Singular’s open-source SKAN standard, it ensures easy setup and compatibility with ad networks. For setup details, see Singular’s SKAdNetwork Guide.
Supporting SKAdNetwork Tracking
Tip: SKAdNetwork tracking is enabled by default when using the Singular SDK.
To disable or turn off the support for SKAdNetwork:
- Set the skAdNetworkEnabled configuration method to FALSE when building the SingularConfig object.
Handling AppTrackingTransparency (ATT)
For iOS 14.5+ (including iOS 18), use ATTrackingManager to request user consent before accessing the IDFA for tracking. Singular’s iOS SDK (v12.x) supports ATT, allowing initialization before consent and delaying events until consent is granted or a timeout occurs. This ensures compliance with Apple’s privacy rules and compatibility with SKAdNetwork (SKAN) 4.0.
Implementation
-
Add ATT Framework:
- Include AppTrackingTransparency in your Xcode project.
- Update Info.plist with NSUserTrackingUsageDescription (e.g., "This app uses tracking to personalize ads.").
-
Request ATT Consent:
- Prompt for consent when the app launches or after onboarding, based on your UX strategy.
- Use Singular’s SDK to handle pre-consent initialization.
-
Configure Singular SDK:
- Set the waitForTrackingAuthorizationWithTimeoutInterval configuration method when building the SingularConfig object to delay events until ATT consent is resolved or the timeout (e.g., 30 seconds) expires.
When using Flutter, you will need to rely on a 3rd-Party package to implement App Tracking Transparency. For example: the app_tracking_transparency plugin to your Flutter
Tip: When you set an initialization delay, the app flow is as follows:
- When the app opens, the Singular SDK starts recording a session and user events but does not send them to the Singular server yet.
- When App Tracking Transparency consent is granted/denied, or the set time elapses, the SDK sends the session and any queued events to the Singular server (with or without the IDFA).
- Singular then starts the attribution process, taking advantage of the IDFA if it is available.
The following table summarizes the possible scenarios using this integration:
| Scenario | IDFA Availability |
| The user sees the consent dialog and grants consent before the set time elapses. | IDFA is available |
| The user sees the consent dialog and denies consent before the set time elapses. | IDFA is not available |
| The set time expires, then the user is shown the consent dialog and grants consent. | IDFA is available only for the user events that are reported after the consent is granted |
| The set time expires, then the user is shown the consent dialog and denies consent. | IDFA is not available |
| The user is shown the consent dialog, exits the app without taking action, and later opens the app and grants consent after the set time has expired. | Any queued events are sent to the Singular server when the app is reopened. The IDFA is not available for these events. Any events tracked after consent is granted do have IDFA associated with them. |
| The user is shown the consent dialog, exits the app without taking action, and later opens the app and denies consent. | Any queued events are sent to the Singular servers when the app is reopened. The IDFA is not available for these events or any of the events tracked afterward. |
Best Practices
- Prompt Timing: Request ATT consent on app launch to maximize IDFA availability, or delay until after onboarding to improve user context. Test both to balance consent rates and UX.
- Timeout: Set waitForTrackingAuthorizationWithTimeoutInterval to 30-300 seconds. Post-timeout, Singular proceeds with SKAN 4.0 attribution (no IDFA).
- SKAN 4.0 Integration: Ensure conversion value updates align with ATT consent to optimize SKAN postbacks (e.g., use Singular’s dashboard for mapping events to values 0-63).
- Error Handling: Check ATTrackingManager.trackingAuthorizationStatus for restricted (e.g., parental controls) or notDetermined states and log for analytics.
Manual Conversion Value Handling
Managed Mode
By default, the SKAdNetwork implementation manages the conversion value directly from the Singular server side.
This allows for maximum flexibility as you can set and change your conversion values through the Singular platform, without modifying your client-side code.
This server-side managed mode also helps you deal with the SKAdNetwork timers. SKAdNetwork allows you to update the conversion value within 24 hours from the time of registration to SKAdNetwork. Any call to update the conversion value extends the timer by 24 more hours. Therefore, when choosing your conversion events, you'll have to make sure the events happen within that update window. In managed mode, you can change the conversion event configuration at any time, without releasing a new version of your app.
Manual Mode
If you want to update the conversion value on your own:
- Set the manualSkanConversionManagement configuration method when building the SingularConfig object.
- Then, to update the conversion value, use the skanUpdateConversionValue method wherever needed in your app's lifecycle.
- or, to manually update SKAdNetwork 4.0 conversion values, use the skanUpdateConversionValues method wherever needed in your app's lifecycle.
Note: The skanUpdateConversionValue method will not function if you have not set the SDK to manual updates on initialization.
Retrieving the Conversion Value
To get the current conversion value, use the skanGetConversionValue method. This method works in both managed and manual mode.