5. Cookies cloning with front-end implementation
In September 2019, Apple introduced ITP 2.3, a significant privacy update that removes 3rd-party cookies after 7 days. Google has also implemented restrictions on certain aspects of 3rd-party cookies, and has announced plans to block 3rd-party cookies by default in future updates of Chrome browser. Mozilla has already been blocking 3rd-party cookies by default since 2019. It is highly likely that other browsers may also be implementing or planning restrictions on 3rd-party cookies.
How does this affect you?
When utilizing Safari, it is important to note that the browser automatically deleted stored SLID cookies, used by the Gravity Field personalization platform to identify users, if a user has not visited your site for 7 or more days. Thus, a returning user will be perceived as new. The consequences will be significant: the number of Safari users will be overestimated, which will impact several aspects of personalization, including reports and A/B testing. To overcome this limitation, it is necessary to pass the SLID cookie from your server, transforming it into a 1st-party cookie, which in turn will allow you to avoid the influence of the above restrictions.
How to pass the SLID cookie from your server?
The solution lies in setting the SLID cookie by the backend application that serves your website. Cookies installed this way are perceived as 1st-party (own domain cookies, not third-party ones) and are not subject to Intelligent Tracking Prevention (Apple ITP), and will have a prolonged lifespan. The installation process consists of two steps:
Checking the user's current cookies.
Processing the cookie according to one of the scenarios below:
2.1. If the user has a cookie named
_slid_server
, its lifespan needs to be updated to one year. The identifier value remains the same.2.2. If the user has a cookie only named
_slid
and there is no cookie named_slid_server
, the identifier must be copied from the_slid
cookie to a new cookie named_slid_server
. Do not set HttpOnly parameter for the new cookies.
Example:
Suppose the value of the _slid
cookie is 63317316ce625bd9270b6442. It is necessary to duplicate this value into a new _slid_server
cookie and set the lifespan to 31556951 as the maximum value of the attribute. Result: _slid_server=63317316ce625bd9270b6442;max-age=31556951
Interaction scenario
The user visits your site.
Your server (backend application) receives a request to display a page in the browser. Requests from returning users include either both the
_slid
and_slid_server
cookies or just the latter.The server application performs the following steps:
Checks if the request has
_slid
cookie.Checks if the request has
_slid_server
cookie.If there is only an
_slid
cookie in the request, duplicates it as a new_slid_server
cookie. If both cookies are present, proceed to step d without duplication.Returns the new cookie as a response header with a lifespan of 1 year. These actions set the
_slid_server
cookie as a 1st-party server cookie. Thus, its lifespan cannot be forcibly reduced by a browser anymore (keep in mind that the_slid
cookie will continue to be returned, no need to change that).
After matching identifiers, the user will see the content rendered for them. Thus, user data will not be lost, even if they have not visited the site for more than 7 days.
Code samples
Validation of the installation using the example of the Chrome browser
To verify the correctness of the installation, you need to:
Open developer tools (Command+Option+J) for Mac or Control+Shift+J (Windows, Linux, Chrome OS).
Go to the Network tab
Select Preserve Log and clear history
Refresh the page
In the column with event names, find the one where the name is the address of your site
Go to the Headers section of this event
In the Request headers subsection, the values of the _slid and _slid_server cookies should match
Last updated
Was this helpful?