Third-party Cookies Expiration and DYID Retention

Privacy concerns are at an all-time high, and many business and communications outlets have already announced the phase-out of the third-party cookie, as Apple (Safari), Google (Chrome), Mozilla (Firefox) and other browsers have already limited their use, or have plans to phase them out. 

Apple ITP 2.3, released in September 2019, forces an expiration of 7 days upon third-party cookies and localStorage. Google has already curtailed some aspects of third-party cookies, and has already announced an upcoming block as the browser default. Mozilla has already been blocking third-party cookies by default since 2019. You can expect any browser to already have limitations or plan for them soon.

How does this affect you?

In the Safari scenario, it means that if a returning user does not visit your website for 7 days or more, the Dynamic Yield cookies that are stored in the browser localStorage expire. As a result, the "returning" user is treated as a new user. The implications can be significant: The number of Safari users might be inflated, which can affect multiple areas, such as reports and A/B testing. To overcome this limitation, you must serve the DYID cookie from your server, making it a first-party cookie that is not affected by the new restrictions.


Important: The impact is similar for any browser limiting third-party cookies, though future developments might differ in the details.

How to serve the DYID cookie from your server


This solution is not designed for implementation of Dynamic Yield using Shopify.

The essence of the solution is that the DYID cookie must be set by the backend application serving your website on your domain. Cookies set this way are considered first-party cookies, and are therefore not affected by ITP and can have a longer expiration period. This is something you must ask your developers to set up in the code. The developer should set up the following two steps: 1. Check whether the visitor arrives at your site with a DYID cookie (is a returning user), and if so, 2. Duplicate the cookie with a new name (_dyid_server), and set its expiration date to 1 year.


Let’s say the value of the _dyid cookie is 7237284912004766755. Duplicate the cookie value into a new cookie, _dyid_server, and set the expiration to 1 year by setting 31556951 as the max-age attribute value.

The result is the following cookie: _dyid_server=7237284912004766755;max-age=31556951

Now, let's look at the flow, and see how this solution works:

  1. A visitor enters your website.
  2. Your server (backend application) gets a request to return a web page from the browser. Requests from returning users include the _dyid cookie.
  3. Your application server performs the following steps:
    1. Checks whether the request includes a _dyid cookie.
    2. If the _dyid cookie is found, it duplicates it as a new _dyid_server cookie.
      Returns the new cookie as a response header, with a 1-year expiration date.
      This sets it as a server-side first-party cookie in the visitor’s browser, which is not affected by the cookie expiration enforcement.
      (Note that the _dyid cookie continues to be returned, this should not change).
  4. Our script now uses the _dyid_server cookie as it runs on your page, and your visitor sees the rendered content of your website.
    This way, no returning user data is lost, even if the user has not visited your site in more than 7 days.

Note that if you have enabled Active Cookie Consent, it's important to wait for the consent object and act upon its result. Otherwise, you might write cookies for opted-out users.

Code examples


>>> curl -v --cookie "_dyid=-3233584359067736988"                                                                                                                                                                                                                                                                                        19:55:13
*   Trying
* Connected to ( port 80 (#0)
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.64.1
> Accept: */*
> Cookie: _dyid=-3233584359067736988
< HTTP/1.1 200 OK
< Date: Mon, 30 Mar 2020 16:55:16 GMT
< Content-Type: text/html; charset=ISO-8859-1
< Set-Cookie: _dyid_server=-3233584359067736988; expires=Wed, 29-Apr-2021 16:55:16 GMT; path=/;; Secure

NodeJS (using Express and CookieParser)

// need cookieParser middleware before we can do anything with cookies
app.use((req, res, next) => {
  if (req.cookies._dyid) { // if this is a returning user and the DYID cookie exists
    const dyid = req.cookies._dyid;
    res.cookie('_dyid_server', dyid, { // store a new server-side cookie named "_dyid_server" with the DYID value
      expires: new Date( + 31540000000000), // Set a 1 year expiration for the new cookie

Python (using Django)

dyid_cookie = request.COOKIES.get('_dyid') 
if dyid_cookie is not None: # if this is a returning user and the DYID cookie exists
    set_cookie(‘_dyid_server’, dyid_cookie, 31557600) # Store a new server-side cookie named "_dyid_server" with the DYID value...


if(isset($_COOKIE['_dyid'])) {
 $dyid_cookie = $_COOKIE['_dyid']; /* if this is a returning user and the DYID cookie exists */
 setcookie('_dyid_server', $dyid_cookie, time() + 31557600); /* expire in 1 year */

Validating the implementation

This procedure checks that the _dyid_server server-side cookie is created with the same value as the _dyid cookie, but with a 1-year expiration date. It can be done on any browser, but we used Chrome in this example:

  1. Open a new browser window and navigate to any page on your website that has the Dynamic Yield script.
  2. Open Chrome developer tools (press Command+Option+J (Mac) or Control+Shift+J (Windows, Linux, Chrome OS).
  3. Go to the Network tab. Select Preserve Log and then click Clear ⊘ .
  1. Refresh the page. Select the first request with the URL of your site (a), and look at the Headers tab (b).
  1. Verify that the value of _dyid_server is the same as the value of _dyid.
    The value of the _dyid_server cookie is in the request header. You can also find the value of _dyid in the Request Headers section of the Headers tab under "cookie:" (the first field). If the values match, your solution is verified.


This validation cannot be done in the Application Tab > Storage > Cookies area because this area includes both server-side and client-side cookies, so some of these will be automatically deleted by Safari.