How to Keep Safari ITP from Limiting Your Ad Revenue | Adzerk

How to Keep Safari ITP from Limiting Your Ad Revenue

Jane O'Hara
cardimage

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.

What is Apple’s ITP?

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.

  • First-party cookies are created and set by the domain a user is visiting (e.g., NYT.com). They are used for purposes like remembering your log-in name, what’s in your shopping cart, cookie consents, and site personalization.
  • Third-party cookies are set by companies whose domains don’t match the site the user is on (e.g., ad.doubleclick.net). These are placed for many reasons, including site analytics and social widgets, but predominantly for ad personalization and retargeting.

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.0 Blocked cross-site cookies entirely (no 24-hour window); requires publisher’s consent for embedded content to get cookie access; trimmed referring URLs for third-party tracking to root domain if ad isn’t clicked
2.1 Limited first-party cookies set via JavaScript (using Document.cookie) to seven days
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.

Please note that ITP doesn’t limit all first-party cookies — just ones set via JavaScript. Cookies set server-side (i.e. using the Set-Cookie header in the HTTP response) can live indefinitely in the browser. This is to prevent third-party JavaScript tags from dropping first-party cookies whenever they want to, while allowing publishers to freely set their own cookies.

How many users use Safari?

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.

Worldwide internet browser use
Worldwide internet browser use

Diving into desktop versus mobile, though, you find some starker differences:

  • Desktop: Safari is 7% of worldwide browser use
  • Mobile: 21%
  • Tablet: 61%

This means that ITP’s impact on your ad revenue will disproportionately skew toward mobile and tablet visits.

Your rates may vary, though, depending on your audience. You can review your breakdown using your website analytics tool (likely Google Analytics).

What does ITP mean for publishers?

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.

Scenario Impact
You partner with ad exchanges/SSPs/DMPs/etc, who use cookies to do user matching and enhance the value of that impression Their third-party cookie is blocked; without that information, you may draw lower eCPMs
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 store non-cookie data in DOM storage like localStorage Information is stored for only seven days
You set first-party cookies using client-side JavaScript (aka via Document.cookie) Information is stored for only seven days
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.

Key challenges of ITP for publishers

Lower CPMs for programmatic publishers

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.

Targeting limitations

If you are storing user data via localStorage or dropping cookies via JavaScript, then this information will last no longer than seven days (and only 24 hours if it sees you appending a string to the URL on click).

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:

  1. Move to setting cookies server-side, using Set-Cookie in the header of the HTTP response. These will live indefinitely.
  2. Use a first-party data management platform that ties information to a persistent ID, like a hashed username, and stores it in the backend. You could build one yourself or integrate your ad platform with Adzerk’s UserDB to get this functionality instantly.
Reporting limitations

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.

Frustrated advertisers

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.

Key opportunities for publishers

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.

Indeed — Apple’s ITP is just another reason for publishers to start incorporating first-party data and innovative, non-cookie targeting into their ad products.

Focus on direct-sold and native ads

As Safari and other browsers — and privacy laws like the GDPR and CCPA — restrict advertisers’ access to user data, advertisers will start going straight to the source: the 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.

Make high-value first-party data actionable

Safari’s ITP also reinforces a point we can’t emphasize enough:

Publishers’ first-party data have never been more valuable.

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.

Amazon sponsored product example
Amazon sponsored product example

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.

What’s next?

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 O'Hara

Recommended Articles