2 pillars of privacy: the app developers guide

Now that iOS 14.5 has finally made its grand appearance (and shortly thereafter, 14.5.1… then 14.6), everyone seems to be taking stock of its long-awaited and predicted impact on the mobile advertising industry.

How has iOS 14.5 affected your company? 

Developers are taking stock and trying to figure out how the change will ultimately affect their bottom line. Depending on what the numbers tell you, you’re in one of three boats:
1.    Uh oh, we’re sinking, and need to recover, and fast.
2.    This is a reasonable dip, how do we steadily increase?
3.    Doing okay, and there’s even opportunity – let’s see how to grow further.

What are other mobile app publishers doing? 

In all of these scenarios, though, you’re doing one thing – looking to see what your competition is doing. Isn’t that always how we deal with new challenges? The ATT (App Tracking Transparency) Prompt Gallery is a good place to start, though the part you really want to know (did it work? what was the opt-in rate?) is notably missing.

2 pillars of privacy: the app developers guide

Other than creeping on your peers to see what they’re putting out there, the other thing you might be doing at this time is looking around to see who can help. You likely are getting pitches from companies and vendors who are saying, hey, we’ve “solved” how to sustainably track without tracking, let us do our magic workaround. I’m here to tell you that they’re selling you something that can’t exist.

Watch out for the snake oil salesmen

First let’s acknowledge that in many ways, both the mobile app and the digital advertising industry has come as far as it has because of the boundary-pushers, the innovative minds that question assumptions and find ways around some of the rules (or guardrails?) put in place by the big tech companies. So when Apple made its privacy announcement last year, the wheels were set in motion. 

At first, it was like everyone thought, there has to be a way around this. “Solutions” sprung up from all corners… only to be shut down, either by legal counsel or by Apple itself in its ever-evolving FAQ. Hashed email addresses? Not okay. Fingerprinting? Not okay. 

There is a lot of misinformation going on in the industry right now around acceptable usage of alternative identifiers like these. Apple has made it crystal clear that any kind of alternative identifier usage which combines data from your app to other company’s apps, websites, or properties for targeted advertising and measurement purposes constitutes tracking, and thus requires consent via the ATT modal. If DSPs, or Advertisers, are willing to pay you more money because of the presence of that alternative identifier, then it is likely they mean to use it for such purposes... which makes your new unified identifier pointless, since if you get ATT consent, you can (and should) use the IDFA. This makes your new unified identifier pointless since if you get consent, you can (and should) just use the IDFA.

Now, the degree to which, or how they're going to enforce that, has yet to be seen, but it should be understood that if you, as a publisher are directly enabling the passing of hashed email identifiers without ATT consent, or other persistent identifiers out of the app for use cases which qualify as tracking, you are the party at risk for Apple enforcement. The vendor who sold you the solution might get a black mark on their SDK, but it's your app that may get rejected. Maybe there’s a 50% chance you’ll get in trouble. Maybe it’s 80%, or as low as 20% chance. Is that a level of risk you’re willing to take? 

It’s tempting to stick your head in the sand – don’t do it

Rather than scramble for a solution, some publishers have taken the opposite route: Ignoring the problem. The question I’ve gotten is, If we don’t prompt the ATT modal, then we don’t need to account for tracking on our app privacy page, right? But yes, you do. 

Here’s why: Even without consent to track, you can still collect legitimate and valid information that facilitates app functionality, or even the contextual advertising process, such as when a user clicks on an ad or which OS version they’re on. You can still collect things like IP addresses, and even use that for anti-fraud initiatives. You just can't use the information that you collect in a way that would qualify as tracking.

So that information still needs to be surfaced in the privacy nutrition label, which I’ve written about in detail. And you still need to be having that conversation with your partners to ensure they’re not doing anything that would again, get you in trouble. Because as we’ve explained, the buck stops with publishers.   

The other reason to prompt is that Apple’s criteria for privacy and tracking are explicitly opt-in. Not surfacing the ATT modal doesn’t mean you can do all the tracking and fingerprinting you want with the excuse of “Well the user didn’t say we couldn’t!” 
Unless there’s an explicit opt-in, then it’s considered a hard opt-out by Apple. 

When in doubt, do the “layman Test” 

Apple has done its very best to describe in detail what they consider to be tracking, both in their developer communications and, on a metaphorical level, through their consumer ad campaign.

But if you’re ever in doubt as to what is likely to be a sustainable privacy practice, do what is now being called “the layman test,” in which you put yourselves in the shoes of average informed user and think, “Would he/she/they think of what I’m doing as tracking their behavior? Collecting data to know more about them than they would volunteer and disclosing that information to 3rd parties?” If yes, then you know what your next step is – ask their permission. If not, then carry on...