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 cookie 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 set on a custom domain.
In autumn 2022, Safari announced a new change in how they treat cookies. They capped 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.
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.
| Related: What are third-party cookies. |
Safari Intelligent Tracking Prevention (ITP) is a privacy feature introduced by Apple in the Safari browser to limit cross-site tracking by restricting how cookies and other tracking technologies function. ITP uses on-device machine learning to identify tracking behavior and enforces rules that reduce advertisers' and data brokers' ability to track users across different websites, affecting how analytics, ad attribution, and user targeting work on Safari.
Apple's Intelligent Tracking Prevention (ITP), which first made its debut in 2017, has seen multiple transformations to become increasingly restrictive with each iteration. Safari’s main goal regarding ITP tracking limitations is restricting advertising and analytic networks from profiling users across different websites. This cap helps to raise user privacy and prevent unwanted tracking of users' online activities. But on the other hand, 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 the existing restrictions and disadvantages of using third-party cookies for browsers based on WebKit.
First-party cookies are small data 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 are those set outside of 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 the use of third-party cookies' further and improve user privacy. Here is a short timeline of the critical updates to Safari cookie lifetime:
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 user data 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 Apple ITP limits the use of third-party cookies in Safari, this results in less accurate user profiling and, thus, less compelling interest or behavioral targeting. As a result, advertisers spend less money on paid campaigns because of low results.
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 which conversion should be attributed to which campaigns.
ITP Apple 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.
This is the reason why many popular affiliate networks have started making 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 whether 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 a new visitor. 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 an effective solution was soon discovered. By employing server-side tagging, web developers could easily bypass this issue.
In the case of server Google Tag Manager (sGTM), if you set up a tagging server URL located under your main site domain, like ss.example.com for the website example.com, the tagging server can set first-party cookies, which will increase the cookie lifetime to the default settings.
After advertisers found this solution, WebKit tried to restrict it even more. Their main concern was CNAME cloaking, which was later curbed. CNAME cloaking is designed to outwit ITP so that it would treat third-party cookies as first-party cookies. If ITP Safari detects CNAME cloaking, it limits JavaScript first-party cookies to the same 7 days as it would limit third-party cookies.
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. Apple 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 sGTM also moved to using 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 brought 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, unless they are 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 Safari ITP cookie 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 a custom domain that you use for your server GTM container.
5. Type or paste your container identifier (you can find it in Container Settings on your Stape account).
6. Click on the Cookie Keeper checkbox 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. On any pricing plan on Stape, standard cookies for the most popular platforms are available: Google Analytics, Google Ads, TikTok, Facebook, and Stape cookies (including cookies set using Data Tag).
For Business-plan 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.
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.
For this, you need to have a master cookie* in place, based on which Cookie Keeper will restore the user's cookies. The optimal approach is as follows:
Once you've created such a cookie:
1. Activate Cookie Keeper in Stape Power-Ups for your container.
In the settings, select the platforms you need, and add custom cookies if necessary.
2. To use Cookie Keeper, you'll need to replace the GTM loader snippet.
Go to the Power-Up 'Custom Loader' and in its settings:
A Custom Loader snippet will be generated for you to use instead of the standard one.
After this, everything is ready, and you can test the functionality of Cookie Keeper.
* You can also use other types of user identifiers, although cookies are preferable. Cookie Keeper also supports retrieving the user identifier from Local Storage, DOM Elements, and JavaScript variables.
The example below shows how to check the renewal of GA4 server-side cookies using Cookie Keeper. If you use other platforms, you can also check their cookies.
1. Open Safari browser: Make sure you are using Safari version 16.4 or higher. You can check the version by clicking "Safari" in the menu bar and then selecting "About Safari."
2. Access your store: Navigate to your store's URL in the Safari browser.
3. Inspect Element: Right-click on any empty space within your store's webpage and select "Inspect Element" from the context menu. This will open the Developer Tools panel.
4. Open the Storage tab: In the Developer Tools panel, click on the "Storage" tab to view the storage information for your store.
5. Find the Cookies section: On the left side of the "Storage" tab, click on "Cookies" to display the list of cookies associated with your store.
6. Locate and save the FPID value: In the list of cookies, find the 'FPID' cookie, which is the user ID cookie set for GA4. Take note of its value by copying it to a text editor or writing it down.
7. Delete the FPID cookie: Click on the 'FPID' cookie and press the "Delete" key on your keyboard, or right-click and choose "Delete" from the context menu. This will remove the cookie from the list.
8. Refresh the page: Reload your store's webpage by pressing the "Refresh" button in the browser or pressing the "Cmd+R" keys on your keyboard.
9. Refresh the page again: In order to see the updated cookies in Safari, you will need to refresh the page once more.
10. Verify the FPID cookie: After refreshing the page twice, locate the 'FPID' cookie in the list again. The value of this cookie should match the value you saved earlier.
You can route the 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 Safari ITP recognizing server-side cookies as first-party cookies.
Stape Own CDN is available on all plans.
Here’s how to configure Own CDN using CloudFlare:
1. Go to your Stape container setting and select Own CDN.
2. Go to CloudFlare and configure CNAME record for the tagging server URL. Please make sure that Proxied is enabled. The setting should look like in the screenshot below.
3. Go to the Rules → Configuration Rules - create a new rule
Scroll down on this page and find the SSL feature. Activate it with the Full option.
4. Go to the Rules → Transform Rules → Modify Request Header - create a new rule
Specify any name you like for the rule
Select Custom filter expression
Field: hostname
Operator: contains
Value: specify your sGTM subdomain, in our example, it is ‘gtm.stape.tools’
In the modify headers section, specify:
Type: Set static
Header name: X-From-Cdn
Value: cf-stape
Deploy changes.
5. Go to the Caching → Cache Rules - create a new rule
Cache eligibility: Bypass cache.
Deploy changes.
That's it, now all your requests to and from sGTM will be proxied through Cloudflare.
Also, please make sure that Web Application Firewall is set to off.
If you get this error after configuration, it is usually due to one of two reasons:
a) You have some additional rule that creates redirects, which causes this problem.
b) Problems with DNS configuration for the whole site. Switching SSL/TLS to the ‘Full’ option often helps.
The recent update to Safari ITP cookie policy, 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 ITP tracking challenges: Cookie Keeper power-up and Own CDN feature.
Stape has lots of tags for server GTM! Click on Try for free to register and check them all.
Subscribe for updates:
we don’t spam!
Ira has 10+ years of digital marketing experience, with the last 5 focused on server-side tracking. She understands how and when it works across various digital marketing scenarios.
Comments