The Marketing Technologist.

We talk about analytics, code, data science and everything related to marketing technology. Backed by the tech geeks of Greenhouse.

Setting up Google Analytics with an HttpOnly cookie

With privacy protection on the rise, the stability of client-side cookie is in jeopardy. The life-time of Google Analytics‘ client id cookie ranges from a day in the most strict scenario to two full years in the best possible scenario. Because of this, you may want to setup a test where you track users based on a HttpOnly cookie. In this post, I’ll share how you can set up such a test.

Server-side to the rescue

While privacy protection has its impact on client-side cookies, it cannot impact HttpOnly cookies. This opens up an opportunity for Google Analytics:

If we set a client id-like HttpOnly cookie, we can use that as a client id for Google Analytics.

In a test on a personal website, I have a setup like that running.  I first set up a cookie that mimics Google Analytics’ client id cookie: it is stored for two years, and the expiration date is updated every time a user visits the website.

Keep in mind that the browser cannot access HttpOnly  cookies, and because of that  your client-side analytics can’t either. So besides setting a HttpOnly  cookie, you will need expose the HttpOnly cookie on the client-side. The data layer is a good place for this.

{
	"event":"client data",
	"internal_traffic":"no",
	"server_client_id":"76f80ee3-ae69-497e-bbcd-4acebc9ccfb0"
}
Example of HttpOnly cookie exposed in client-side data layer.

How to set a custom client id for Google Analytics

This is the interesting part. When you want to test a setup like this, I would strongly recommend testing it against a regular tracker. There are two settings you will need to configure to test the secondary tracker:

  1. Overwrite the client id: the first thing is obvious. Set the clientId field to the value of your server-side client id (the HttpOnly  cookie). In my example, this is the data layer value server_client_id.
  2. Disable storage: the second thing is not so obvious. Set the storage field to none. This makes sure that Google Analytics won’t store the id in the client-side cookie.  It won’t be a problem as we manage the value server-side. If you do not set this field, it will store it in the Google Analytics cookie, overwriting the existing value for the existing tracker as well!

With these two value set, you are ready for your test.

Comparing the data

With the setup ready, the values you will want to review are those impacted by user recognition (e.g. new users and direct sessions). Keep in mind that the existing tracker already has historical data. Because of that, it already has 2 years of data that it can use to recognize users and 6 months of campaign data to attribute to sessions. Instead of waiting 6 to 24 months for the effect to wear out, you may want to add a new generic Google Analytics tracker.

Enjoy making the comparison!