How Kameleoon keeps visitors properly bucketed over time
The ability to track people's behavior online using cookies made modern marketing possible.
As companies like Facebook, Google, and Apple signaled that the days of cookies are over, marketers moved to LocalStorage, but this technology, too, began facing restrictions from Apple’s Intelligent Tracking Protection (ITP).
The truth is, privacy protections create a significant technical challenge for A/B testing platforms to keep visitors properly bucketed over time.
Simply put, if your platform has to delete user data after a very brief attribution period, it becomes impossible to trust its reliability. Luckily, Kameleoon has worked for nearly a decade to build a unique, best-in-class solution.
We've combined server set cookies with LocalStorage to allow our clients to continue providing excellent, personalized experiences to their customers. Because experimenters have questions about this solution, and about ITP, cookies and LocalStorage, we’ve created this FAQ.
1 What is ITP?
Intelligent Tracking Protection is a privacy feature in Safari that blocks all third-party storage, including cookies and LocalStorage, from websites. The goal of ITP is to improve customer data privacy for Safari users by blocking third-party trackers that identify and track visitors without their knowledge after landing on a site and restricting the lifespan of first-party cookies and LocalStorage.
While users appreciate their increasing online privacy, ITP poses major challenges to organizations wanting to leverage customer data in experimentation. Tracking restrictions impact Experimenters’ ability to track and identify returning visitors in their analytics and optimization platforms, even if they’re only leveraging first-party cookies. We talk about these impacts in detail in our article here. In short, ITP’s restrictions will cause organizations to lose customer data saved in web browser storage, which will lead to the serving of incorrect customer experiences (due to visitors being incorrectly bucketed) and unreliable reporting (since returning visitors will get counted as new visitors after 7 days).
2 What are the restrictions imposed by ITP?
It’s important to understand that ITP affects various types of web browser storage differently:
Third-party cookies are blocked by default
First-party cookies created by JavaScript’s document.cookie will expire in 7 days. If the cookies are accessed within those 7 days, their expiration date will be extended by 7 days.
First-party cookies created by JavaScript’s document.cookie AND are created by a tracking domain AND use link decoration will expire in 24 hours. If the cookies are accessed within 24 hours, their expiration date will be extended by another 24 hours.
Data stored in LocalStorage in Safari will expire in 7 days. If the data in LocalStorage is accessed within those 7 days, then its expiration date will be extended by 7 days.
3 What’s the difference between first-party and third-party cookies?
A cookie is a piece of data from a website that is stored on a user’s device. A first-party cookie is saved to a user’s device by a web page the user has visited. Organizations typically leverage first-party cookies to make their websites more user-friendly and to provide users with personalized digital experiences.
First-party cookie data is owned by the organization doing the tracking. On the other hand, a third-party cookie is saved to a user’s device by any other site or service, often for cross-site tracking, retargeting and ad serving purposes. Data stored by third-party cookies is owned by an external party.
Apple’s ITP has blocked third- party cookies since 2020, and Google is set to completely phase them out by 2023. This means that marketers will need to learn to optimize with first-party data going forward.
4 What is a server-side cookie?
Server-side, or server set, cookies are created by an organizations’ servers, as opposed to an external tool. While ITP imposes restrictions on client-side cookies, it will not remove server-side cookies because they may be necessary for a website to function as expected.
Because server-side cookies are not subject to ITP’s first-party cookie expiration restrictions, they play a crucial part in Kameleoon’s solution for mitigating the impact of ITP.
5 What is LocalStorage?
HTML5 enabled a new type of technology, LocalStorage, to do the same thing as first-party cookies.
LocalStorage is essentially a database hosted on the browser which collects and organizes information about what the user is doing on the website.
When used with a cross-domain tracking solution (as in Kameleoon), LocalStorage provides the same data to an experimentation platform as pre-ITP2.2 first-party cookies.
That means users get a consistent, holistic view of how the customer interacts with their website.
6 What’s so special about Kameleoon’s LocalStorage solution?
Current ITP updates impose the same constraints on LocalStorage as on first- and third-party cookies. Another problem with LocalStorage is its subdomain/protocol partitioning scheme, where visitors to your subdomain and domain come up as different visitors.
For example, if a visitor goes to your primary domain, randomshop.com, and then moves onto a transaction page hosted on transaction.randomshop.com, the visitor’s data ends up being stored in two separate instances of LocalStorage.
The consequence is the same as in ITP issues, where a user visiting your site today might look like a different user if he comes back a week later. He might also encounter an A/B test meant for new users rather than returning users.
In both cases (ITP or partitioning), you get inaccurate information about the customer, leading to erroneous data and possibly exposing the customer to the wrong experience.
Marketers need their experimentation platform to apply LocalStorage data to the whole domain and allow it to sidestep the 7-day purge required by ITP. Kameleoon’s LocalStorage solution does both of these things.
7 How does Kameleoon’s LocalStorage solution work?
We ask Kameleoon customers to set a server-side snippet on their server via an HTTP header. (We provide this snippet for multiple languages.) The snippet creates a server-side cookie, called the kameleoonVisitorcode. This server-side cookie ensures that a visitor always sees the same variant of an experiment.
Safari removes client-side first-party cookies and LocalStorage after 7 days; therefore, it’s important that the KameleoonVisitorCode cookie is server set, as Safari won’t remove it.
The kameleoonVisitorcode contains a visitor’s unique IDs (visitorCode) and synchronizes data back to LocalStorage from Kameleoon’s servers to save the historical data on the visitor.
By following this approach, the visitorCode is consistently saved and shared between front-end and back-end, and ITP restrictions are also correctly accounted for.
When a visitor arrives on a site, Kameleoon reads the kameleoonVisitorCode and obtains the visitorCode and checks if the current LocalStorage is empty. If LocalStorage is empty, the visitor’s last visit was over 7 days ago. (For new visitors, the server-side kameleoonVisitorCode is not present and they are assigned a new one.) Kameleoon then performs a Server Synchronization Call to fetch all the data that was present in the LocalStorage from our own backend servers for this visitorCode and restores it as if ITP had not wiped out the data.
This solution works under the hood to provide an experimentation platform that does not slow down your website.
Critically, this solution only requires a simple installation of the server-side snippet.
8 But Safari is blocking cross-domain tracking. How does this impact the correct bucketing of my visitors?
Safari’s blocking of cross-domain tracking only impacts your ability to target your visitors for experiments based on historical data that is stored in LocalStorage in different sub-domains. (e.g., You want to serve an experiment on a subdomain to visitors who came to your main domain 3 times in the past month.). This is restricted by ITP because all instances of LocalStorage are independent of each other. This is a challenge all A/B testing providers will need to tackle if you have multiple domains.
The good news is that our solution for consistent bucketing is not affected by Safari blocking cross-domain tracking, and neither is our reporting. It will only limit your ability to target based on data that is shared between several domains.
We are currently working on a solution to this challenge that will be generally available at the end of 2022.
9 How does this solution affect my customers’ privacy? Is LocalStorage secure?
By synchronizing the cookie on client- and server-side, and spending a decade building architecture around LocalStorage, we’ve created the right solution to address ITP restrictions, while also respecting user privacy and adhering to consent regulations.
Besides sidestepping ITP restrictions on cookies, LocalStorage is also more secure because, unlike with cookies, data never leaves your devices.
Ready to get started? See this step-by-step guide and technical documentation.
Request a demo to see this feature and the Kameleoon platform in action.
Questions? Curious? We'd love to hear from you. Please reach us at [email protected]
