As you look to monetize your site with ads, it’s important to understand how a user’s browser can impact ad revenue, as each of the major browsers has its own stance toward cookies, ad blocking, and so on.
In this post we’ll look specifically at Apple’s Safari browser. Not unsurprisingly, given Apple’s stance on privacy, Safari favors user data rights over advertisers/publishers — enabled through a feature called Intelligent Tracking Prevention (ITP), which blocks all third-party cookies on Safari, across mobile and desktop.
This article will explain what ITP means for publishers and present ways to monetize Safari users despite Apple’s limitations.
First released in 2017, Apple’s Intelligent Tracking Prevention (ITP) blocks third-party cookie tracking in its Safari browser, as well as sets limitations for how long certain first-party cookies can be stored.
As soon as it was released, though, ad tech vendors found workarounds to the third-party cookie limitation — leading Apple to engage in a cat-and-mouse game to block these hacks.
Here’s a brief overview of key ITP updates through March 2020:
|ITP version||ITP goal|
|1.0||Limited third-party, cross-site cookie tracking to 24 hours; third-party cookies purged after 30 days of inactivity|
|1.1||Allowed third-party services with embedded content (eg, embedded video, social logins) access to third-party cookies|
|2.2||Limited first-party cookies set via JS and which used link decoration (aka they append info to the URL, like "site.com?clickID=user123") to 24 hours|
|2.3||Limited DOM storage, like localStorage, to 7 days; downgraded all cross-site request referer headers to the page’s origin (aka, stripped “?clickID=user123”)|
To stay up-to-date with ITP, you can follow Apple’s WebKit team blog.
Safari is the default browser on all Apple devices and the second most popular browser worldwide (after Chrome) — with an approximate 18% global market share.
Diving into desktop versus mobile, though, you find some starker differences:
This means that ITP’s impact on your ad revenue will disproportionately skew toward mobile and tablet visits.
ITP presents challenges not just for third-party cookie usage, but also for first-party cookies, so it’s important to understand in what scenarios you could be impacted.
|Your advertisers want to insert pixels for impression verification and user matching||Their third-party cookie is blocked; advertisers won’t get that information|
|You do above and also append query strings to the URLs (e.g. site.com?clickID=user123)||Information is stored for only 24 hours|
|You set first-party cookies using a server-side script (such as using the Set-Cookie header in the HTTP response)||Cookies live indefinitely|
NOTE: If a user returns to your site within the same 24-hour/seven-day period, the data clock resets.
Ad exchanges and DSPs rely on cookies and third-party pixels to do user matching — whereby they match the users on your site, in real-time, to a database that contains information about them. They then use this data to decide how much they are willing to pay for that impression.
This is especially valuable for retargeting, where an advertiser may be willing to pay 10x+ higher eCPMs to reach someone who visited their site that week. But if they can’t tell who your user is — because these third-party cookies are blocked — they won’t pay a premium.
Due to this, eCPMs (and therefore revenue per user) on Safari will naturally be lower than on Chrome and other browsers — an average of 30% lower than Chrome according to Digiday, and by as much as 51% according to data from OKO.
If you are storing user data via
This may make it hard to do targeting such as behavioral targeting or frequency capping, as normally you would just store information about their past browsing/click behavior in a cookie for quick reference.
To illustrate this point, let’s say you have an advertiser who wants to show only one ad to a user per month. You would run into this issue:
|Day of visit||What happens|
|May 1: User visits site||Frequency capping cookie with Ad ID and timestamp is dropped|
|May 2: User visits site again||Ad server recognizes person via the cookie and does not show the ad|
|May 9||Safari deletes cookie automatically||May 15: User returns for first time since May 2||Ad server does not recognize person and shows them the ad|
Your alternatives here are to:
Likewise, if you are setting cookies via JS for reporting, ITP could cause attribution issues. For example, upon ad click you may be storing a cookie that says “Ad ID: 4124”. When that person makes a purchase (or converts in some manner), you then pull the Ad ID from the cookie, which allows you to report that the ad drove a purchase.
If the person purchases after the cookies have been cleared, though, you would lose the ability to tie that conversion data to the ad, increasing the risk of underreporting performance and skewing “time-to-buy” metrics.
The solution to this would again be either setting cookies server-side or a DMP.
If you’re working directly with advertisers, you know the importance of being able to accommodate third-party click and impression pixels, as well as including auditing and audience measurement tags like Moat and Integral Ad Science.
As Safari will block these third-party tags, advertisers will have to make the choice whether to exclude Safari from their targeting or live with the situation. The good news is — you can explain it’s a technical limitation outside your control. The bad news is — it may make it hard to fill your Safari inventory.
While ITP has always been a negative for ad tech vendors and programmatic publishers, that doesn’t mean there aren’t opportunities to grow ad revenue from Safari users, particularly for Utility Publishers.
Publishers who offer direct-sold, server-side ad placements — including native ads, such as sponsored listings — will benefit, as advertisers will be looking for fast, high-value placements and unique first-party data.
Getting ahead of this curve will help you monetize not just your Safari users — but users across all browsers and devices.
Safari’s ITP also reinforces a point we can’t emphasize enough:
Your relationships with your users — who they are and what interests them — allows you to sell against this data. There’s a reason that companies like LinkedIn, Twitter, and Facebook are making billions from their ad platforms: they are able to charge premiums for layering on first-party data like company, job title, interests, who they follow, etc. While the average eCPM for a programmatic exchange may be $1-$2, LinkedIn is drawing in $6+.
Additionally, you don’t need demographic data to provide value. Context, searches, and on-site behaviors are also immensely valuable first-party information. Amazon’s Sponsored Products are a great example: the data Amazon sells against is who is searching for what and then letting vendors pay to promote their products to those people.
For example, if Amazon knows I’ve searched for window shades, it can display sponsored products that match my search terms — and change higher CPMs to advertisers looking to reach me with products that might meet my needs. The relevance of these ads improves my experience as a user and helps Amazon boost its ad revenue.
Mozilla’s Firefox browser also blocks third-party cookies, and Google has committed to blocking third-party cookies too by 2022. This means that the issues — and opportunities — outlined above for Safari are already applicable to an additional 5% of the market (Firefox) and eventually 64% more (Chrome).
The push for data privacy is only getting stronger, so we’ll continue to follow the cookie crumb trail and share more insights on how publishers can generate ad revenue in upcoming articles.
Jane is the Product Marketing Manager at Kevel. She enjoys discovering user-first ad platforms and articulating the value of Kevel's ad serving APIs.