In this 25-minute MeasureSummit talk, Benoit Weber walks through one of the most technically demanding analytics projects he’s led to date — the full-scale migration of a Vietnamese e-commerce company from a disjointed client-side setup to a consolidated, privacy-compliant, performance-oriented server-side tracking architecture.
This isn’t theory — it’s a detailed, step-by-step breakdown of a real-world implementation using:
- Stape.io for server-side GTM hosting
- GA4 and Firebase for analytics
- Measurement Protocol for app + backend events
- Haravan and other multi-stream platforms
If you’re dealing with unreliable data, QA issues, PII compliance risks, or overwhelmed dev teams, this talk offers a practical blueprint for navigating server-side complexity at scale.
What You’ll Learn
- Why server-side tracking is worth the effort — and when it isn’t
- How to untangle years of legacy tracking setup across web, apps, and backend services
- What tools and integrations (like Firebase’s native GA4 support and Stape SDKs) can simplify implementation
- The real blockers Benoit faced: tight timelines, fragmented teams, misunderstood requirements, and app QA pain
- Lessons learned about training, stakeholder alignment, peer validation, and keeping it simple
Watch Now
Full Transcript
Hello, everyone. Thanks for joining this session. Today, we’re going to talk about server-side tracking. I’ve been attending Measure Summit for years now. So I’m very happy I can participate to the event this year. And I hope that you will enjoy this session.
Today’s session is about updating the digital mainframe. What we going to cover today is, we’re going to start with a quick introduction of the client and their requirements. We’re going to look at the outdated circuits. So the setup that they had for their tracking. We’re going to run through the blueprints for the new digital core. Which are the “why we would want server-side” and how it’s going to work.
We’re going to introduce the team who was involved in that project. We’re going to run through the plan. How we tackle this and how this sort of projects are working. We’re going to talk about the different blockers or challenges that we had. We’re going to finish with the results, the new digital paradigm.
And then we’re going to, I’m going to share with you some of the learnings. Now, if you have any questions, feel free to contact me directly. I would be happy to share with you extra information or content if needed.
Now, before we jump into the presentation, just a bit about me. So my name is Ben. I’m French. As you can hear. I’m based in northern Vietnam close to the border with China. And I’m working as head of analytics. At In Marketing We Trust. So I’m responsible for anything that touches digital analytics or governance dashboarding , reporting, implementation. datawarehouse and privacy in general. When I’m not talking (about GTM) or implementing things. I like to take my motorbike and my dog and ride in the mountains around my place. And you can see here, this is where, am actually living.
Let’s start the journey and let me present to you the client and what were the requirements? The client in six points. So this client is a Vietnamese company. They are e-commerce. They are selling clothes and accessories online. They came to us because they had a system in place for their tracking. But, they had some challenges when it comes to setting up the tracking for their website and their apps. They’re also using the measurement protocol. They have two apps, one for iOS, one for Android. And they really emphasised on the fact that they needed technical support… and, guidance when it comes to server-side tracking. What they wanted in terms of deliverables… and this is not the whole list, but that’s the five main deliverables… that this project was including and that they wanted. The first one is the clear project plan. So making sure that we know the timeline, the teams that are required, potential risk. We needed also to put together the tagging strategy. How are we going to make that migration happen from client-side to server-side. We needed to consolidate everything in one streamlined process. We wanted to have the server-side implementation itself. So implementing the clients, the different tags for GA, Facebook and TikTok. And then testing reports so wanted to make sure that we also included QA. Especially around the apps and then training materials and maintenance guides. This is something that we include in all our projects.
Now let’s look at the outdated circuits. What were their original setups? When we started the project? So this is an overview view of the whole data collection system that they had in place. As you can see, they have multiple streams. And I’m just going to run through each of the streams and explain you what it does and how it works. Now you have to understand that this is the results of years. This is also the result of multiple teams that were involved. Not necessarily guided by, one person, that was overlooking the overall architecture. So at the top, we have the web stream… which is pretty standard, where we have the websites… they implemented dataLayers is for the most important events. They had e-commerce setup. They had the standards GTM container that was installed in the pages. And initially they had only that container that was sending information to Google Ads, Facebook and GA.
Now with the recent release of the Facebook conversion API, they wanted to set up some conversion s in the server-side. So, which is why they also had GA4 sending requests to their server-side container, which was, triggering conversions, conversion API sending information to Facebook. Now you had also the two apps streams, Android stream, and then iOS stream, that were very also standards. They had Firebase analytics installed in there, which integrates natively with Google Analytics. Only information from Firebase Analytics was directly sent to the property. Now you can see they have two other streams. One is our Haravan server, which is their e-commerce platform. They had to implement that because…. they noticed that not all the purchase events that were happening on the website were actually tracked in GA4. So what they’ve done is on the server… when those purchases happen…. instead of just relying on the user browser to collect data… they wanted to send from the server to Google Analytics using the measurement protocol. And then for the apps… because you can see on the app streams, they had only the Firebase Analytics.
What they implemented is at an app server level, they had a solution called square… that was enabling them to send information to a server-side container… which once again, had conversion API tags for Facebook to be able to track purchase. So you can see it’s quite a complex system. It had a lot of different streams involved. And it’s the result of years of implementation. Let’s go now into the blueprints of the new setup that we want to do. Why do we want server-side and what is actually server-side and what it means? There are a few advantages, benefits of using server-side. And you may have read about those in different articles, even Google is promoting it. So it helps with governance and helps with the accuracy, you have better control of your data. So you therefore enhance the privacy. Because you have less tags on your own GTM container client-side, it’s going to improve the site performance… Now I find it quite challenging to promote server-side to clients that are not of a certain maturity. So when I’m proposing with my current client retainers or things like this of migrating to the server-side. The “pros versus the cons” really depends based on who you are talking to and how much they know about data. I found server-side a complex and quite technical subject to cover with clients.
Now, how does the whole tracking work then. Now what we are adding when we talk we’re going to implement server-side… you are adding a new layer in your measurement. So what’s happening is that you keep the client-side. So we still have the websites that load the GTM container. The only difference is that in our GTM container, we’re going to only have specific tags. In that case, it’s actually GA4 tags that are going to send data to our server-side container URL. So that’s going to be HTTP requests that the server-side container is receiving. In the server-side container, you have what we call the client. So the client is going to digest, transform, parse data that is receiving from the client-side container. It’s gonna translate it and basically you will be able to access that data through variables. And then based on specific conditions… you will be able to trigger your tag that will take that data from those variables… and send it to the different end-points that you have. So it could be GA4, it could be Meta, it could be GMP. Now, more and more platforms are supporting server-side… so it makes it easier for us to have all our platform tags in the server-side. And the client-side container will only have those GA4 tags.
Now for measurement protocol, for instance, you could have directly your server sending the request to the server-side. For mobile app that could have, in this visualisation, it’s tag manager… but in our instance, and we’re going to look at it later, it was Stape. io. Now for this sort of project… the type of team or people that are involved in this project… is quite different from any other, standard, more standard implementation projects. So this is the actual setup. So for this project, we had on our end, an account manager and then myself… who was the person, doing the design, the implementation and everything. On their end, you can see that there were quite a lot of people involved. And this is due to the complexity of their system… and the number of streams that we were dealing with. Basically we had to deal with the people that are responsible for the development of the apps… the person that is responsible for e-commerce… the data engineer specialist that is responsible for the overall architecture… the digital marketing manager, because it’s going to impact him, obviously. So the complexity of server-side is not only from a technology perspective… but also from a team perspective… because you will have not only to deal with your main point of contact… but also with the different dev teams for all the streams that you are working on.
Now, what was the master plan? What, what we wanted to do and how we’re going to achieve it. So there were three main objectives for this project. First one was to actually set the foundation, making sure that we have a proper setup in GA4. We have proper setting in Google Tag Manager, both client-side and server-side. And we make sure that the data collection for the apps and the server are actually streamlined into one framework, which is Stape.io.
We’re going to come back to that a bit later. You have the consolidation of the tag management. So you could see we had different streams, different containers, we have different teams even managing it. So really the idea here is to consolidate. And then the last point is the minimisation of risk. And in that case, it’s because we realised that PII was being collected in the GA4 property. So PII, personal identifiable information. This is against Google policy. So usually when it happens, I recommend, having a new property starting from scratch. And especially in that case where we work so much on the measurement and changing everything. We’re just going to have the client-side, the current GA4 property being kept… And the new GA4, as a new property. The way we tackle digital analytics services to simplify everything… it’s usually, you can categorise them into those four categories. Strategy, reporting, dashboarding, governance and implementation / innovation. In that case, this is just an implementation project. So we really focus on implementation and governance. So any implementation projects will always involve some, in some regards, governance, documentation, and trainings.
In Marketing with Trust, we are certified partners, since 2018, and we use the Google approved process. This is very standard process, by the way. If you have done, ever done development project, it’s very similar to that. We have five phases, prepare, discover, design, implement, and launch. And usually for projects, implementation projects, I recommend 12 weeks. There are some projects that go much faster. Some of others much longer… but the more people are involved… the more dev people or teams involved, the longer it’s going to take. Now, Prepare / Discover is all around defining the timeline, understanding who are the people, understanding the actual objective of the project.
This is where we interview the stakeholder understanding, what they want. But also, getting information on what they set up and why they set up this way. We do, on our ends, the review, GA, GTM, server-side tag manager. We look also at the measurement protocol or any hard coded tag that they may have. And then we do the Design. So the design is going to be, us filling the gap, right? So we know what they want. We know what they have. How we’re going to get there? So this is where we create the measurement plan. We create a detailed implementation plan that includes step by step what we’re going to do. We produce the documentation. Then the Implementation phase. Well it talks by itself, this is where you implement GTM. This is where you implement the tags. This is where the team is updating the server or the apps and all the websites.
This is where we do the validation, qualification, QA, like normal dev steps, and then we prepare for the launch. And Launch is the last phase. And this is where we give the ownership back to the client. This is where we do the trainings. This is where we give them all the documentation. This is where we run through a presentation showing this is how the project has been. And this is what we we’ve done and how we’ve done it. Every project has challenges. And in here, I just want to show you some of the challenges that we had. So first one to me, for server-side implementation in general, it’s the technical complexity of it. It’s new. I put quotes in there. It’s new, new, but not a lot of people actually know how to implement fully server-side. It involves much more complex concepts than client-side would. The other challenge that I see, in that sort of projects, are ETA and the deadlines.
So I was just telling you, and usually we say 12 weeks. But the client thinks it’s too long. So we usually have to adapt, but then the reality catches us up. It usually takes longer. The cost implication, there are always cost involved, especially around developments… that the team didn’t necessarily understand at the beginning of the project. Even if we present it, sometimes it’s hard to evaluate the amount of work that will be involved. App. I’m just putting apps there because I do think that app tracking is a nightmare in general. Firebase analytics works well. But as soon as you want to do something else, it’s a bit more challenging. And as soon as you want QA unless you are a dev or you have very good dev skills, it’s going to be hard.
And then in this particular project, I think one of the other challenges we had was the language. Well I’m French to start with, project managers were from Australia. Some of the team were also on the clients’ end were French too, but we had the majority of people who were Vietnamese. So there is always a chance that information is not properly understood by one or the other side. We are now going to spend some time going through the new digital paradigm. We’re going to go through the new setup that we put in place, the output of this project.
But before we go into the actual architecture of it and how it works… there are a few considerations that I need to tell you that impacted the overall design. So one of the first thing, and I mentioned it earlier… is that the fact that their existing GA4 property was compromised because they were collecting PII. And there was also the fact that purchase events were double counted… because we had server-side sending purchase events and… they were also having clients side GTM collecting purchases. The other consideration, which is one of the biggest, was the fact that they wanted GTM server-side to be hosted by Stape. I didn’t know the product before. But I’ve been studying it and I could see that they were proposing a lot of different SDKs… so I could implement in the apps, in the server… different SDKs to send the information to the server-side. They have templates for clients, for tags. And then the other thing is native integrations are always better than any custom implementation that you could do. I considered implementing measurement protocol calls from GTM on the apps. But overall it was more complex than the native integration and using Stape.
This is one of the concepts that I keep reminding myself when we do that sort of projects. Which is the KISS principle, the “keep it super simple”. Let’s just try to not over engineer things and just like, keep it simple, stupid. Now they are in native integrations. So like I was saying, Firebase Analytics integrates with GA4. GA4 integrates with Google Ads. It’s simple. It’s going to help us with the compliance. It’s native. Just use the integration when you can. So this was the original plan. Like really just like the idea, the concept of it. And like I was telling you, GTM was actually playing a bigger role than it is now. You can see, especially for the apps then.
Android and iOS were using the client-side container… to send information to our server-side. But we changed that into this one. So I’m going to go through each of the streams, one by one, and explain you on how it works. Right? The first one is the web stream… it’s pretty standard in a way you will have the website, the dataLayer… and then the clide-side GTM container… and where we would have all our GA4 tags sending information to our server-side container. And then in our server-side container… we’ll have the (GA4) client claiming all those requests coming from G4… processing, parsing the data, the event data. And then we will trigger tags. So either, GA4 or Facebook. Now for the purchase events, you can see, we will have the Haravan server. We will send the purchase events information… using the Stape SDK to send information directly to our server-side container.
And then from there, trigger the tags that we want. And then for Android and iOS, Stape is proposing SDKs for both platforms that hook on Firebase Analytics. So for every event that occurs in Firebase Analytics… Stape is going to parse the data and send it to our end point. So in terms of implementation… you just need to deploy the SDK and then Stape is going to do the rest for you. So all the information is being sent to our server-side container. We have there our Stape client that will process that data and then we will be able to trigger the tags for Facebook. Now you can see for the app streams, we actually using the native integration for GA. So we are not sending from our server-side container any (GA) information from the app.
This is basically directly being streamlined to GA4. And then for Google Ads, as you can see, we are using for all streams, we are using the native integration. We are not triggering any conversion for Google Ads, any tags for Google Ads, all the data is being processed through GA4. The learnings from this whole project that I wanted to share with you. There are six main learnings that I have on this project. One is apps are complex. When it comes to tracking and setting up measurements.
Obviously, we have Firebase Analytics, we have some Mobile Attribution Platforms that we could use. QA is hard, deployment takes time, to have them installs… Overall, as soon as you have an app involved, it adds complexity. Second point is the importance of training, I think. This is quite technical. It involves a lot of people. And you have to take the time to train and teach people on how things are working. A lot is subject to misinterpretation. So I really emphasise on this. Spend the time explaining and reexplaining and reexplaining, you will save time down the road. Simo Ahava’s expertise. I mean. Obviously. Everyone knows how Simo is. But really, the training on server-side is the one resource that I used to train myself on this technology. And I really enjoyed doing this training. I know that he’s updating regularly the training, but he’s also promoting it (GTM server-side). And he’s also having like articles on his own blog explaining things. So really, if there is anything you need to know, Simo is one of the good resource. And also he is very willing to help. So I reached out for instance, on slack, Measure slack, and he helped me with the overall design. The native integration. If there is one, just use the native integration, it ‘s always going to be more powerful than anything that you’re trying to do.
Even if the native integration is not as good as we wish it would. Sometime it’s better than anything that you would do. The peer support. In that sort of project I think it’s very important to ask for support from your peers, like within your agency or company. Just making sure that you validate your design, your approach, your dataLayers, your specification for devs… Just bounce all your ideas to someone else just to comfort you, that you are taking the right approach, the right path. And then expect challenges. I think it’s the common theme on any implementation projects, not just server-side, but any implementation projects. I’m always surprised by the amount of challenges that I can face that I was not anticipating.
And this is me for today. I hope you enjoyed the server-side story that I had to present to you today. So we went through. who was the client, the deliverables, the plan of attack, why we did server-side, some of the challenges we had, the overall architecture, the outputs, the things that we have implemented and some of the learnings. If you have any question, please feel free to contact me. You can add me to LinkedIn or send me an email.
I’ll be very happy to provide you additional information or context. And, I would like also to thank again, the Measure Summit team. I am really glad I could present this year. Thanks everyone. And speak to you soon.
Final Takeaways
This project reminds us that server-side isn’t just a technical shift — it’s an organisational one. It requires:
- Clear project ownership
- Strong documentation and QA
- A realistic timeline (hint: 12 weeks is often optimistic)
- A commitment to training and knowledge sharing across teams
And most importantly: when native integrations exist, use them. They save time, reduce bugs, and improve compliance.
Want Help with Your Tracking Stack?
If you’re planning a migration to server-side, struggling with compliance, or just want a second pair of eyes on your tracking architecture — we’re here to help.
Reach out to us at In Marketing We Trust
Connect with Benoit on LinkedIn
