The Hazards of iOS for Marketers, Part 1: IDFA

Preamble: This blog does not provide legal advice. Every company must consider their own unique context.

Marketers can’t ignore iOS. Depending on how you measure audience and which audiences are most important to you, more than 50% of your audience might be on iOS. Overall, 50% of mobile advertising spend takes place on iOS, despite Android having a much larger share of ad impressions. And Safari is by far the most popular mobile browser on the market (56% of impressions to the #2 browser, Chrome, at 32%).

Unfortunately, Apple places unique limitations on marketers operating in the iOS ecosystem.

We need to understand how these limitations impact the marketing community, and just as importantly, measure the risks of circumvention.

Broadly speaking, the three most important limitations of iOS for marketers, are:

• Reliance on Apple’s proprietary state management/cookie replacement, IDFA.
• The default 3rd party cookie blocking setting on Safari.
• The rise of Limit Ad Tracking, a prominent tracking opt-out setting.

This is the beginning of a three part series addressing each of these limitations in turn.

A robust and rather one sided debate is underway about whether these limitations imposed by Apple are appropriate, proportional, competitively driven, consumer interest driven, etc., and I’ll avoid that debate as much as possible here. The debate needs to happen, but in this piece I’ll attempt to sort through the practical implications of the iOS world that we currently live in and leave the lobbying to others.

Part 1: Using IDFA

Traditional web cookies do not work for state management on native applications for either Android or iOS. Without state management, advertisers cannot build profiles for targeting or engage in basic cross-application measurement, optimization, or attribution. Fortunately, both operating systems provide a centrally managed unique device identifier that advertisers can use for cross-application state management. For iOS, the identifier is ‘IDFA’ (‘ID for Advertisers’).

IDFA quickly replaced permanent identifiers and other awkward work arounds (paste board objects, etc.), and become the currency of online advertisers on iOS. IDFA was built with specific user privacy features in mind and has succeeded in replicating many of the privacy features of the desktop cookie based system. Users can reset their IDFA at will (similar to deleting cookies) and can ‘Limit Ad Tracking,’ which in iOS 10 renders IDFA un-usable (similar to blocking 3rd party cookies).

For state management across native applications, IDFA works beautifully. Its main limitation is that it does not extend to iOS Safari. This is is especially troubling for advertisers seeking to understand the customer journey from advertisement to final action. Whenever the user takes a path that includes Safari, the chain of tracking and attribution is broken.

Using alternative state management techniques

Statistical IDs (probabilistic IDs based on a combination of observed characteristics) are an example of a technologist’s approach to overcoming the limited visibility imposed by IDFA. A statistical ID can effectively bridge activity associated with IDFA on native apps to a Safari session, and back to the native app.

It is very difficult to argue that a typical consumer understands the nuanced power and limitation of IDFA as a state management tool and in particular, how ad related tracking happens, and is fine, throughout the in-app journey, and then suddenly breaks at the Safari border, even when the user is unaware that they have transitioned to Safari. Either extreme point of view (‘I am always tracked on iOS’ or ‘I am never tracked on iOS’) seems more logically coherent. This argument is even stronger when the application of the data is simple ad attribution, rather than profile assembly for targeting.

Unfortunately for advertisers, iOS is not part of the ‘open web.’ IDFA is a proprietary ID subject to specific terms and conditions set by Apple.

So what does Apple say about IDFA circumvention?

First of all, recall that Mr. Jobs actually had a personal axe to grind with 3rd party analytics firms back in 2010, calling out Flurry by name and introducing a so called ‘anti-Flurry clause’ to the iOS Developer Program License Agreement. This clause hasn’t gone anywhere and marketers are still dealing with it and the ethos that it embodies.

According to Apple’s App Store Review Guidelines, an agreement that each application owner must agree to in order to be listed in the App Store, IDFA circumvention is a challenge and could put the application owner in some jeopardy.

5. Legal; 5.1 Privacy; 5.1.2 Data Use and Sharing

cannot use or transmit someone’s personal data without first obtaining their permission
or to serve advertising in compliance with the Apple Developer Program License Agreement

On (i), ‘personal data’ is helpfully undefined. But in the EU ‘Personal Data’ is generally understood to include state management IDs like IDFA and their equivalents, including statistical IDs, and in the US, the FTC has taken the position that these IDs are ‘Personally Identifiable Information’, a term that is usually understood to be narrower than ‘personal data.’

So we need consent for tracking associated with a state management device, whether that device is IDFA or a statistical ID. But there is no specific statement about IDFA alternatives here, so everyone is in the same boat. And no standard for consent is described, so we can assume that consent in this context can be obtained by way of an application provider’s privacy policy, at least until informed otherwise by Apple or others. Apple certainly hasn’t required specific and separate consent for the use of IDFA from each application, for example.

Of course, existing industry standards require that statistical IDs be specifically called out in privacy policies. So get on this, if you haven’t bothered to check in the past.

(ii) might be more directly applicable for us, as it states comprehensively, that no data can be collected or shared except for purposes related to 1st party app improvement, unless the data is used in compliance with the Apple Developer Program License Agreement.

So let’s go there …

Actually …

The Apple Developers Program License Agreement does not say anything about data collection about the user for advertising purposes, IDFA or otherwise.

Perhaps they mean the ‘iOS Developer Program License Agreement,' which is oddly missing from the main ‘Terms and Conditions’ page. We’ll get to that in a moment.

When an application owner is ready to submit their app to the app store, they will encounter this dialogue:

The key bits for our purposes are:

IDFAis the only way to offer targeted ads.

…

only for the purposes listed below and respects the Limit Ad Tracking setting

So … statistical IDs and other IDFA circumventions appear to be out of bounds, at least with respect to the serving of targeted advertising.

Perhaps we can use them for attribution?

Now lets get into the iOS Developer Program License Agreement.

First of all, the ‘Limited Advertising Purposes’ that we get to use IDFA for are defined as follows:

attribution

So clearly IDFA was intended not just for targeting advertising, but also for analytics and attribution, among other uses.

Further:

and any third party with whom You have contracted to serve advertisingYou may not use analytics software in Your Application to collect and send device data to a third party. Further, neither You nor Your Application will use any permanent, device-based identifier, or any data derived therefrom, for purposes of uniquely identifying a device.

The last portion (bolded for reference) is the infamous ‘anti-Flurry clause’ and seems to directly refer to traditionally less controversial data uses like analytics and attribution. This is not a limitation that is specific to ‘targeted advertising.’

Sections 3.3.12 and 3.3.13 only address advertising using the advertising identifier (IDFA). Arguably only advertising, analytics, and attribution, done in accordance with these sections, using IDFA as the sole basis for state management, is allowed.

Now … a good lawyer could push back using several technical arguments. Is a probabilistic ID a permanent, device-based identifier? Nothing is exactly permanent, especially when you have the built in rotation and decay features of a statistical ID. But it’s certainly used for purposes of uniquely identifying a device. And the intent of the language seems pretty clear here.

Another reasonable argument that was highlighted to me from a thoughtful draft blog post reviewer focussed on the word ‘permanent.’ The argument is that that Apple was specifically concerned about the use of ‘permanent’ hardware level device IDs (UDID and the like), which are not resettable and lack the privacy controls of IDFA. In theory, if a company were to create their own ID and replicate cookie-like privacy controls, perhaps they would be in compliance with this provision. However, I’m not sure that this helps companies avoid the ‘may not use analytics software’ line. And could any 3rd party present a case that their identifier has similar levels of transparency and control to IDFA, with all of the embedded OS level controls?

Is the license agreement over broad or otherwise unenforceable in this area? Is the language too complex and perhaps poorly crafted, and therefore not applicable? If apple takes no action to enforce these guidelines, can the market effectively run through them and then adjust if and when Apple begins to enforce?

The lawyers can debate these points and we’ll get some popcorn.

The likelihood of a state or federal regulator taking action against a company on the basis of the agreements cited here seems quite low, as these agreements are commercial between the parties (Apple and the applications running third party ad code), and are not agreements between commercial parties and the consumer. However, we should consider the privacy policies of the applications where the ad code is running, including whether or not they disclose statistical ID tracking for the purposes contemplated.

In summary, Apple legal documents clearly state that IDFA is intended to be the sole state management tool for targeted ads, and we’re not supposed to work around it for advertising or related tracking purposes.

Perhaps the language is not enforceable (lawyer up!) or in any event, might be unenforced currently (until the bear wakes up). So if you are considering this direction, do so with eyes wide open and take precautions, including reviews of first party disclosures, and perhaps … have a backup plan.

One other consideration:

Historically, once a company in the digital marketing space needs to take a defensive position on privacy issues based on public accusations in the press, the best legal arguments seldom bring comfort. The market usually provides too many alternative platforms to deploy spend, and a few months of lost momentum can be difficult to recover from.

Did we miss something? Do you evaluate the risks differently? Please let us know in the comments!

Colin

Next up: Part 2: Safari’s no cookies default

If you liked this post, we’d greatly appreciate if you’d click the heart below and leave us some feedback here or on Twitter. We’ll keep this post up to date as additional perspectives come in from the community.