Webkit’s ITP 2.2: How it Affects Analytics Tracking and What to Do About It

Intelligent Tracking Protection (ITP) is the digital equivalent of a volcano in the analytics world—we’ve all heard rumblings and felt tremors from the “privacy” volcano fully expecting something to come to shake up our industry.  

Suddenly in Feb 2019, we heard the first explosion as Apple’s Webkit announced the beta of its ITP 2.1 specification. The Webkit ITP browser engine is used by Safari, Mac, and iOS and thus makes up a sizable chunk of most sites’ customer base and affects the vast majority of sites.

ITP 2.1’s main aim was to cap the expiry of all client-side first-party cookies to 7 days. Luckily the effect of this volcanic eruption has been muted so far. However, in less than 2 months, we have had our second eruption. Webkit released ITP 2.2, which reduced that expiry further to just 24 hours for a specific subset of cookies, which has created problems for many websites.

Impacts of the New ITP 2.2 Standard

One of the main consequences of ITP 2.2 is that campaign attribution is now more challenging than ever.

If you depend on traffic from affiliates such as Facebook and Google, ITP 2.2 might cause you to report inflated unique visitors in your web analytics tool. 

How does this happen?

Under normal, non-ITP circumstances, affiliates like Facebook and Google can easily recognise unique visitor traffic from these sources. Visitors to your site would bring with them a unique visitor identifier via the URL, which the affiliate would match against a cookie previously dropped on the browser. The affiliate would then use the cookie and the visitor identifier to track visitors across domains.

Things are different with ITP.

Now, ITP 2.2 uses a blacklist of domains with cross-domain tracking capabilities. If ITP 2.2 blacklists your affiliates’ domains and your affiliates use something looking like a visitor identifier, the cookies they drop will have an expiry capped at 24 hours instead of 7 days. As a result, you will only be able to identify unique visitors within that 24-hour time frame. 

Addressing the Visitor ID Cookie problem

No matter what solution you use for your analytics, there are a variety of methods to solve the challenge that ITP presents.  Below are some of the more common solutions that have already been identified to mitigate ITP 2.1, and the good news is that they work to address the impact of ITP 2.2, too:

• localStorage. If you store the visitor identifier in the browser’s localStorage instead of in a cookie, you can get around the 24-hour time frame. While this solution currently works fine, it’s likely to be restricted in future ITP releases since it leverages purely client-side technologies that run in the browser.
• Reverse-proxy. Another option is to intercept the HTTP request after ITP caps the expiry of the cookie but before it reaches its destination and then release the request with the correct expiry.
• Edge cache. This option is a similar solution to a reverse-proxy, but is only available on cloud-hosting solutions such as Cloudflare or AWS
• Canonical name record (aka CNAME record, aka alias record). If you configure your DNS to have a subdomain on your website that is sitting on someone else’s server, you can restore the correct expiry of the cookie on that subdomain.
• Server-side cookies. If you send the data from your own servers to your partners’, ITP can’t touch these cookies because they don’t sit on your visitors’ browsers but your servers.

Below we cover some specific methods for tracking unique visitors in Adobe Analytics and Google Analytics in a world where ITP affects a large portion of internet traffic. 

Addressing the ITP 2.2 Unique Visitor Challenge with Adobe Analytics

Adobe identifies returning visitors using a variety of methods, most of which have been affected by ITP because they are cookie-based:

For mobile

Considering that most traffic impacted by ITP is iPhone traffic, let’s have a closer look at the HTTP mobile headers identification method. 

There is a way to bump up that identification method and make the Adobe servers use this as their 2^nd identification method. Since nobody should be using the s.visitorID method anyway, your traffic would use this method instead of any cookie-based (i.e. ITP-impacted) method. 

Assuming that “s” is your Adobe Analytics global JavaScript object, you can implement the following in your Adobe Analytics AppMeasurement library (or your s_code file for older implementations):

 s.mobile = "true ";

Setting s.mobile to “true” will prioritize HTTP mobile headers over cookies for your identification method, resolving your visitor tracking issues for mobile ITP-powered browsers.

For desktop

We’ve configured HTTP mobile headers as the preferred identification method, so what happens on desktops and other devices? 

Nothing. The settings for mobile will be ignored, and the Adobe servers will move on to the next identification method, i.e. the s_vi cookie. For unique visitor identification on desktop, you’ll need to make sure you’re using first-party cookies in combo with the CNAME method we mentioned above.

With your s_vi cookie set as a first-party cookie, the CNAME method will correct the expiry and keep your cookie from dropping off the browser. You can also install Adobe’s Visitor API v4.3 via Adobe Launch which will also leverage the CNAME solution.

If your s_vi cookie is set as a third-party cookie, you are impacted by ITP 2.0, 2.1, and 2.2 on desktops even with mobile fingerprinting enabled. I would consider switching to a first-party cookies implementation as soon as possible.

You might notice lower unique visitors on mobile and desktop for the following reasons:

• Mobile: The fingerprint dedupes returning customers better since it’s based on data that the visitor cannot change very easily, or finds very inconvenient to change
• Desktop: If you are using third-party cookies, some of your visitors will block them and Adobe will depend on the client’s IP address and their user-agent string. Because ISPs assign a new IP address every few days, this option isn’t much better than relying on ITP’s 24-hour window. Visitors and their browsers accept first-party cookies better; Adobe will be able to identify returning visitors and dedupe them better.

Ultimately, you will want to talk to a professional. For all marketing pixels, DMPs and other tools impacted by ITP, please speak with your marketing agency and various vendors for ITP-safe versions of their code. The solution will likely be some form of server-to-server solution.

Main Takeaways

1. Implement s.mobile = “true “; in your Adobe Analytics AppMeasurement library (s_code file on old implementations) and all your mobile tracking requests will use the mobile fingerprint instead of cookie-based identification methods. That will take care of the bulk of the traffic impacted by ITP.
2. Switch to a first-party cookies implementation for Adobe Analytics and/or use the new Adobe Visitor API v.4.3. Both leverage the CNAME solution. It should fix the impact of ITP 2.1 and ITP 2.2 on desktops for all Adobe solutions.
3. Talk with your marketing agency about ITP-safe code.

What should users of Google Analytics do to help minimise the impact of ITP?

Unlike Adobe, Google hasn’t yet announced an official method to solve the challenges brought on by ITP.  

Personally speaking, I am not really expecting one any time soon.  As we can already see in the past few months, there have been two minor releases of Webkit’s ITP framework, which are pretty much on par with their browser releases. Clearly the Webkit team are watching what the industry does to respond to ITP, and reacting quickly. 

They aren’t alone. Firefox is fast on the heels of Webkit, having recently announced their own enhanced tracking protection controls. Privacy seems to be the new selling point that browsers are betting is going to help them to earn back market share from Chrome.

That Webkit has such an agile team means that any large systemic change that is done to something like Google Analytics or Facebook tracking could be rendered worthless very quickly and would result in a game of privacy whack-a-mole.  Thus the larger players need to take a far more strategic approach to find a solution.  

So where does that leave us implementers of Google Analytics? In a pretty good place actually. We need to really just do three things really well.

1. Make a deliberate, concerted effort with user privacy
2. Become more agile
3. Plan for the future using a working party

1. Make a deliberate,  concerted effort with user privacy

Apple, Google, and Facebook are becoming increasingly “privacy-aware.” Knowing this market trajectory means that we can help support these great initiatives. 

It’s time that we all sat down and worked on our own user’s privacy strategies.  We should be adding sections to our implementation documents that deal with things like user privacy and consent.  

We should be asking and answering questions like:

• What happens if users don’t consent? 
• What’s the fallback that caters to their needs?  
• What sorts of processes and testing do we need to put in to make sure that we comply with their requests?

All of these cases need to be added in as part of your implementation strategy. Yes, it’s probably more work, but this is the price of collecting data in a way that’s fair to users (i.e. your customers!).

2. Become more agile

The best way to respond to Webkit’s agility is for our organisations to become agile as well. 

In most companies, the data analyst is the only person warding off the impending data issues. The data team needs to start reaching across the room and partnering with development teams to crack the right solution for ITP that works in your organisation.  

Data implementation tools like Google Tag Manager have made us all a bit spoiled as we can deploy changes without speaking to developers. Instead, if we actively partner with the development team, we can start to leverage solutions like server-hardening for our JS cookies. 

Server-hardening is where developers take JS cookies and make sure they are set by the server and can thus delay the expiry date of the cookie way beyond the 24 hour limit of ITP 2.2.  

Simo Ahava shares a lot of other solutions for addressing ITP, but most of the more effective and long lasting solutions will mean that we need to resort to development. The good news is that for now, data is back to being a team effort and it can only be a good thing to have more people inputting into how we can collect our data in the most effective ways. 

3. Plan for the future using a working party

Whether you are a small or large company, there is no doubt you will need to keep responding to changes in ITP and other privacy regulations. I recommend you start taking proactive steps to address this change. 

Build a working group made up of a developer, data person, and a business analyst. If your company is super small, your working group could simply be yourself and your data practitioner. Set this team’s role to monitor changes in ITP or user privacy.

By being aware of these changes, you will be in the best possible place to make sure your data, the lifeblood of the business, is not impacted and you can focus on building your business in the right way, in a way that lets you build up a great set of customers who respect you because you respect their privacy.  

One way to gauge the impact of ITP 2.2 on your data collection is to use an ObservePoint Web Audit that simulates user activity on your site for Safari on Mac or iOS and compare it against the same audit for another browser engine (like Chrome). 

To see ObservePoint in action, schedule a demo.

References:

https://www.simoahava.com/analytics/itp-2-1-and-web-analytics/

https://www.simoahava.com/analytics/use-localstorage-client-id-persistence-google-analytics/

https://www.linkedin.com/in/eike-pierstorff-77a4a166/

https://twitter.com/fujii0

https://www.linkedin.com/in/plamenarnaudov/

https://omr.ruhr/google-analytics-itp-2-1-prevention-http-set-cookie-snippet-182092779d40

https://marketing.adobe.com/resources/help/en_US/reference/datafeeds-visid.html

https://marketing.adobe.com/resources/help/en_US/sc/implement/visid_mobile.html

https://marketing.adobe.com/resources/help/en_US/mcvid/mcvid-release-notes.html

https://www.pedromonjo.com/2019/02/visitor-identification/

https://www.pedromonjo.com/?s=server-side

https://medium.com/adobetech/safari-itp-2-1-impact-on-adobe-experience-cloud-customers-9439cecb55ac

https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol