Apple announced that users need to opt in to share the information with 3rd parties.
I am confused as to how will this impact user level data collection in Snowplow?
Can someone throw more light on this? Thanks
After reading through it appears the crux of the article is with 3rd party sharing, for example targeted ads, with the exception of fraud detection. If you’ve done a first party implementation I don’t think this will be an issue.
There is also misinformed rumblings about Safari blocking trackers like Google Analytics. This is infact incorrect, the ITP blocks CORS/3rd party and Safari has been doing this since 2017.
More here: https://www.simoahava.com/analytics/no-safari-does-not-block-google-analytics/
1 Like
We’re currently putting together a blog post that covers this in more details but to give a quick overview.
Firstly, we’ll be offering advice on how to appropriately set AppTrackingTransparency when using the Snowplow iOS Tracker. You’ll basically need to set up NSUserTrackingUsageDescription which we will offer advice on soon, from a Snowplow point of view.
The tracker is also currently capable of collecting the IDFA, however from iOS14 this will prompt the user before being accessible. This will likely reduce the number of events that will contain the IDFA. Here is an interesting Forbes article on this.
The iOS tracker does sessionisation client side and sends a userId value in the client_session context. This is tied to the applications install and generally a good way to understand how a specific user is using your application (as apps are not reinstalled very often) but it does not invade on a users privacy in the same way collecting their device specific IDFA does.
The last thing to concern yourself with in iOS 14 are the ITP changes that are coming. On the whole these won’t really effect Snowplow, particularly if you have your Snowplow collector set up on your domain as a first party collector. Safari restrictions that exist today will still exist with the core difference being the privacy report to make it more transparent to the end user what ITP is doing. This is a good thing.
One thing that will change though, is that ITP will now take effect in all WKWebViews. This means third party cookies will not persist and JS set cookies will only persist for 7 days inside Web Views. This against, doesn’t have a huge impact if using Snowplow on your own domain however it is worth noting if not.
If you don’t currently use WKWebView, then I believe the current plan states if you want to publish application updates after December 2020 then you must have upgraded to WKWebView.
And lastly, if you are using WKWebView then you’re going to want to look into App-Bound Domains to use most of the powerful features in WKWebView and to protect your users.
Here are a couple of WWDC videos you might also find interesting:
Check out Build trust through better privacy - WWDC 2020 - Videos - Apple Developer (On this topic, watch for a couple of minutes from 15:00 and a couple more from 26:30)
Discover WKWebView enhancements - WWDC 2020 - Videos - Apple Developer (Around 24 minute mark is probably most interesting on this topic)
5 Likes
@PaulBoocock. Could you link to the blog post you mentioned here?
1 Like
Hi @Sarah_Schell
The impact on Snowplow tracking was very minimal, the blog post never saw the light of day. We didn’t have a lot of information from Apple 8 months ago and the content didn’t really pan out. Particularly because it didn’t lead to much (if any) change from a typical Snowplow iOS Tracker setup, although in the last 8 months things have become clearer from Apple.
To summarise though, the IDFA restriction only really restricts the tracking of users across multiple different vendors applications (it’s a device specific identifier). It affects advertising platforms significantly, as it removes the ability to stitch users across multiple vendors applications. However IDFV is still available so per vendor identifiers are still good. You also have the “installation user ID” which is part of the Snowplow session context as it has always been. Building user modeling around the IDFA has never been a privacy centric approach, so the steps which Apple are taking are welcome as they give users control over their privacy. However it doesn’t leave companies without options for typical analytical use cases as other identifiers are still readily available.
You’ll need to appropriately report how you’re using the data you capture as part of your app store submission, if you’re linking it to the user or not (About privacy information on the App Store and the choices you have to control your data – Apple Support).
One other thing to consider is that a Snowplow pipeline is typically seen as a first party data collection solution and doesn’t fall into 3rd party data collection as Apple defines. This page defines the different App privacy details that Apple requires: App Privacy Details - App Store - Apple Developer
If you have any questons, don’t hesitate to ask - the more I write the more I think that revisiting the blog post might be a good idea!
2 Likes
An important fix about IDFA has been released in the 1.7.0 version of the iOS Tracker.
The version 1.7.0 fixes an issue causing app rejection due to the fingerprinting caused by the OpenIDFA feature.
To avoid any further issue we have completely removed the OpenIDFA identifier and related code.
Also, we changed the policy for enabling the Apple IDFA. On the new version 1.7.0, the IDFA identifier will be enabled only if the developer adds the AdSupport library to the app project and enables the compiler flag SNOWPLOW_IDFA_ENABLED in the build settings.
More details in the release post of the version 1.7.0
3 Likes