Safari has recently introduced Intelligent Tracking Prevention (ITP) 2.1, 2.2, and 2.3 that reduce trackers’ ability to establish user identities across sites.
In ITP version 2.1, a cookie created on a visitor’s browser (using document.cookie) expires after 7 days.
In addition to 2.1, with ITP version 2.2, if a user comes from a decorated URL, i.e., a domain classified with cross-domain tracking capabilities and has a query string or a fragment, the cookies on the website expire within 24 hours.
In addition to 2.2, with ITP version 2.3, if a user comes from a domain classified with cross-domain tracking capabilities and has a query string or a fragment, the first-party non-cookie website data expires after 7 days of the user not interacting with the website.
ITP mapping with iOS
- Intelligent Tracking Prevention (ITP) version 2.1 is included in Safari on iOS 12.2 and Safari 12.1 on macOS for Mojave and High Sierra. https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
- Intelligent Tracking Prevention (ITP) version 2.2 is included in Safari on macOS Mojave 10.14.5. https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/
- Intelligent Tracking Prevention (ITP) version 2.3 is included in Safari on iOS 13, the iPadOS beta, and Safari 13 on macOS for Catalina, Mojave, and High Sierra. https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/
How ITP Impacts VWO Tracking
VWO stores all visitor tracking information in cookies. VWO’s client-side testing platform creates these cookies using document.cookie method. After ITP 2.1, we moved this information from cookies to first-party local storage.
With ITP 2.2, if a visitor on your website comes from a decorated link, i.e., a domain classified with cross-domain tracking capabilities and has a query string or a fragment, then the storage duration of the cookie created via document.cookie is capped to 24 hours.
And, with ITP 2.3, if a visitor on your website comes from a decorated link, the local storage option is also compromised wherein the first-party non-cookie storage duration is capped to 7 days.
With the decorated link issue which came in ITP 2.2, the expiry of all first-party cookies and local storage data is 24 hours and 7 days, respectively. This means that even if we use local storage, visitors who return to the website after 7 days of becoming part of the campaign are identified as new visitors. This can inflate the number of unique visitors and skew the conversion rate of your A/B test campaigns. This impacts all the data collected by VWO.
For example, if your funnel has three steps and the visitor completes the last step on the 8th day, then the flow of the funnel will never be complete even though the visitor completes all the steps of the funnel. This is because the data collected throughout the users’ journey can expire after 7 days (because it was stored in the local storage). Post this, the visitor is considered a new visitor, and the data collection starts from scratch. Since the same user is tracked multiple times, the results become ambiguous. To know more about Cross-Site Tracking Via Link Decoration, refer to Intelligent Tracking Prevention 2.2
This can also mean that the same visitor visiting the website after 7 days may be served a different variation of the same test than what was previously shown. This can create inconsistent experiences and impact campaign accuracy. Also, visitors coming on your website from a domain classified with cross-domain tracking capabilities and have a query string or fragment identifier in the URL are treated as new visitors if they appear after 24 hours of their last visit, despite them visiting the site a little more than 24 hours ago. This is because the information about which variation was shown to the user is stored in cookies.
How to Resolve the ITP Issues in Safari?
If The Campaign Is Running on One Domain or Multiple Subdomains of the Same Domain.
If the campaign is running on a domain classified with cross-domain tracking capabilities and has a query string or a fragment, the following are some cases we may find:
- If the user keeps visiting any subdomain of the website within 7 days of the last visit, everything works as expected.
- However, if more than 7 days have passed since the user’s last visit to any subdomain, things may or may not work as expected.
For example, if more than 7 days have passed since the user’s last visit to any subdomain, it may not have the updated VWO cookie data as was on his last visit. This can cause issues that may include, but may not be limited to the following scenarios:
- The user is tracked as a new visitor if he visits a brand new subdomain.
- If the user is part of a funnel earlier, he/she might be included again in the funnel.
- The user may be tracked as a returning visitor, but his conversion might be recorded again.
Installing a Cookie Sync Endpoint
To avoid ITP-related issues, you must install a cookie sync endpoint on your server to read the cookies created by VWO and set an infinite expiry (for example, 10 years). VWO will provide this snippet in various backend languages like PHP, Node.js, Java, Python, etc.
Adding the code snippet is a two-step process:
1. Create a sync code file, and save it with the extension corresponding to the language you want to work with. For example, if you choose to work with the PHP implementations, you must name your file as <fileName>.php.
NOTE: If you choose to work with the .NET implementation, place the sync code in the controller file.
2. Enter the URL of the sync file in the syncUrl attribute of the Code snippet, and place this code snippet file before the VWO SmartCode.
PHP SCRIPT Code Snippet
If you have a PHP implementation, the following configuration needs to be installed before the VWO SmartCode.
With the following script example added, cookies don’t expire, and VWO doesn’t need to rely on local storage at all.
NODE JS Code Snippet
If you have a Node.js implementation, the following configuration needs to be installed before the VWO SmartCode.
FileName: Sync.js, Node.js Implementation
SYNC .NET Code Snippet
If you have a .NET implementation, the following configuration needs to be installed before the VWO SmartCode.
Server Controller
If you are using NetStandard2.0, you can use the above code as follows:
If The Campaign Is Running on Multiple Domains
VWO currently does not support tracking across multiple domains, as it is not supported by default in Safari.
Current Limitation with Cookie Sync Endpoint
Installing the cookie sync endpoint will make other things work, but the surveys in VWO have an impact due to the First-party Local Storage limitation .i.e., If the visitor has not completed all the questions of the survey within the 7 days window, then their progress on the survey is lost as the data from local storage expires after 7 days. Also, they are not considered as a new visitor because that info is available in the cookies after the cookie sync endpoint. Since this information is lost, we do not show the survey to them again.
Frequently Asked Questions
How does the code for cookie sync work?
The logic converts all VWO client-side cookies to server-side cookies and sets their expiry to 10 years. The 7-day expiry limit does not apply to server-side cookies, so tracking and other VWO features work normally.
Does that mean VWO cookies will never expire until 10 years?
No, we have added logic to expire cookies on the front-end manually. VWO stores the expiry of all cookies alongside their values and will automatically determine when a cookie should be deleted.
Should I worry about any security threats or cookies leaking?
Absolutely not; there are no security concerns or threats of cookie leaking, as VWO does not receive or store any cookies sent to the syncing script. All logic lies and is stored on your own server.