Over the past few years, there has been a significant shift in rhetoric from Apple and Google as it relates to privacy. While Apple seeks to use privacy as a point of differentiation, the reality is Apple is the best of a bad bunch. There is much that needs to be done.
Indeed Apple has taken many steps to improve the privacy and sought to limit the data applications have access. They have not gone far enough.
We’ve all become familiar with their sleek brand positioning best captured in their “Privacy. That’s iPhone” campaign. A step that did wonders for the brand’s perception in market. But unfortunately for consumers, the big Apple is still complicit in enabling many applications to extract significant amounts of data from users phones / tablets for what can only be considered user profiling and tracking. Which prompts the question, why else would numerous apps need to send battery percentage or phone carrier information back to their servers? Further, why should any app be allowed to make calls out to servers before the app has fully launched?
Apps do have a legitimate purpose for accessing these types of information to deliver better user experience, and there are valid reasons for some applications to connect to third parties and the internet upon launch. Its worth noting that any solution posed to limit their access would be complicated. But really the question worth posing is while consumers may accept dialogue boxes for Bluetooth, microphone and location, would they be accepting of the many more dialogues currently unbeknownst to them which occur every time they open an app?
Amidst the array of arguments, the positioning around relevance and user experience, the onus is on the OS creators, app developers and ultimately brands to do more in controlling what applications extract from an individual’s personal device. Since the introduction of GDPR and CCPA, all companies should be seeking to limit what data they collect regardless of where they are in the world. A legal lead approach is not all ways the best approach and developers and brands need to be good global citizens. In marketing circles, the notation that our laws will change sooner or later, means we need to embrace that data minimisation, better consumer engagement and value exchanges for experience are the future.
It is in this context that all organisations should seek to remove, to the greatest extent possible, any data collection that does not directly assist in them delivering value to consumers. Brands need to wake up and realise that they must differentiate to succeed in the long term. Differentiation based on the data they collect on consumers is not a long-term strategy for competitive advantage. The collection of data should seek to improve the user experience - in ways beyond targeted advertising. In my view those organisations that collect data purely for the purpose of targeting ads are in danger of falling victim to the renowned academic Michale Porters famous notationl; being all things to all people is a path for strategic mediocrity1.
So what data are they collecting?
The data connected differs from application to application, tracking library to tracking library. The below has been extracted from a network request2 for Flurry Analytics the “worlds most adopted app analytics” which is owned by Verizon Media. This information was collected upon simply opening a paid business focused application.
- OS Version
- Screen height and width
- Device model
- iOS Advertising ID 3
- Battery Percentage
- Disk Usage
- Phone or iPad Carrier
- Memory available
- CPU Load
- Session ID - Could only be for tracking.
- Session duration in milliseconds
Worth asking, is your data worth the experience?
Introduced in iOS 7 the identifier for advertising is an Apple supported id for advertising. The Android alternative is the Google Play Services identifier. Importantly these identifiers allow users to limit the extent to which they can be tracked by selecting limit ad tracking, though this is all but useless when users login to and app, unless the ads are being served programmatically with no other derived identifier. ↩