The Future of Analytics and the Cookie Apocalypse: Cookieless Tracking and Server Side Implementations

by | May 15, 2022 | Google Analytics, Google Tag Manager | 0 comments

When GA4 had its beta debut in 2020 it introduced significant challenges hindering migration / updating to the platform. The cross-overs with Universal Analytics (GA3) were fairly loose.


  • Standard reports that everyone is used to are not pre-built – analysts found work arounds with a combination of BigQuery and DataStudio. For the most part though, marketing teams can’t just switch and maintain reporting continuity.
  • The concept of Sessions and Bounce Rate didn’t exist.
  • There were no filtering possibilities in the actual platform – some level of filters could be achieved via manipulating hit data in Google Tag Manager.
  • The UI and terminology is significantly different Universal Analytics and a learning curve in itself.
  • It wasn’t an updated version of Google Analytics, but a brand new platform with a brand new tracking methodology underpinning it.

Adoption is definitely taking its time, mainly for the reasons mentioned above.

Although there has been some hype around needing to migrate to GA4 because of the sunset of Universal Analytics being announced for 1st July 2023, I have been hesitant to recommend fully switching platforms.

Dual tagged implementations are desirable with the caveat that GA4 is not a full featured platform, but it is good to get a head start with it.

Google Analytics Cookies and GDPR Compliance

Google Analytics stores data in a 1st party cookie (_ga) including unique identifiers such as client ID and session ID, which are used to tie data to a particular session and user. The GA tracking script can continue to pull data from the browser without the cookie, but recording data without assigning a session ID or client ID on each pageview.

Given that the tracking methodology Universal Analytics is built on is Session and User based, this is a huge problem.

In a nutshell cookieless tracking is horrible for GA, Consent Mode and GDPR plugins that block cookies pre-consent but let analytics.js run are something to be avoided for GA3/UA – they make a mess of the data.

The concept of Sessions and Users becomes redundant and will be reset on every pageview.

This means you will still get acquisition data for that first pageview, but for the visitors that don’t opt in, the session resets and becomes Direct on every consecutive pageview. Conversion attribution will be lost to Direct on those Sessions.

Respecting consent isn’t the issue – cookieless tracking is. I’d recommend that you only deploy tracking scripts on opt-in rather than blocking cookies mixing messy data with the optimally collected data i.e. only inject the GTM container or Analytics javascript on opt-in.

I have seen sites lose up to a 3rd of their data / Session count by becoming compliant, but that is better than the skewed data cookieless tracking will give you.

Some GDPR plugins integrate with GTM by producing a dataLayer that outputs the consent status the user selected. This can be used as a trigger condition for all tracking and remarketing tags in a GTM container.

Googles Consent Mode is still in beta, but it was designed for GA4. Adswerve have done some tests to monitor how Consent Mode affects the recording of data in UA and GA4.

The main concern is that CM does not guarantee GDPR compliance and can be deceptive i.e. User Ids are still logged in BigQuery and it sends “anonymous” data to GA4 for “modeling” purposes even if the user declines cookies.

As always, ensuring GDPR compliance is something that should be advised by your legal team. It is always better to err on the side of caution, especially with GA being made illegal in France recently.

Server Side Tracking

Data loss incurred by the cookie apocalypse has been blamed for the increase in cost per acquisition on ppc campaigns. Server-side tracking (for GA4, UA, Google Ads, etc.) and the Facebook conversion API are combative against the cookie issue.

Server side GA4 is a server to server data collection solution (as opposed to browser to server).

It is comparable to what the Facebook Conversions API is to Facebook’s browser Pixel.


  • Reduced load on a page (site speed benefits)
  • Control what kind of data is sent to vendors via sGTM (i.e. ability to filter/edit cookies, fingerprinting, any data that might be considered PII)
  • Extend the cookie expiration on Safari (ITP) from 7 days to 2 years
  • Reduce the impact of ad blockers


  • Server is an extra on-going cost – $120/month+ based on bandwidth/usage.

Server Side tracking isn’t actually new – Adobe Analytics and and other tag managers like Tealium have been server side for a long time already, but they are premium priced products.




Submit a Comment

Your email address will not be published. Required fields are marked *