How To Overcome GA4 Server-Side Tracking Challenges

For organizations seeking a competitive advantage in their data capture, learning about GA4’s server-side capabilities is just as important as learning GA4’s event model.

The deadline to deploy Google Analytics 4 is rapidly approaching. Google will sunset Universal Analytics in just two months on July 1, 2023 (If you’re paying for GA360, you get a one-time one year extension). Before migrating, it’s important to understand how the change will impact your business.

The most significant change from Universal Analytics to GA4 is its move to a modern event-based data model. This fundamental change deserves attention and requires education, but it’s important not to overlook another major change that could considerably impact your business: server-side tracking.

Universal Analytics collected server-side and client-side data for a wide variety of use cases, but GA4’s server-side tracking is less independent and requires support from client-side (browser) tracking to enable key use cases that you may rely on:

• Attribution
• Sessionization
• Geolocation
• Conversions for Google Ads Remarketing

Server-side tracking is more important than ever, but if it’s not implemented correctly in GA4, some of the capabilities you rely on won’t work as expected. In this post, we’ll explain why you need a hybrid deployment to get the most out of GA4, and we’ll show you how RudderStack’s GA4 integration solves hybrid implementation for you.

Benefits of server-side tracking

As the analytics landscape evolves, it’s getting more difficult to collect complete data for conversions and attribution. This is largely driven by two factors:

• Page speed - Each second delay in desktop or mobile page load was approximated to reduce conversion rates between 20-22% percent
• Ad blockers - Over 40% of people worldwide now use ad blockers

If you’re relying solely on client side tracking, it’s likely your conversion rate is suffering and you’re losing a significant amount of valuable data to ad blockers. Server-side tracking can help you stay competitive in the face of these challenges because it delivers:

• Faster website performance – server-side tracking reduces the amount of code required to load client-side, which can lead to dramatic improvements in page speed metrics.
• Ad blocker resiliency – Server-side tracking enables you to capture data in spite of ad blockers, so you can regain large volumes of data that were previously unavailable. (Note: it’s important to consult a legal team regarding gathering data in the presence of an ad blocker)

Perhaps most importantly, server-side tracking lets you own your first-party data capture. Rather than injecting third-party code throughout the site, you can send data server-side to command more granular control over what happens with the data.

With the benefits of server-side tracking established, next we’ll discuss how GA4 tracks server-side data and explain why this data collection often requires browser support.

Server-side tracking options for GA4

GA4 offers two options for server-side tracking: Google Tag Manager (GTM) Server-side or the GA4 Measurement Protocol API. We’ll detail both options and their limitations below.

Google Tag Manager server-side

GA4’s GTM server-side tagging is different from a web GTM container. It’s hosted on a server-side container (GCP or other), so it does move instrumentation off of the browser, but it comes with some critical limitations:

• It’s not ‘pure server-side’ without browser code because it still requires a web GTM container to send events to the server-side container
• Browser GA4 tags are used like a server-side data layer, and data is transformed to other tags (Facebook, Snapchat, etc.). Simo Ahava details this for GA4 data mapping to Facebook here. This data mapping can introduce extra points of failure for some sites. For example, if your web development team maintains GTM’s data layer for event tracking, GTM server-side cannot natively retrieve this data. Instead, GTM server-side retrieves data that passes through the GA4 tagging, which can introduce discrepancies compared to pulling from the raw data layer.

GA4 Measurement Protocol API

The measurement protocol API enables you to write code and send data directly to https://www.google-analytics.com/mp/collect. It’s an effective way to augment client-side data collection, and it’s actually the method RudderStack uses to send GA4 server-side data, but its standard implementation is problematic:

• GA4’s out-of-the-box attribution reporting does not support server-side data, it requires browser tracking.
• Google Ads remarketing requires browser tracking.
• Out-of-the-box geographic information requires browser tracking.
• Sessionization requires a session ID, client ID, and timestamp that fits within a particular session, and this implementation requires careful QA.
• Engineering a server-side client ID for anonymous users can require new development work for some businesses.

Currently, using only the Measurement Protocol API for data collection eliminates critical capabilities of GA4 reporting. GTM server-side tagging works around this because it still requires a web container or Google tag (gtag.js) coded in the site, but as noted, this approach comes with its own limitations. Google has even stated that server-side measurement for GA4 will “augment existing events” not serve as standalone data collection.

Because both server-side approaches come with significant drawbacks, most organizations will require a hybrid GA4 implementation that includes server-side tracking with support from browser code.

Architecting a hybrid deployment

Hybrid deployments use a combination of client-side and server-side tracking suited to an organization’s needs. Generally, a hybrid deployment would allow you to experience the best of both worlds while capturing a fuller set of information. Hybrid deployments deliver a number of key benefits:

• Attribution can be created and updated via browser code (GTM, gtag.js)
• Sessionization can be generated through browser code (GTM, gtag.js)
• Geolocation data can be captured through browser code (GTM, gtag.js)
• Conversions for Google Ads Remarketing can be captured through browser code (GTM, gtag.js)

For many companies, these benefits are non-negotiable because they enable capabilities their teams have come to rely on. There are some drawbacks to hybrid deployments, however, that should be considered. Hybrid deployments are more time consuming to set up, they do still require client-side code that affects performance, and they are partially susceptible to ad blockers.

Various hybrid deployment architectures

There are three primary ways to set up a hybrid deployment, and each option involves its own tradeoffs. We’ll illustrate this with a few examples below.

Option 1: Server-side with client-side as needed

This deployment uses server-side tracking everywhere that client-side tracking isn’t necessary for attribution, remarketing, or geolocation data. It has the least impact on client-side performance and reduces data loss from ad blockers, but it requires a significant organizational commitment to server-side tracking that necessitates training and upkeep.

Option 2: Server-side fallback for ad blockers

In this setup, server-side tracking is used only when a client-side ad blocker is detected. It reduces data loss from ad blockers but still involves client-side impacts on performance.

Option 3: Split server-side and client-side

Splitting server-side and client-side tracking runs both tracking methods in parallel. Data is deduplicated in reporting. When a matching client-side hit cannot be found for a particular server-side hit, then the positive impact of server-side performance is demonstrated.

This approach allows organizations to directly compare client-side data collection with server-side data collection, and because client-side tracking is still fully running, it provides you with more time to train your team and update server-side tracking. As you can gather, though, it requires reporting resources for de-duplication and still involves client-side impacts on performance.

Introducing RudderStack’s GA4 Hybrid Mode

If you’re overwhelmed by all of the options covered above, we get it, but you’re in luck. To help make the migration to GA4 a bit easier, RudderStack has launched a hybrid mode feature that productizes a one-step GA4 hybrid deployment.

Utilizing RudderStack’s GA4 Hybrid Mode, you have access to an implementation that actually does deliver the best of both worlds. You’ll get a fuller, more unified, and accurate set of attribution data with the least possible impact on front-end performance from a combination of client-side and server-side tracking. This feature follows the approach detailed above in option one – the server-side with client-side as needed option.

This feature also makes it easier to get a GA4 hybrid deployment up and running. With RudderStack’s integration, you don’t have to create two separate connections and then de-duplicate events via filtering and transformations. You can simply set up one connection and flip on hybrid mode. Check out the docs to learn more about how you can get started with RudderStack’s GA4 Hybrid Mode.

If you’re interested in Hybrid Mode and feel like you could use some extra help navigating the migration to GA4, reach out to me and the team at BlastX. We’ve already helped numerous companies with their implementations and would love to work with you.