Server-side GTM for Mobile Apps:

Introduction

It's been a while since we've eagerly awaited a new technology from Google. One of the most anticipated is sGTM (Server-side Google Tag Manager) for mobile apps. Unlike the web, implementing customizations and interventions in mobile apps is far more complex and often requires outsourcing to external companies. Each change or update can take weeks, even months, to implement.

As for GTM in mobile apps? Well, it wasn’t exactly usable on its own, and the wait for a replacement felt never-ending.

So, where do we stand today? Has sGTM truly improved mobile app analytics? Can it reduce client costs and development time? Does the value outweigh the operational costs? These were the questions our colleague Dan asked as he put sGTM to the test. Let’s dive in.

A Brief History

Before jumping into sGTM, it's important to take a quick look at the evolution of mobile analytics—especially Firebase and GA4—and the role GTM played in this space.

If you're only here for the latest on sGTM, feel free to skip to the section titled sGTM for Mobile Apps.

Google Analytics and Mobile Apps

Universal Analytics for Mobile Apps

When I first began learning analytics, the transition to Web+App had already started, so my experience with Universal Analytics for mobile apps was mostly theoretical. The original SDK for mobile apps under Universal Analytics was far from ideal, especially as mobile platforms and frameworks evolved. It became clear that a more modern approach was needed.

The Birth of App+Web Analytics

In 2017, when I joined Optimics, Google was experimenting with Web+App, a new analytics structure that wasn’t widely adopted at first. However, after several iterations, Web+App evolved into Firebase, a tool that aligned better with the fast-paced growth of mobile app development.

Firebase Analytics

Firebase Analytics represented a significant shift—it focused on user interactions rather than just app performance, treating everything as an event. This was a big departure from Universal Analytics, where events were just one of many metrics. For me, Firebase's event-based model made much more sense for tracking user activity in apps. However, it was a tough sell for many who were used to the old Universal Analytics framework.

GA4: A Unified Approach

As the years passed, Google introduced GA4, marking the end of Universal Analytics. This was inevitable given how web and app landscapes had changed—from static, predefined web pages to dynamic, user-driven experiences. GA4 represented a more flexible approach to tracking, which better suited the needs of modern websites and apps.

GTM for Mobile Platforms

Google Tag Manager (GTM) is a beloved tool for managing web analytics. It allows us to respond to site events without involving the development team, saving time and effort. But mobile apps presented a different challenge.

Legacy GTM for Mobile

The original GTM for mobile apps was built on the Universal Analytics SDK. With the transition to Firebase and GA4, the old mobile GTM became increasingly difficult to use. Unlike web-based GTM, changes in mobile apps required development involvement, meaning each update had to be deployed with a new app version. In the end, it became a cumbersome and inefficient solution for managing mobile analytics.

Updated GTM for Mobile

The updated version of mobile GTM was released just before the introduction of sGTM. While we haven’t explored it in depth yet, it's clear that it was designed to work alongside sGTM. We’ll dive into this in a separate article.

sGTM for Mobile Apps

Now that we’ve covered the history, let's explore what sGTM for mobile apps brings to the table.

Expectations

We had high hopes for sGTM for mobile apps, expecting it to provide:

1. The ability to modify events in near real-time, adding or removing data as needed.

2. Easy configuration for sending data from one GA4 property to another.

3. Seamless integration with external platforms without the need for app development intervention.

4. The ability to respond to specific events, like triggering Google Cloud Platform tasks.

5. A simple debug environment for users without deep technical knowledge.

Test Results

We tested the most important features, particularly those outlined above. Here's how they performed:

• Event modification and enrichment: Works flawlessly, just like in web analytics. A big win.

• Connecting to external tools: No major changes here. The setup mirrors web analytics, which simplifies things.

• GCP cloud task triggers: Successfully triggered events using HTTP requests.

• Analytics management without dev team involvement: This is where things get tricky. While some processes can be streamlined, app deployment still requires developer involvement. Unlike the web, where updates are instant, it can take months for users to transition to a new app version. However, sGTM does allow for quicker fixes while waiting for a full app update.

• Debug environment: Setting up the debug environment is user-friendly but has some technical hurdles. For instance, during my first test, I encountered issues with application IDs, particularly those containing underscores, which caused errors in the preview mode:

"Enter your Application ID" – If one is not familiar with mobile apps and does not know the format that is given as an example there can be communication noise between the analyst and the developer. Because "Application ID" can be basically anything. I would appreciate a small breakdown in the documentation so that there is no doubt about what is expected in this field.

That, however, aside from confusion, is not the worst thing. In my first test, I took my app published on the Google Store and tried to debug it. However, to my surprise I got the following response:

And suddenly I started to doubt this "Application ID". Is it something else? Is it some ID that is directly linked to sGTM? So what is the correct format?

So I tried the Bundle ID for the iOS app and It was already at peace with that one:

So the problem was the underscore "_", but it is a valid character for the Andorid package name. I can't edit the URL or somehow else pass it to him (at least I couldn't). This could be a pretty strong hit for some apps, because so far it looks like you just won't run previews for an app that has that name. Speaking for myself, I would say that the documentation is not up to the standard that Google is trying to hold itself to. It's ambiguous in some places, lacking an explanation or a link to documentation that further describes the technical specification, but here I assume there will be improvements and clarifications after the next few weeks.

 So an easy debug environment? To use, yes. On implementation? Not really.

Configuration Limitations

One notable limitation is the inability to easily send data from one GA4 property to another. While some clients may rely on this functionality for unified reporting, sGTM doesn’t support it. Instead, custom solutions, like using the measurement protocol, are required.

Android and iOS Limitations

Despite the rather problematic configuration of the Preview mode, the functional limitations do not manifest themselves and it is only necessary to observe the limitations that Google mentions in the documentation, which are:

Android Restrictions:

1. Proxy Server for Security: "To avoid potential security vulnerabilities involving server containers and Google Play services, events will go through a stateless proxy server in between the SDK and your server container. This proxy will validate the source and endpoint of the request, but it won't inspect or store any data about the events. Consistent with how GA4 collects data from EU-based devices, the proxy will be in the EU for EU-based traffic."
   I view this as more of an informational note than a limitation. What concerns me, however, is that this proxy process applies only to Android. It raises the question: is there an equivalent service between the iOS SDK and the server container, or is iOS traffic unaffected by this flow?

2. In-app Purchases Not Sent to Server Container: "Automatically logged in-app purchases rely on integration with Google Play backend and won't be sent to the server container."
   This could be a limitation if you're aiming to enrich in-app purchase events using sGTM. However, for most clients implementing custom event purchases, this won't be an issue. Nonetheless, it's critical to inform clients of this restriction if it might affect their setup.

3. Missing app_remove Event: "The app_remove event won't be reported on Android."
   This could present a problem if your reports track app removal statistics. Clients relying on this event should be notified that they will no longer be able to capture it.

Android and iOS Restrictions:

Connecting Google Analytics Data to Google Ads: "Connecting your app data streams in Google Analytics to your Google Ads account is still necessary to ensure that your SDK data and conversions are imported into Google Ads. Server-side tagging does not offer any inherent integration between your SDK and Google Ads."
This is another informational note. It clarifies that sGTM does not handle the actual integration between GA4 and Google Ads. This doesn’t mean you can't post data to the Google Ads API using sGTM—it just won't handle the GA4-to-Google Ads connection directly. This setup is consistent with the web platform and applies similarly to mobile.

Conclusion

Overall, sGTM for mobile apps meets most of our expectations and provides a much-needed improvement for mobile analytics. While it still has rough edges, such as limitations in the debug environment and the inability to send data across GA4 properties, it offers valuable features that help bridge the gap between mobile and web analytics.

With further refinements in documentation and implementation processes, sGTM could become a core tool for mobile app analytics, giving analysts more control and flexibility without heavily relying on developers. For now, it’s a promising step forward, and we’re excited to implement it for our clients.

In short, sGTM for mobile apps gets our green light, and we look forward to seeing it evolve even further.

If you want to learn more about this topic, feel free to reach out to your favourite online measurement company. ❤️