The Webkit team, led by Safari, has been at the forefront of combating invasive data collection when it comes to web surfing. In a revolutionary move against third-party cookies tracking tactics, they imposed limitations that drastically reduced third-party cookies' lifetime duration to 7 days or even 24 hours. However, companies soon found an effective workaround to this limitation with the help of server-side tagging configured on a custom domain.
In autumn 2022, Safari announced a new change in how they treat cookies. They will cap cookie lifetimes to 7 days for responses from third-party IP addresses. So, we at Stape created a Cookie keeper power-up and Own CDN feature, about which you can find out more here.
In this blog post, we will describe how the limitation of cookie lifetime based on the IP address works and what it means for web advertising and analytics. And, of course, how Stape can help with the new restriction.
Apple's Intelligent Tracking Prevention (ITP), which first made its debut in 2017, has seen multiple transformations to become increasingly restrictive with each iteration. The main goal of Safari when it comes to tracking limitations is to restrict advertising and analytic networks from profiling users across different websites. This helps to enhance user privacy and prevent unwanted tracking of users' online activities on one side. But on the other side, this can make it more difficult for advertisers to target users with personalized ads and track the effectiveness of their advertising campaigns.
Let’s dive into more details on what is wrong with 3rd party cookies and the existing restrictions on using third-party cookies for browsers based on WebKit.
First-party cookies - are small text files stored on a user's device by the website they visit. If the website is example.com, first-party cookies will be considered those set from the main domain example.com and all subdomains blog.example.com, app.example.com, etc. They are used to store information about the user's preferences, such as login credentials, language preferences, and shopping cart items. Because first-party cookies are set by the website being visited, they are considered "first-party" and are generally not subject to the same privacy restrictions as third-party cookies.
Third-party cookies - those set not from your domain. For example, when facebook.com or google.com set cookies on the domain example.com, these are considered third-party. Third-party cookies are often set by advertisers or tracking companies to collect information about a user's behavior across multiple websites.
Safari has been regularly updating its Intelligent Tracking Prevention (ITP) feature to restrict third-party cookies' use further and improve user privacy. Here is a short timeline of the critical ITP updates:
Advertisers who rely on third-party cookies to track user behavior and serve targeted ads may see a decline in the effectiveness of their campaigns when users are browsing Safari. This is because the browser's restriction on third-party cookies prevents advertisers from collecting data on users across multiple websites. As a result, they may see a decrease in conversions and a lower return on investment for their advertising spend.
Ad networks use third-party cookies to collect data about users who visit different websites by assigning the same user a unique third-party cookie. This way, they can see what websites users browse online and understand their interests. Ultimately, they use this data to show ads based on the user's behavior and interests.
Since using third-party cookies is limited in Safari, this results in less accurate user profiling and, thus, less compelling interest or behavioral targeting. As a result, advertisers spend less money and put more into organic outreach, sponsorship, etc. For programmatic media buying, advertisers started to set less CPM for the target audience since the results of this type of campaign decreased.
The second critical use case of third-party cookies in cases of advertising platforms is utilizing a click id. When a user clicks on the ad, most advertising networks add a unique click ID to the URL and store the click id as a third-party cookie. When a user converts, this click id is used to understand what conversion should be attributed to which campaigns. This has a considerable effect on affiliate networks.
ITP makes it difficult for affiliate networks to attribute sales and commissions to the correct affiliates, as the cookie data used for tracking may be deleted after just seven days.
Because of this reason, many popular affiliate networks have started to make server-side tracking implementation mandatory for publishers. With the help of server-side tracking, it’s possible to set first-party cookies and rely on a longer cookie lifetime.
Remarketing is a technique where advertisers show targeted ads to users who have previously interacted with their website. This is typically accomplished by using third-party cookies. Since a user who visited your website in Safari can stay in the remarketing pool for only 7 days, the size of the remarketing audience will decrease.
Analytics platforms use cookies to identify if a user is new or has already visited your website. If a safari user does not revisit your website every 7 or 1 day, they will be considered new. And it will have a substantial negative impact on user journey, conversion analytics, etc.
Webkit's restriction on third-party cookies may have initially seemed like a roadblock, but the most popular solution was soon discovered. By employing server-side tagging, web developers could easily bypass this issue.
In the case of server Google Tag Manager, if you set up a tagging server URL located under your main site domain, like ss.example.com for the website example.com, a tagging server can set first-party cookies, which will increase the cookie lifetime to the default settings.
Even after advertisers found this solution, webkit tried to restrict it even more. Their main concern was CNAME cloaking, which was later restricted. CNAME clocking is designed to outwit ITP so that it would treat third-party cookies in a first-party contact. If Safari detects CNAME cloaking, they limit JavaScript first-party cookies to the same 7 days as they would limit third-party cookies.
In autumn 2022, webkit announced the new limitation on using third-party cookies for all Safari users. They will limit cookie lifetimes to 7 days for responses from third-party IP addresses. This limitation is available only for beta Safari users and does not yet affect everyone. But since it was announced several months ago, it will soon be released to production and affect all browsers using ITP.
Whenever a new ITP detects that the IP address of the URL that tries to set cookies is different from your website’s domain, it cuts cookies' lifetime to 7 days, whether it’s first-party or third-party. For example, your website example.com points to IP 1.1.1.1, and you previously used server-side tagging to increase cookies' lifetime. Let’s say you use the tagging server ss.example.com which points to 2.2.2.2 to set first-party cookies. ITP will detect that example.com and ss.example.com have completely different IPs. In this case, it will treat cookies set by the tagging server ss.example.com as standard third-party cookies, limiting cookies' lifetime to 7 days.
Safari won't decrease cookies' lifetime if the IP address of the domain that sets first-party cookies is half matching (i.e., 16 for IPv4 and 64 for IPv6). So if your main site IP address is 1.1.1.1, then cookies are set from the subdomain that points to the IP, which starts with 1.1. will be considered the first party, and its lifetime won’t be cut. But Webkit says they might change the first 50% match rate rule.
After the restriction on CNAME records, most platforms and server Google Tag Manager also moved to use A or AAAA records for setting up first-party cookies related to third-party domains. So, for example, you can set a custom domain for your sGTM tagging server URL by utilizing A record in case of stape users and set first-party cookies for Google Analytics, Facebook, Affiliate networks, etc., with the help of server-side tagging.
This new release would bring everyone back to where they were using third-party cookies. When a user browses your website in Safari, first-party cookies will live for up to 7 days, except it is set from the domain whose IP matches at least 50% of your website IP address.
Yes! And it’s easy to prolong cookies in Safari using stape solutions:
This power-up helps to make sure that your marketing cookies are active all the time, even if they get deleted. Cookie keeper comes with a “master cookie” - a special tracker that identifies each visitor’s unique ID on your website. This cookie is stored as a first-party cookie and it lets you comply with all ITP rules. So when the marketing cookies are deleted, the “master cookie” provides information to restore them. This means you can still see how people are using your website and how well your advertisements are working, even if the original cookies were deleted.
1. Download our apps for:
2. After the installation, turn on the switch to activate the addition of the GTM snippet to your store.
3. Add your web Google Tag Manager ID, which follows the format 'GTM-XXXXXX'.
4. Add custom domain that you use for your server GTM container.
5. Write your container identifier (you can find it in Container Settings on your Stape account).
6. Click on the checkbox of Cookie keeper to enable it.
7. Go to your Stape account, open your container and choose the Power-ups section. Click on Cookie keeper.
8. Choose the cookies you’d like to prolong and click Save the changes.
For Business-plans users and above, additional custom cookies are available. For instance, if you use Twitter Ads, you can add the "twclid" cookie so that the click ID cookie for Twitter is also restored for the necessary duration.
To find out more about the custom cookies and about the “master cookie” please visit the article on how to increase first-party cookie lifetime set by a third-party IP (Safari 16.4 and ITP update).
9. Now in the Power-ups section choose Custom loader.
10. Choose your domain, enter your GTM Web ID, and select your website's platform: Shopify, Wordpress or Magento. Click Save.
If you have a custom site or do not use Shopify, WP or Magento, please follow this guide on how to configure Cookie Keeper.
You can route sGTM custom domain and proxy sGTM traffic via your website's DNS provider by enabling stape’s Own CDN feature in the admin of your container. The IP addresses of your website and the custom domain of the sGTM will match, leading to the server-side cookies being recognized as first-party cookies by Safari.
Here’s how to configure Own CDN using CloudFlare:
1. Stape Own CDN is available on all plans, so when you open your container on Stape and scroll down to Domains.
2. Then, if you have Cloudflare for instance, configure CNAME record for the tagging server URL. Please make sure that Proxied is enabled.
3. Go to the Rules → Page Rules (1) inside your CloudFlare account. In the URL setting (2) add your tagging server URL ending with /*. Set SSL to Full (3) and Cache Level to Bypass (4).
4. Go to the Rules → Transform Rules (1) inside your CloudFlare account. In the Modify Request Header section (2), create a new rule. If All incoming requests (3), then Set static X-From-Cdn = cf-stape (4).
Also, please make sure that Web Application Firewall is set to off.
The recent update to Intelligent Tracking Prevention, which restricts the lifespan of first-party cookies set by third-party IPs significantly affects all websites, making old methods of prolonging cookies ineffective. This change impacts analytics and advertising platforms since, in browsers like Safari, recognizing returning users has become impossible.
Fortunately, Stape has developed two solutions to address these challenges: Cookie Keeper and Own CDN.
Just click on Learn more, and find out how you can deal with new ITP update with the help of stape.
