Apple Privacy Changes

Apple-Logo-Png-Download.png

Apple recently announced that it would begin blocking third-party trackers in Safari (the default browser for both Macs and iOS). Apple is not blocking ads altogether with this move, though it does support extensions for ad blocking already in Safari. The browser already blocks third-party cookies (see footnote 1 for details). The impact is now that, if you as a vendor had a cookie set - or were dropping some sort of attribution pixel to a 3rd party domain - that pixel might be blocked. So conversation pixels, site analytics, data aggregators, etc, may see challenges. The predominant factor in Safari's pixel blocking will be whether the company has a relationship with the user. This means that companies like Facebook, Google, etc may be exempted, while others like Oracle (BlueKai), Criteo, Axciom (LiveRamp), etc will be blocked. Details of the policy are available here: https://webkit.org/blog/7675/intelligent-tracking-prevention/. The idea being that the user’s relationship with that partner’s domain indicates some level of consent about their data being sent to that partner, though it’s highly questionable at best if users of Facebook and Google truly understand the degree to which their data is aggregated by these companies - so the assumption is tenuous at best. 

Intelligent Tracking Prevention itself is not particularly challenging for TripleLift, since we are almost always a “3rd party cookie” that’s already blocked in Safari - so we continue to be blocked from setting pixels, as do most other DSP partners - meaning there already isn’t much userdata being used for Safari users (outside of Criteo - see footnote 2). What is noteworthy is that this could possibly have the opposite impact from what Apple actually wants. Apple’s challenge is that websites are tracking users and undermining their privacy. Indeed, anyone that uses Ghostery or similar tools can see the vast array of services tracking users. Most users do not have any sense that this behavior is going on - or, if they do - have any idea about how to block it. That said, the trackers are there for a reason - because they make whatever publisher has elected to use them some revenue. So it is more likely that alternatives will emerge to bypass the restrictions Apple is implementing, and they likely are going to be far less respectful of user privacy. For example, Facebook, Amazon and Google are likely exempted from Apple’s tracking blockers - because they have a relationship with the customer and users visit these sites regularly. These companies could emerge as being a hub for attribution and tracking. All three have a relatively true sense of one’s “identity” - meaning more and more data will be centralized by brokers that can match an individual to an ever-increasing amount of data. It’s not clear why there would be any benefit to consolidating all knowledge to a certain set of consumer-facing companies that have leveraged their position for non-consumer, and often non-transparent activities that consumers have no idea are happening. The alternative is a server-to-server data push where identity is predicated on a more universal ID like email hashes or the LiveRamp ID. This means there would be a movement away from the semi-anonymous world of cookies - where the data movement can be tracked - to one of persistent identifiers and more secret flows of data. (See footnote 3 for how this might play out for Criteo)

Safari also released an auto-play video blocker. This means that both publisher- and advertiser-hosted video that autoplay will be paused at the browser level until the user initiates the video. This naturally has an impact on our auto-play video ads (the fact that the volume is on or off does not seem to be considered). This means primarily that we should deprioritize instant-play video on safari, as the play rates will be lower. We already have plans to take into account things like play-rate on sites, devices and browsers, so it fits in relatively nicely to our existing roadmap. 

What is important to note through these moves is that there is a real push by Apple towards privacy. This is likely not altruistic, and is probably predicated on at least three distinct rationale. The first is that Android is the predominant alternative to the iPhone, and Android is owned by Google - who makes all their money from collecting data about users and uses it for advertising. Creating a real contrast between the Android ecosystem - as one of data collection and “misusing” user data, v that of Apple, where one’s privacy is respected at a higher level can be considered as to be a pure sales or marketing initiative - that they don’t actually care and it’s just to create a difference and leverage it and make money through hardware sales v ad sales (or that they do care, but still use it for marketing). The second is that Apple wants to make web monetization as poor as possible on Safari, which is the dominant browser on iOS, which in turn would incentivize publishes to use apps - which Apple can monetize either directly through store fees, or indirectly through user/app lock-in. This is supported by the fact that no similar restrictions exist in the app ecosystem, which is exacerbated by apps having relatively persistent identifiers. The third is that Apple may want to build an increasingly personal set of devices that will know an ever-increasing amount about their users - health, mood, location, etc - and they believe they can only effectively do that if they very strongly respect user privacy through and through. It should be noted that Google was the company most people felt comfortable sharing their health data with per a Rock Health 2016 survey, followed by Microsoft, Samsung, then Apple - Amazon, IBM and Facebook were much lower. It’s unlikely that Google will take the same privacy stance in Android (but likely would with health data), so it will be interesting to watch the bifurcation of how user data is leveraged over the two ecosystems. 

Footnotes
1. The relevance of this is that, unlike most other browsers, in Safari you can only set cookies belonging to the domain of the page you’re on - so third parties can’t set a cookie on one site, and then follow that user on another, different site. Said alternatively, if you’re on a.com, and you try to set a cookie for z.com, Safari already won’t let that happen. So if you then go back to a.com, or go to b.com - the cookie that z.com tried to set won’t have been saved (meaning a request to z.com will appear like it has no data on that user). This has been in place for a while. It currently means that TripleLift’s adserving cookie domain, 3lift.com, cannot set cookies for users (we can and do set cookies when users click on our ads - they are first directed to a 3lift.com page where we can set a cookie for 3lift.com - because the domain matches - then they continue on to their final destination). This has largely meant that Safari users don’t have as high a match rate and monetized at a lower rate. 

2. Criteo currently leverages its partnership with e-commerce sites to bypass the domain level cookie rule in Safari by creating a tool such that when a user is on a partner site and they click on something, it will briefly redirect to a criteo.com page, then redirect back to the destination. This enables Criteo to write a cookie for that user. Intelligent trackers introduces the problem that, if the user then goes to a product page - the normal way that criteo would be able to retarget that user is with a pixel from that page indicating what the product is, then criteo would use it’s already-set cookie ID and be able to retarget that user (it syncs with SSPs through another protocol beyond the scope of this Lift Letter). This behavior is being blocked in future versions of Safari.

3. Instead of using cookies, Criteo could partner with a partner that combines techniques like browser footprinting, email hashes, etc that creates a unique identity. This company could be cnamed for each publisher (meaning when you go to abc.xyz.com, it actually points to third-party.com), then this would send server-to-server information to all the relevant parties. Criteo would then move away from targeting based on cookie, to targeting based on a unified identifier that’s passed server-to-server.