PerformanceININside Performance Marketing
JOIN THE PERFORMANCEIN Join the PerformanceIN Partner Network
How Have You Responded to Apple’s ITP 2.0 Update?

How Have You Responded to Apple’s ITP 2.0 Update?

PerformanceIN

With the rollout of ITP 2.0 supposedly introduced at the end of September, how have affiliates and advertisers responded to the update and does it pose a greater threat to digital advertising as a whole?

Third-party cookies are under threat. Courtesy of Apple’s Intelligent Tracking Prevention (ITP 1.0), the time-frame where cookies can be read by Safari on desktop and mobile from a remote domain was cut 24 hours. And now, with ITP 2.0 in place, Apple will restrict tracking behaviour further, blocking sites from reading third-party cookies altogether. But that doesn’t mean it is all doom and gloom for affiliate and cookie tracking. Here’s why:

On paper ITP 2.0 presents a headache for affiliates, as it breaks the traditional tracking model, where an advertiser fires their conversion pixel through their affiliate network and credits a publisher with the commission for the sale they’ve driven. As the conversion pixel is a cookie in third party context once ITP 2.0 is introduced advertisers and publishers won’t be able to read it. 

New framework

Fortunately, this change is not unexpected and the industry has spent several years preparing for it. Consumers have become progressively more savvy about their privacy, browser settings and more prolific in use of ad blockers, all of which has contributed to creeping awareness that the day would come where the industry could no longer rely on third-party cookies. 

Contacts at major affiliate networks are clear that a common framework has been implemented across most advertisers to respond to ITP 2.0, which focuses on a site-wide tag being implemented on their website.

Here’s how the new framework works: 

  • User clicks on the affiliate link
  • The tracking script appends a unique identifier to the resulting URL (e.g: advertiser.com/?affiliate_id=123
  • The site-wide tracking script on the advertiser’s side reads this URL param and stores it as a 1st party cookie in the browser
  • On conversion, the site-wide script simply reads the 1st party cookie and sends it to the affiliate network along with the conversion details
  • The affiliate gets rewarded with a commission

From networks, we understand over 80% of the biggest advertisers have already adopted the new framework. The impact should be further minimised by Safari’s small market share (20%) in the affiliate industry. 

Where is it problematic

ITP 2.0 is, however, more problematic for display advertising and retargeting. The latter in particular relies on following the user around the web using 3rd party cookies, which will be impossible once ITP 2.0 comes into force. The GDPR makes this more problematic: affiliate networks can argue they track users on “legitimate interest”, which is not a pretext that’s available to display companies.

And unfortunately, the tech giants are going to escape unscathed from this, while smaller players will be most affected. Facebook, for example, has its widget on almost every website around and good reason to use that to track end users around the web. Even beyond that, Facbeook.com itself generates more than enough intent signals to enable the company to continue to sell compelling targeting options to advertisers.

So in sum, the large affiliate networks have already taken precautions for ITP 2.0, which should minimise any damage from its introduction. Moreover, Safari’s limited market share should further mitigate the impact affiliate marketing feels. It is far more problematic for display advertising, however, and retargeting in particular faces a real challenge in the way it currently collects data on consumers.

Continue the conversation

Have something to say about this article? Comment above or directly on Facebook, Twitter or our LinkedIn Group.

Tamas Szikszai

Tamas Szikszai

    Tamas Szikszai is Head of London Engineering at Skimlinks. Day-to-day he oversees various engineering teams at Skimlinks, ensuring the products they build are not just useful for customers but up to exacting engineering quality standards too. He joined Skimlinks as a Junior CSS developer and has held countless positions since he joined ten years ago, working across all aspects of our tech stack.

    Read more from Tamas

    You may also like…