Extend cookie lifetime using server-side Google Tag Manager

Intelligent Tracking Prevention and other anti-tracking mechanisms have changed the tracking world significantly. It introduced restrictions on cookies that challenge businesses that rely heavily upon online marketing, especially third-party data collection for targeting ads. 

This blog post will talk about tracking restrictions that affect cookies, how they influence marketing, and how to use server Google Tag Manager to extend cookie lifetime. 

3rd party cookies and privacy concernsCopy link to this section

3rd party cookies are being blocked by many browsers these days. The two most popular browsers that restrict 3rd party cookies are Safari and Firefox. Chrome announced that they will start to phase out of 3rd party cookies by the end of 2023. Meaning that by the end of 2023, around 80% of browsers will stop supporting 3rd party cookies. First-party cookies won’t be affected. 

Let’s talk about the difference between 1st party and 3rd party cookies. To simplify, the main difference is: first-party cookies are set from your site to your domain, while third-party cookies are set from your site to other domains. 

There are no restrictions on the use of 1st party cookies. 3rd party cookies gained a bad reputation because of cross-site tracking. Advertisers use this type of cookies to track users across different domains and to profile users. With the help of 3rd party cookies, big platforms can follow you around the internet and see what sites you are visiting. And in the end, use this information to show you personalized ads. 

How cookies affect analytic and marketing campaignCopy link to this section

Intelligent Tracking prevention algorithms used in Firefox and Safari limit the cookie lifetime to 7 days (when cookies are set with JavaScript) or 24 hours (when cookies are set with JavaScript, link decoration used, and referring to a website is a ´known tracker´). 

Attribution and reportingCopy link to this section

Most marketers use UTM tags to track campaign parameters. When ITP detects UTM tags in the URL, it decreases the cookie lifetime to 1 day. It highly affects the attribution since if a user visits your website clicking on the ad with UTM tags and converts several days later, the conversion won’t be attributed to the ad campaign. 

Analyzing user journeyCopy link to this section

Since cookies are deleted in 1 or 7 days, a user who visited your site 7 days ago will be considered as a new one. It will have a massive effect on the customer journey. You won’t be able to see the complete picture of what traffic sources affected the decision of a customer to make a purchase. 

PersonalizationCopy link to this section

Personalization is frequently used to provide customers a seamless experience by showing relevant offers, content, products, etc. With the decreased cookie lifetime, personalization might have a negative impact. Because a user will be assigned to a new audience pool every time the cookie expires. 

Affiliate marketingCopy link to this section

Each affiliate offer has its cookie lifetime. When a user visits your site in Safari via referral link today and coverts  in 10 days, this conversion won’t be credited to the affiliate. As a result, an affiliate won’t receive the commission. 

Remarketing audienceCopy link to this section

When cookies reset every 7 days or 1 day, it negatively affects the size of the remarketing audience and ad frequency. Platforms will also have less data to create lookalike or similar audiences. 

How to extend cookie lifetime using server Google Tag ManagerCopy link to this section

Setting or extending cookies is a complicated question and should be treated individually for each platform and browser. But to summarize, you can use the server Google Tag Manager container with the custom domain to set first-party cookies and extend cookies lifetime. Check this site to see how cookies work in each browser cookiestatus.com. 

Standard Universal Analytics or Google Analytics 4 clients for server Google Tag Manager set server cookies FPID with the HttpOnly flag. It makes Google Analytics cookies resistant to ITP because ITP mostly affects JavaScript set 3rd party cookies. It means that the server-side Google Analytics cookie will last for 2 years as it was before. 

Google Analytics 4 was released a year ago, and not too many businesses had time to switch to GA4, and most are still using Universal Analytics. If you want to move the existing UA property from web to server tracking, then make sure to enable “Migrate from JavaScript Managed Client ID” in the Universal Analytics Client template. It will prevent creating new users for those who already visited your site. GA will continue using JavaScript Managed Client ID until _ga cookie is reset. Once _ga expires, FPID will be used. 

Our Facebook conversion API tag for server GTM automatically extends _fbp and _fbc cookie lifetime to 2 years. All other stape.io tags for server Google Tag Manager extend cookie. Cookie lifetime depends on the platform.

Extend cookie lifetime using Cookie extender tag in sGTMCopy link to this section

Stape created an sGTM Cookie extender tag designed explicitly to extend cookies. There might be multiple situations when you need to use this tag to extend cookies, some most popular scenarios from my experience are:

• A native tag does not extend cookies. 

• Server cookies might be overridden by web tracking. 

• Server and web cookies have different names and standards. A great example here is GA. If you move to server-managed cookies it will create a new FPID cookie. FPID has a different format, name, and technology than GA web cookies. Besides, that FPID can’t be accessed by JavaScript. 

• Cross-site tracking using web-generated cookies. 

• Need to use web-generated cookies for user identification for other platforms. 

Multiple times we needed to extend cookies for platforms whose native tags cannot do so, like affiliate networks and email services. Or maybe you need to extend web cookies since server cookies, the ones with Httponly, can’t be accessed by JavaScript. And you can’t use these cookies in web GTM. Or maybe you need to use web GA-generated client ID format on other platforms. In all these situations, a Cookie extender can help.

Another common scenario is when you use web and server tracking, for example, for platforms like Facebook, TikTok, or Snap. Even if you extend fb cookies using a server tag, there might be scenarios when web cookies are set first. It means that server cookies and case Safari will still decrease. 

So how can you use Cookie extender tag? 

1. Download the Cookie extender tag from GitHub or add it using sGTM template Gallery. 

2. Import the Cookie extender tag to your sGTM tag templates. Go to the template sections in sGTM -> Click create a new tag -> Import the Cookie extender tag that you’ve downloaded from GitHub.

3. Create a Cookie extender tag in sGTM. I will extend Facebook (fbc, fbp) and Google Analytics (gid and ga) cookies in this example. In the tag settings, I’ve set cookie names and the lifetime to which these cookies need to be extended. 

I’ve also enabled a checkbox Create backup cookies and restore them in case main cookies are not found. This setting creates backup cookies, for example, for _ga, it will create _ga_backup and store there the same value as _ga. If you’ve set Cookie extender tag and enabled backup cookies, it will restore the _ga cookie from the backup cookie _ga_backup. It means that this user will still have the same cookies as they had during the first visits, even when _ga cookie was already erased. 

With the Facebook cookies  (fbc, fbp) different logic applies. Server FB CAPI tag sets cookies to 3 months. If you use both browser and server tracking for FB, then there are might be some cases when the FB pixel tag triggers first and sets a browser cookie whose lifetime in Safari (and other browsers with ITP) is 7 days maximum. In this case, cookies are not extended. To eliminate this issue we will trigger FB pixel tags only after the server FB tag has set cookies. 

4. Inside the web GTM container I want to modify a trigger for FB pixel events, as I need to set server cookies first. To do so I will use Data Tag/Data Client because these two have an option to send dataLayer push to the web GTM after server requests are completed. My idea is to trigger FB pixel only after the server FB CAPI tag worked, meaning that server cookies were set. 

To do so I will use Data Tag/Data Client to send data layer push to web GTM when the server received a response. 

My trigger for the FB pageview tag looks like this. It triggers on a custom event server_reponse, meaning that server requests were sent. 

5. Now you can test the Cookie extender tag using web and server GTM previews. Once you’ve verified that these works correctly I would suggest opening Safari (or any browser that limits cookie lifetime) and testing cookies. This is how cookies look for my setup.

Conclusion:Copy link to this section

With ITP's restrictions on cookies and other data collection so far, Safari has led the privacy crusade. However, other browsers have also started implementing anti-tracking mechanisms, including Chrome which has more than 50% of the browser market. 

Cookies have a considerable impact on campaign performance, attribution, conversion tracking, etc. That is why you might want to implement server-side tracking to extend the cookie lifetime. If you need help, just send an email to agency@stape.io.