How to set up cookieless analytics

Privacy & Analytics in 2021 Series–Part 2

This month, One North is putting out a content series on Data Privacy and Analytics that focuses on changes in guidelines and regulations, their effects on digital analytics and new ideas for maintaining compliance while still getting valuable information to better serve your audience.

In the first article in our Privacy and Analytics series, we discussed how the latest guidance on GDPR is causing some companies to move to an opt-in model–even for their basic web analytics–for European users, meaning they are not tracking any analytics unless a visitor explicitly grants them permission. Firms following this method have recorded as much as 90% traffic declines.

One way to still capture some traffic and event information while still complying with this interpretation of GDPR would be to implement a cookieless version of Google Analytics to run alongside your regular implementation. In this article, we’ll walk you through how to set this up and how it looks in your analytics.

What cookieless GA accomplishes

Google Analytics uses cookies to track users across pages and sessions, assigning each user a unique ID called the “Client ID.” Common, popular metrics in Google Analytics like Users and Sessions rely on the Client ID to work. It allows Google to group sets of pageviews together in a session and assign it to a user.

Beyond pages viewed, it is extremely helpful to know how many actual users visited your site. But some interpret the use of this unique ID to be at odds with regulations like GDPR because it can be used to profile a user. Removing the cookie allows us to still understand how often website pages are being viewed and events are being fired without building this profile.

One important thing to note–this is currently only possible on Universal Analytics. Google Analytics 4 does not yet have this capability.

Setting up cookieless analytics

Fortunately, this is fairly easy. Google has provided guidance on how to accomplish it, and we will show you how to do this quickly with a Google Tag Manager setup.

First, go to your Google Tag Manager container and click on the Variables tab.

Go to your Google Analytics variable (if you don’t have one yet, follow these instructions), and expand the More Settings > Fields to Set section.

Add a new field with ‘Field Name’ set to “storage” and ‘Value’ to “none.” That’s it. If you save and publish, you will no longer have the _ga cookie stored on your users’ browsers, and the JavaScript will fire upon page load.

If you want to go an extra step, set a field with the name “anonymizeIp” to “true” to deprecate the IP and prevent Google from performing a reverse IP lookup for things like location with the user’s full IP address.

Reporting with a cookieless setup

I recommend creating a separate Account (different GA Tracking ID than your main account) for your cookieless setup, and have it run concurrently. This will allow you to have the cookieless view to get the authentic pageviews and events, but still collect some real User and Session data.

As you will see, the cookieless view is extremely limited in some cases.

The Audience view is a good first place to go to get used to what works and what doesn’t, mainly answering the latter.

As you can see, without a cookie, it believes every pageview is a new user and a new session, and that every session is just one pageview. Bounce rate? Session duration? Incalculable without that cookie.

However, here is what you do get, which you cannot get when dealing with opt-in: an accurate view of how often your pages were viewed by a device:

Events will also fire, so if you want to know how often a PDF was downloaded, or how often a CTA was clicked, you can still find that info.

Those are the explicit, best uses with a cookieless set-up–great for having as verification or backup against what could be a limited view due to cookie policy.

But there are some additional pieces of info.

Channels – You will still know whether the user came immediately from Google search page or another website. What you can’t really know is what percentage of the sessions are being delivered from particular places, as we don’t know sessions without cookies.

Devices, screen resolution and location are all still stored. But it paints an approximate picture, since you cannot know how many pageviews were from a single user, just total pageviews from a phone type or location.

Setting your own Client ID

Maybe you don’t have concerns about creating a general session ID, but you feel that Google Analytics Client ID is a problem. The good news is you can set your own Client ID using Google Tag Manager if you have a development team that can fire a unique session ID into the data layer.

Back in Tag Manager, open up the Google Analytics variable again and expand Fields to Set.

This time, write in the Field Name of “clientId” and for Value, select the variable tied to your new session ID (you will likely need a developer’s help to push this ID into the data layer). You may already have a native website cookie with a unique value you can use and tie into a Variable. My variable was named SS Visit, so I could use a Squarespace cookie already on site.

Now, the Client ID will be set with the value of this Cookie every pageview, which will be consistent across each page of a session.

You now have a bit better reporting visibility.

Eureka! More pageviews than sessions!

Every session is a new user, but we do get to see how many pageviews per session (my fake website does not have very high engagement). Session duration will actually not come through well, even with this setup, but bounce rate should work. Channel traffic is also more reliable.

If your firm starts moving to an opt-in model for web analytics, I highly recommend creating a backup view like this to have some visibility into traffic. As we will see as the series continues, things are only going to get more restrictive, but there are also more opportunities that arise from taking more control of your data.