With stricter privacy regulations and the phase-out of third-party cookies, traditional tracking in Google Analytics is becoming ineffective. GA4 still relies on cookies by default, despite its privacy-first design. To collect accurate data in GA4 without cookies, it should be implemented using server-side tracking.
Websites traditionally use cookies to track user actions, like saving cart items or recording ad clicks. But with growing privacy concerns, many are shifting to cookieless tracking.
Cookieless tracking relies on first-party data instead of browser-stored cookies. The most reliable way to implement this is through server-side tracking. This not only helps to get rid of cookies and make tracking more accurate but also makes it more compliant and has greater control over the user data.
Google Analytics 4 uses machine learning to model the behavior of users who did not consent to analytics cookies. They use the behavior of similar users who allowed consent to analytics cookies to model the behavior of those who did not agree to analytics cookies.
To be eligible for machine learning, GA4 property should meet specific:
If your GA4 property doesn't qualify for machine learning or if you discover that machine learning isn't providing accurate results, you have the option to rely on first-party data when a user opts out of analytics cookies and implement cookieless GA4 tracking.
To make GA4 work correctly and recognize users who come back, you have to provide GA4 with the following information:
To set up cookieless GA4 tracking when a user hasn't given consent, we'll use these tools:
To determine if consent was granted or not, we use the gcs parameter. The default GA4 consent configuration sends requests to sGTM, but the request lacks some information. All GA4 requests are written to the Firestore.
To determine if a user without consent has an active session in GA4, we will use the difference in the timestamp of the previous visit vs the current visit. If the difference is more than 30 minutes, we will update the session parameters in Firestore.
Firestore will use the UserID as the document name and save details about the user session within these documents. While this is a straightforward way to organize Firestore, there are numerous other approaches to maintain data about the complete user experience in Firebase.
1.2 If needed, write data to Firestore. For this purpose, we use the Firestore Writer tag. Please check this detailed guide on how to use the Firestore Writer tag. We use the collection UserID. For each user ID, we create a new document that uses cid as a document name.
1.3 The GA4 server-side tag has a standard configuration and triggers every time the GA4 client is claimed, and the user consents to analytics cookies.
2.1.1 If consent to analytics cookies was not granted, we used Stape User ID power-up to add user ID in sGTM request headers.
2.1.2 With the help of the Firestore Writer tag, we write data to Firestore and use Stape User ID as a document name.
2.1.3 To check that the session is active, we use the Firestore Reader variable to extract the timestamp that is associated with the last visit of this user in the Firebase. Then, check the difference between the user's previous session timestamp and the current timestamp. If the timestamp is less than 30 minutes, the user has an existing session.
2.1.4 Parameters are updated like below:
2.1.5 Send modified data to GA4. To update data before sending it to GA4, we use transformation.
2.2.1 If consent to analytics cookies was not granted, we used Stape User ID power-up to add user ID in sGTM request headers.
2.2.2 Write user data based on Stape User ID in Firestore again with the help of the Firestore Writer tag.
2.2.3 To check that the session is active, we use the Firestore Reader variable to extract the timestamp associated with this user in the Firebase. Then, check the difference between the user’s last session timestamp and the current timestamp. If the timestamp is more than 30 minutes, a new session has started.
2.2.4 Parameters are updated like below:
2.2.5 Send modified data to GA4. To update data before sending it to GA4, we use transformation. Tag triggers when a GA4 client is claimed, consent is not granted, and the time difference between sessions is more than 30 minutes.
2.3.1. When analytics cookies are not allowed, use Stape’s User ID power-up to generate a user ID.
2.3.2. Check if a user with the same UserID already exists in Firestore. If no user with the same user ID is found, use a Firestore Writer tag to create a user with session details in the database.
2.3.3 Parameters are updated like below:
2.3.4 Send modified data to GA4.
Implementing cookieless Google Analytics 4 tracking through server Google Tag Manager represents a significant step forward in adapting to the changing landscape of online data privacy and user preferences. As the digital world evolves, gathering valuable insights without relying on cookies becomes essential.
By using the power of server-side tracking and Google Tag Manager, businesses can maintain their commitment to data privacy while still harnessing the crucial data-driven insights provided by GA4. This approach not only ensures compliance with emerging regulations but also fosters trust with users concerned about their online privacy. As we navigate the cookieless future, embracing innovative solutions like server-side tracking and GA4 can help businesses stay competitive and relevant digitally.
We are happy to hear that! Click on Try for free to register and check all the possibilities.
Subscribe for updates:
we don’t spam!
Ira has 10+ years of digital marketing experience, with the last 5 focused on server-side tracking. She understands how and when it works across various digital marketing scenarios.
Comments