In February 2022, the CNIL sent a shockwave through the marketing ecosystem by rendering Google Analytics, the world’s most widely used web analytics solution, illegal in France! A big wave of panic arises, and searches for an alternative solution multiply. Matomo, Piano Analytics, Piwik Pro, Eulerian? And what if the answer was to continue to use or migrate to Google Analytics 4? In a note dated July 20, 2022, the CNIL specifies a way to continue using Google’s analysis tool: proxyfication.
What is proxyfication?
The CNIL describes proxyfication as implementing a proxy server between the user’s terminal and Google Analytics servers. This is notably possible through the use of Google Tag Manager Server-Side. The requests usually sent directly to Google’s servers will be directed to a tracking-dedicated server hosted in Europe.
In a site without proxyfication, the Google Analytics request is directly sent to Google’s servers.
From this tracking server and the Google Tag Manager Server-Side interface, it will be possible to perform data transformations according to the CNIL’s directives.
What does the CNIL say?
To make use of Google Analytics 4 compliant, the CNIL imposes specific measures:
- No transfer of the IP address to Google Analytics servers.
- Pseudonymization of the user identifier.
- Removal of external referrer information from the site.
- Removal of any parameters contained in the collected URLs.
- Removal of the user_agent, which may contribute to fingerprinting.
- No collection of cross-site or deterministic identifiers.
- Removal of any other data that may lead to reidentification.
The above can be implemented with a Google Tag Manager Server-Side tracking installation.
Let’s now see how to put this into practice.
Proxyfying Google Analytics 4
First, ensure your Google Analytics tag sends the request to the server. To do this, check “Send to server container” and enter the URL of your tracking server.
From now on, every triggering of a Google Analytics 4 tag will generate a server-side event.
As a reminder, this server-side configuration does not exempt you from obtaining consent from your visitors. To learn more about configuring your CMP Axeptio on the server side, read this article (link to server-side and consent article).
Suppression of IP
Google Analytics systematically masks the last octet of each IP address, but this is insufficient in the eyes of the CNIL.
Fortunately, you can prevent it from being transferred to Google’s servers. To do this, choose “True” on the “Hide visitor IP address” option of the GA4 tag.
Pseudonymization of the user identifier
You are assigned a user identifier whenever you visit a site with Google Analytics. This is stored in a “_ga” cookie, which will be used to link your different sessions.
The CNIL tells us: “To ensure effective pseudonymization, the algorithm performing the replacement should ensure a sufficient collision level (that is, a sufficient probability that two different identifiers give an identical result after hashing) and have a variable time component (adding to the hashed data a value that changes over time so that the result of hashing is not always the same for the same identifier).”
We will carry out this action in 3 phases:
- The definition of a new cookie, with a lifespan of 30 minutes, is renewed with each user event. This “r_ga_token” cookie, therefore, has a session lifespan.
- Pseudonymization of the client_id and x_ga_js_client_id
- Creation of the “r_ga_token” cookie Start by importing the following variable template (put the link) in the Template section:
You can then create the variable and name it according to your naming convention:
This variable will create a new cookie r_ga_token (random value) if it does not exist or will return the cookie value if it exists.
Go to the tag template gallery and download the “Cookie Monster” template.
Create a tag using this template and select “Add cookie.”
Then set the cookie name as described and choose the previously created variable as the value. Finally, set for 30 minutes, or 1800 seconds.
Finally, use the following trigger:
Thanks to this, the cookie will be extended by 30 minutes with each event the user performs.
Here we can see that the cookie was created during my first visit…
Pseudonymization of client_id and x_ga_js_client_id
Now that the random identifier is created, we will replace, and thus pseudonymize, the two parameters used to identify a visitor: the x-ga-js_client_id and the client_id.
We will again go to the Template section to use a variable template created by the Addingwell team.
- Give a name to the variable
- Go to “Fields” and select “Text input.”
- Go to the gear icon and select “Validation rule.”
- Fill in the fields as shown below
Go to the code section and insert the following code:
const getCookieValues = require("getCookieValues");
const sha256Sync = require('sha256Sync');
const math = require("Math");
const key = getCookieValues('r_ga_token')[0];
return sha256Sync(data.Input + '.' + key, {outputEncoding: 'hex'});
Finally, grant authorization so that the API can read the r_ga_token cookie.
The code indicates that the variable is hashed and corresponds to the concatenation between the input (which we define below) and the “r_ga_token” cookie. The user’s unique identifier will expire 30 minutes after their last action (i.e., at the end of their session).
We now enter the final phase of this user identifier pseudonymization mission. We need to create the variables that will replace the values natively in place.
Let’s start by configuring two “Event Data” variables that will capture the values of the client_id and the x-ga-js_client_id.
Let’s now use our previously created variable template to replace the values of these two variables.
The variables are created, pseudonymized, and hashed; now, we need to send them as replacements for the default ones.
To do this, return to the Google Analytics 4 tag and add the following two fields under “Parameters to add/modify.”
Removal of the referrer domain
The CNIL then requests to remove the referring domain link if it is external to the site. Indeed, we will want to keep the flow of the user’s pages on our site. It will therefore be necessary to distinguish between incoming links.
To begin, create an “Event Data” type variable to capture the value of the page_referrer.
From the value of this variable, we will want to distinguish between internal and external referring domains. To do this, add the URL Parser variable template to your space.
Then select our “Event Data – page_referrer” variable as the URL Source and choose Host Name from the drop-down list to highlight only the domain name.
We now need to create our proxy filed page_referrer variable. Either the domain is internal, and we will send the referring URL to GA4, or it is external, and we will send an undefined field.
To do this, create a “Lookup Table” variable and select the filtered URL by domain as the input variable.
Then enter your domain name(s) as input, with the output being the page_referrer variable. Finally, check “Set the default value” while leaving its content empty.
All that remains is to add a new page_referrer parameter to the GA4 tag, as shown below.
Removal of URL parameters
In its documentation, CNIL requires the removal of all URL parameters. This means that UTMs must be filtered before being transferred to GA4 and parameters such as gclid (Google Ads) or fbclid (Meta Ads).
Note that by removing the external referrer domain and URL parameters, Google Analytics will no longer be able to determine your acquisition sources. CNIL establishes this data as personal.
To remove these parameters, we will add a new variable template coded by Addingwell.
Name the template “Page Location” in the Information section and insert this code in the appropriate section.
const getEventData = require(‘getEventData’); const parseUrl = require(‘parseUrl’);
const parsedUrl = parseUrl(getEventData(‘page_location’)); if (!parsedUrl) return;
return parsedUrl.protocol + ‘//’ + parsedUrl.hostname + parsedUrl.pathname;
Finally, select “All” as the event data reader authorization.
Save the template and create a variable from it. You do not have any parameters to specify here.
Then go back to the GA4 tag to add this variable as the value of the page_location parameter.
Removal of the user_agent
The user_agent parameter corresponds to the technical characteristics of the device on which the user visits your site, both from a hardware and software point of view.
By crossing this data, Google could do fingerprinting and thus uniquely identify a user. Can’t believe it? You can check the uniqueness of your configuration with the AmIUnique website.
When returning to our GA4 tag, we will add the user_agent parameter and the screen_resolution, which provides information about the user’s screen size, as excluded parameters.
Absence of any cross-site or deterministic identifier collection
After implementing technical settings to block information, the following two sections discuss tracking elements that should not be implemented.
Cross-site tracking
If you have multiple sites on distinct domains, cross-domain tracking cannot be used to track a user’s activity as they move from one place to another. This option is made impossible anyway by the removal of URL parameters. Cross-domain tracking works with URL decoration.
Deterministic identifier
The user_id parameter is regularly used to add an identifier specific to your database or CRM that will persist over time. This would allow the multi-session activity of the user to be tracked. That is why you cannot implement it if you want to comply with CNIL directives.
Removal of any other data that could lead to reidentification
You must not transmit data such as your user’s phone number, email address, or name. Also, these data are useless to Google Analytics, whether hashed or not. Here, you have nothing to filter; just be careful not to send this data with your tag manually.
Conclusion
The proxyfication process is mandatory if you want to continue using Google Analytics 4 while complying with the law.
This article allows you to implement this process step by step.
