The ad industry is partially pinning its hopes on email as legacy identifiers get knocked off one by one.
But hashed IDs, including emails and phone numbers, collected elsewhere cannot be used as a replacement for app tracking on iOS 14.
That’s true whether or not the hashed identifiers were collected with consent.
In its developer notes on user privacy and data use, Apple makes it explicitly clear that apps need to receive a user’s permission through its proprietary AppTrackingTransparency framework for any user tracking.
In other words, if developers want to do in-app tracking on iOS 14 devices, they have to get permission through Apple’s own consent mechanism or they’re out of luck.
Apple added that titbit to its dev notes in late September. Beeswax CEO and co-founder Ari Papari called out the update on Twitter last week.
— Ari Paparo (@aripap) October 14, 2020
And there’s another wrinkle. If an app has the AppTrackingTransparency framework enabled – which it’s required to do in order to get permission to use the IDFA – then Apple’s policy appears to prohibit that publisher from using any data collected via its app for other purposes, such as matching or marketing on other platforms.
Colin O’Malley, co-founder of Lucid Privacy Group, a privacy consultancy, and co-founder of Evidon noted on Twitter that although this would be difficult to enforce, a privacy advocate could easily document that type of activity and turn it over to Apple.
It’s not a novel idea that companies need specific permission to use data for multiple purposes. It’s a notion enshrined in GDPR, for example.
But Apple appears to be saying that even if a company has permission to use a person’s hashed email address or some other related hashed ID for app tracking – collected, perhaps, during the onboarding process after download – Apple will not allow it to be used for that purpose on iOS 14 unless permission is given directly through the Apple framework.
And that could have a big impact on the scalability of cookieless solutions that rely on email.
“It seems to mean that the user will have to both provide their email to the app and give consent for using that email in a third-party manner,” Paparo said, “which will certainly reduce the scale of those solutions.”
It’s far from game over for ID resolution and post-addressability solutions, but there will be some impact, and a definite challenge on the road to adoption and ubiquity.
“If you get into the weeds on this document, there is enough gray area for a company to squeak out an argument for its special blend of privacy and consumer-first encryption and data workflow,” said Steve Francolla, head of partnerships at Permutive. “[But] at the end of the day, the intent of Apple’s policy is clear – without a new generation of technology, this leaves marketers without intelligent access to that iPhone audience outside of the walled gardens.”
Be that as it may, LiveRamp plans to keep on maintaining a consented IDFA graph and continue rolling out its Authenticated Traffic Solution (ATS), a product that allows publishers to match consented user data with a LiveRamp ID without the need for third-party cookies.
ATS doesn’t require access to device advertising identifiers such as the IDFA in order to function, said Travis Clinger, SVP of addressability and ecosystem at LiveRamp.
“Rather, [its] intended use is connecting publisher first-party customer data, not app-collected data,” Clinger said. “As such, ATS enables a consumer-publisher relationship beyond the app – [and] email addresses shared with a publisher, with appropriate notice and choice, can be activated independently of the AppTrackingTransparency framework.”
For its part, The Trade Desk is planning to carry on building its Unified ID 2.0 based on the IAB Tech Lab’s Project Rearc principles as an open source solution for the web.
A Trade Desk spokesperson told AdExchanger that industry collaboration will remain the focus between now and when the UID 2.0 go-live date gets closer, which should be at some point next year.