https://steamclock.com/blog/2021/02/apple-tracking-analytics-sdks/ Steamclock is a web and mobile software studio based in downtown Vancouver. We make great apps for iOS, Android, and the web. Services Work About Blog Get in Touch More Steamclock is a web and mobile software studio based in downtown Vancouver. We make great apps for iOS, Android, and the web. Close Services Work About Blog Get in Touch Allen Pike • February 8, 2021 Is Apple Banning Free Analytics SDKs? Apple announced last summer that they will soon require users to opt in before apps can get the infamous "IDFA" tracking identifier for that user. While this was controversial in the ad tech sphere, most mobile apps can get by without this identifier. However, most mobile app teams do collect analytics to help make product decisions. What features inspire free users to convert to paid users? Why do we think our trial is converting poorly? Do we still need to support iOS 12? A lot of apps use free SDKs to collect and analyze this kind of data. The most popular analytics SDKs are free because they're owned by companies that sell ads, or share data with those companies: Google Analytics, Flurry, and Google's Firebase. Paid competitors like Mixpanel and Amplitude can be really powerful, but often cost thousands of dollars a year or more. Now, I can't find this said explicitly anywhere. But it seems like, along with the incoming restrictions on IDFA and ad attribution, Apple is also enacting a de-facto ban on these free analytics SDKs. The setup looks like this: 1. Since December, App Store Connect's App Privacy submission process has required developers to indicate if they have "3rd Party Tracking". Developers are told to do this if they're including an SDK from a company that hosts ads or shares data with advertisers across apps. 2. In the coming weeks, iOS 14.5 will require apps that engage in "3rd Party Tracking" to ask explicit permission, which most users will opt out of. 3. App Review will soon start rejecting apps that are not following the opt in provisions. They'll likely do this by comparing the app's App Privacy metadata to the use of the new opt-in APIs, as well as scanning apps for the presence of certain SDKs. 4. Therefore, it seems, iOS apps currently using the Google Analytics, Flurry, and Firebase SDKs may need to migrate off of them promptly and instead use an analytics tool not owned by a company that displays ads. Popular choices include Mixpanel, Amplitude, or a self-managed analytics tool. These new rules could be a big hurdle for some developers, especially if they currently rely on other SDKs that do 3rd party tracking or attribution, such as Facebook's. Do we really have to? The challenging thing for developers evaluating all this is that many of the points above have not been said so explicitly by Apple. Apple has instead outlined a series of rules, each rule being worded somewhat differently between the App Privacy documentation and the App Tracking Transparency documentation. A generous reading makes it seem like you maybe could comply with the rules and still use some of these SDKs. Maybe. Apple did not - and from a legal perspective likely can't - explicitly ban the Google Analytics, Flurry, Facebook, and Firebase SDKs. Their wording leaves some wiggle room. It seems like it could be possible to use them. It seems even more possible that Facebook and Google could make them usable. However, this puts developers in the situation of evaluating the changing documentation, complex privacy policies, and large settings panels that these tools offer, trying to judge whether a given setup of a given SDK would now pass muster from Apple's perspective. For example, in App Store Connect - where developers indicate if they have Third Party Tracking - Apple asks if your app is: Sharing data with entities who display third-party ads. It seems maybe impossible for a Google-owned analytics SDK to not trigger this provision. In contrast, the AppTrackingTransparency documentation asks whether you are: Placing a third-party SDK in your app that combines user data from your app with user data from other developers' apps to target advertising or measure advertising efficiency. Does it matter if the SDK combines user data in general, or is it sufficient if you've been assured that your app's user data in particular won't be combined by the SDK? The logical complexities and differences in wording raise questions that, unfortunately, developers need to make assumptions about until we hear something from Apple, or we hear through the grapevine how App Review actually enforces these rules. In particular we need to make three guesses: 1. Will you be allowed to indicate your app has 3rd Party Tracking, not implement the opt-in dialog, but still get App Review to approve you as long as you believe you're not required to do opt-in based on your evaluation of the SDK, its settings, and the exact wording in the AppTrackingTransparency documentation? Our guess is no. It seems likely that Apple will expect that all 3rd Party Tracking requires the opt-in dialog. 2. Will you be allowed to include an SDK that App Review considers a "3rd Party Tracking SDK", but not indicate 3rd Party Tracking in your App Privacy data as long as you believe you're not required to based on your evaluation of the SDK, its settings, and the exact wording of the App Privacy documentation? Our guess is no. It seems like Apple will probably consider any use of the Facebook, Google, and Flurry SDKs to be 3rd Party Tracking. 3. Is it safe to continue using - or migrate to - 3rd party product analytics tools like MixPanel and Amplitude that are not owned by advertising companies? Our guess is yes. These rules seem squarely aimed at companies involved in advertising. If one of the above assumptions is wrong - for example, maybe these SDKs can be configured to behave sufficiently privately, and App Review can be convinced that this has been done for your app - then that would be really useful to know. If anybody has more information on what Apple will or won't be allowing, or even conflicting hunches, let me know. Does our SDK require App Tracking Transparency? Uh... well... Firebase, Google Analytics, and Facebook have been releasing updates and documentation to help developers navigate Apple's questions, but conspiciously they don't directly answer them. Instead they answer different, related questions that are maybe helpful but are certainly not decisive. Contrast that to paid analytics tools that don't share data with ad companies. MixPanel, for example, posted clearly 6 months ago that they believe they're compliant with Apple's rules: You need to specify what data is used to track someone across external apps and websites, which in our case is none. We only allow customers to track data they own; data sent to Mixpanel is not used by any other external companies. Interestingly, Flurry - whose business model apparently is to share data with advertisers - has also claimed its SDK doesn't trigger the App Tracking Transparency rules. This seems dubious, but is interesting if so. However, if the above rules and assumptions are correct, any apps that don't both purge these SDKs and set their App Privacy to say they no longer have 3rd Party Tracking - or only use the SDKs for the small percentage of users who opt in - will soon face rejection. Meanwhile, even besides these restrictions, there are some substantial benefits to using premium analytics services like Mixpanel. Our advice for now, then, is that all iOS apps should be prepared to migrate off of the Google Analytics, Firebase, Facebook, and Flurry SDKs, potentially on very short notice. If you were already on the fence, now is probably a good time to make the move. A lot of apps might be making changes in the coming weeks. Hold on to your butts. Steamclock is a web and mobile software studio based in downtown Vancouver. We make great apps for iOS, Android, and the web. 2.8.21.1264 Older Post Release Radar: Ora The work and times of the app development team at Steamclock. Archive (39) RSS Feed @steamclocksw Interested in future posts or announcements? Subscribe to our feed. [ ]Email [Subscribe] Need a great app? We'd love to work with you. Contact us about your design and development needs today. Get in Touch Studio * Services * Work * About * Blog * Get in Touch * Contact Products * Bluejay * Two Spies * Quests Follow Us * Github * Twitter * Dribbble * LinkedIn Headquarters * Suite 575 - 375 Water St. Vancouver, BC Canada V6B 5C6 (c) Steamclock Software Ltd. No developers were harmed in the making of this site.