#74 The UPDATE framework for server-side GTM migrations (with Matthew Hooson @ Measurelab)

This week Dan and Dara are joined by Matthew Hooson from Measurelab to talk about server-side Google Tag Manager (sGTM) and the UPDATE framework to best migrate over to server-side tagging. Hear Matthew talk to Dara and Dan about what he and the team have learned from doing many sGTM migrations, and what the top things to consider when migrating are.

Check out the UPDATE framework from Matthew on how to migrate to sGTM, Why you should consider Cloud Run for server-side GTM, and How to access BigQuery data from server-side GTM (via Firestore).

And as always, visit Simo’s blog for even more resources on the topic.

In other news, Matthew built a wall!

Measurelab is hiring! Head over to our careers page to see what positions we have open and apply.

Follow Measurelab on LinkedIn.

Intro music composed by Confidential – check out their lo-fi beats on Spotify.

If you’re like what we’re doing here, please show some support and leave a rating on Apple, Spotify, or wherever really.

---

Let us know what you think and fill out the Feedback Form, or email podcast@measurelab.co.uk to drop Dan and Dara a message directly.

Quote of the episode from Matthew: “You’re certainly putting yourself in a certain amount of digital debt from the maintenance side of things (of server-side GTM)… We’re pretty upfront with clients when we’re talking about these kinds of projects that this isn’t a one and done ,off you go, skip off into the sunset with your new conversion APIs. This is something that needs continuous thought, it needs reporting, it needs to be monitored…”

Quote of the episode from Dan: “…(server-side GTM) 100% squarely in IT’s camp, the marketers have access to a proportion of that which they can play with safely. And I think that’s for me, the idea there is that we’re kind of appeasing IT and also not removing any capabilities from marketing.”

---

Transcript

The full transcript is below, or you can download the transcript file here.

• Intro [00:15]
• Topic [02:16]
• Wind down [33:28]
• Outro [34:36]

Intro

[00:00:15] Dara: On today’s episode, we’re joined by Measurelab’s own Matthew Hooson, who talks to us about the benefits of server-side GTM and some of the complications, and also about the UPDATE framework that he’s developed here at Measurelab to help people migrate to server-side GTM.

[00:00:30] Daniel: The UPDATE framework along with all the other resources that Matthew talks to, the ones that he’s created, as well as his colleagues at Measurelab, as well as the other ones that he’s been using to learn all this stuff are linked to in the show notes, so follow that link to get all the resources that he’s been using. Alright, enjoy the show.

[00:00:45] Dara: Hello and welcome back to The Measure Pod, a podcast for analytics and data enthusiasts. I’m Dara, I’m CEO at Measurelab.

[00:00:52] Daniel: I’m Dan, I’m a consultant and trainer at Measurelab.

[00:00:55] Dara: And we’re joined today by Matthew Hooson, who’s one of Measurelab’s own. So Matthew was actually on the show once before, just after we had all been to MeasureFest prior to the brightonSEO conference, and Matthew was one of the guests who came on and talked about his favourite talk. But Matthew, good to have you back on, how are you?

[00:01:12] Matthew: Very well, thank you. Yeah, thanks for having me back.

[00:01:15] Dara: No worries, so you’re back on your own this time, but before we get into what it is that you’re going to be talking to us about, can you just remind our listeners of your journey into analytics?

[00:01:24] Matthew: Yeah, I think last time we said it was the fairly typical route. It was adult nursing, pub landlord, journal editor for a medical journal, analytics. You know, the fairly standard path to analytics. That’s pretty brief.

[00:01:38] Dara: Pretty predictable really, isn’t it? I mean, how else would you get into analytics?

[00:01:41] Matthew: Yeah, that’s it. As pretty much everybody I hear on this podcast it’s a stumble in that direction, something about your particular way of thinking or something or other just ends up settling you in the world of analytics for some reason, and that’s how I got here.

[00:01:54] Dara: Gets its claws into you. All right, so you are going to be talking to us while we are going to be talking together about server-side GTM. So why don’t you kick things off by giving, I’ll pretend to be somebody who doesn’t know much about server-side GTM. So why don’t you just give me the kind of initial elevator pitch of why somebody might be interested in server-side GTM versus the standard kind of client side implementation.

Topic

[00:02:16] Matthew: Yeah okay, elevator pitch. So what server-side GTM is, so the standard GTM container that will be we’ll be very familiar with very nice, warm, safe blanket that we’ve been all using for a number of years. That all runs client-side all within the browser, so all of the tracking, all of the data that you’re sending back out to third party tracking partners or solutions, all of the JavaScript that you are downloading and running and passing and manipulating data with, that’s all happening locally within the browser. And that’s great, and has worked well for a long time, but there’s a couple of problems that have sort of necessitated more exploration and Google’s move towards the server-side implementation. And those fall into two main buckets really, the sort of war of attrition against the, the third-party cookie and its dwindling use and utilisation. A lot of previous marketing technologies and things like that have relied on third-party cookies in order to function properly. So as they start to dwindle and be less and less useful, new solutions need to be found in order to be able to effectively track your marketing spend with conversions, etc.

[00:03:20] Matthew: The other bucket involves security and GDPR and the ever complex world of GDPR and understanding things and making sure that we’re all putting our best foot forward in terms of ensuring no personal identifiable information’s leaking anywhere, making sure that we’re aware of what data is leaving and where it’s going. And again, that is difficult within the client-side container, especially with third party pixels, things like that. You may think you know what data you’re sending in their direction, but sometimes they’re collecting other things that you may not be fully aware of. They may be trying to do things like fingerprinting and things like that to try and help understand your users a little bit, so that obviously has problems.

[00:03:57] Matthew: The way server side works is rather than all of that stuff happening within the client side browser, you set up your own server side container, and that is run on a server controlled by you, typically on Google Cloud Platform (GCP) because Google makes it really easy for it to work with Google Cloud Platform for obvious reasons, and that means that you essentially send off packets of data to the server as a HTTP request. Then you do all of the processing, you do all of the redaction, all of the anonymisation, the decisions on what data’s going where you do all of that processing within the server that you own, and the server that’s under your control. Means you can control a lot better what data’s going where, make sure that data is anonymised etc, etc.

[00:04:39] Matthew: It also, as I mentioned, all those JavaScripts that are being downloaded and passed and manipulated within the client-side can be moved over onto the server-side and that can help load speeds and things like that as well within a site. That’s the reason why server side is interesting and people are starting to consider it more and more.

[00:04:58] Daniel: Great, thanks for coming on Matthew. It’s been good talking. No, I’m just kidding, I love server side and we’ve got it set up on our website, thanks Matthew, for that actually. We’ve been working with it for a while now and something that when I’m talking to people when I’m speaking to clients about, you know, implementation server side, quite often the term server-side tagging or provisioning a server or the GCP never quite comes up in conversation. The way it comes up is sort of Meta is pointing them towards using CAPI, which is their Conversions API framework and Google is pointing everyone to use Enhanced Conversions, right? We’re talking about the same thing, right? We’re talking about providing data directly to a system like Meta or Google via an API, and that’s the process of doing that, is using server-side tagging, and obviously Google has their own server-side container.

[00:05:41] Daniel: So I think this is the interesting part for me is that often it’s like we need, insert thing here, we need CAPI, we need the Enhanced Conversions. But actually, and I think this is what I want to dig a bit more with you, Matthew, is the process of getting there is quite convoluted, and it needs some thought, otherwise there could be some painful moments down the line right? There’s actually quite a lot to doing server-side Google Tag Manager, not at least the cost because that’s a new thing for people to think about when it comes to tag management. But what are some of those things that I suppose are new to the server-side tagging world that you didn’t have in client-side? What are those things that maybe people don’t kind of think about when they go into something like this?

[00:06:19] Matthew: So yes, there’s a lot to think about. There’s a lot to think about from the fact that a server-side container itself, the GTM UI interface is slightly different. It has new concepts in there, like ‘clients’ which are receiving the messages from the client-side container and yeah slightly different ways of setting up triggers and things like that, different types of variables. So that’s one consideration, there’s a whole new sort of interface there. The other consideration is the sort of architecture of the whole thing. You’re getting into provisioning, scalable cloud architecture and when you sort of throw a term out like that, you start to understand that things are a little bit more complex then they may seem when Meta’s just nudging you in the ribs and say, oh get CAPI it’s great, there’s more to think about. You could potentially just spin up a App Engine flex, automatically provisioned server.

[00:07:08] Matthew: Google makes it very easy to do that within the UI of server-side GTM containers. But in doing so, I don’t think it’s particularly clear to a layman that, oh, that’s only going to spin up one server instance, for example. And really you need at least three to make sure you’ve got redundancy or you’re going to be losing data, really important data that you don’t want to be losing. It’s not really clear how you scale and how high to scale or how low to scale or what thresholds you should be using it. It’s not really clear should I be using App Engine? Should I be using Cloud Run? What’s the advantages, disadvantages of each. It’s not really clear as you put that this costs money. If you’ve not been on a Google 360 contract in the past and you’ve just been using Google Analytics and you’ve just been using a client-side GTM container, you probably are maybe used to not paying for your analytics and within this new server-side world, you could be looking at anywhere between 40 to 300 dollars, depending on the amount of traffic and requests that are going to be hit in those servers and the architecture you’ve got set up in there, and your fail safes and things.

[00:08:08] Matthew: There’s a lot to think about, a lot to make sure that you’re getting right because the consequence, as I’ve kind of already alluded to, is either a spiralling cost because you’ve not properly thought things out, you’ve not got the architecture well thought out, and you are not monitoring things properly. Or data loss and you’ve just got big black holes of data heading off to your various third parties which is not ideal.

[00:08:29] Dara: And you mentioned the cost there and you were talking just about the cost of the, the kind of use of GCP only, but there’s obviously the potentially additional cost of either hiring people if you don’t have the resources already, or hiring an external kind of third party to come in and advise you and help you set this up. So, it’s not just the fact that there is a cost to actually kind of running it, but there’s the cost or the resource requirements to actually, because as you mentioned, it’s really complex, so if somebody just believes the hype and thinks, oh, I’ll move to server-side GTM that sounds great, it’s by no means that easy. There’s quite a lot of thought needs to go into the kind of architecture behind it as opposed to client-side GTM where it’s relatively easy, by comparison.

[00:09:12] Matthew: You’re certainly putting yourself in a certain amount of digital debt from the maintenance side of things. We recommend to clients, we’re pretty upfront with clients when we’re talking about these kinds of projects. This isn’t a one and done ,off you go, skip off into the sunset with your new conversion APIs. This is something that needs continuous thought, it needs reporting, it needs to be monitored, it needs to be changed and updated. If you either don’t have the internal resource to manage that or aren’t willing to go along with some sort of maintenance package with, I don’t know ourselves or somebody else to maintain those things, then maybe it’s not for you because you could find yourself in a bit of bother.

[00:09:47] Daniel: For me, that’s probably the biggest misconception going into server-side tag manager that I’ve seen out in the wild at least. And that’s the, the fact that it’s going to be in an organisation, it’s going to slot in and replace where Tag Manager lives right now. There’s an argument there that Tag Manager shouldn’t be sort of set up and walked away and forgotten about because, you know, you’ve got the same kind of problems that you alluded to earlier, Matt, around, you know, client-side GTM with this overhanging implementations, sending data to places you don’t know about or page low times could be increased when they don’t need to be those kind of things.

[00:10:15] Daniel: But more so with server side Tag Manager, because it’s one thing, it’s new, it’s new technology, the community and the resources and the templates and the guides and the, just the common understanding just isn’t there right now. And also you’re spinning up service, right? So anyone with a database or a server or data warehouse, you can’t expect that to work on its own. And so I think this is the biggest thing is that, oh yeah, no we’ve got a marketer or an analyst that just manages Tag Manager. I think when it goes over to the server side, it comes with a whole world of different skill sets and I think that’s the thing that gets people the most is that it’s, oh crap I didn’t think about it that way. I need people, different people, external people or a new hire to kind of come in and manage this or it’s no longer just a bit on the side, which client-side GTM has often thought about, whereas server-side tag manager is a, a living, breathing beast that needs a bit more time and attention.

[00:11:00] Matthew: Absolutely, and that’s kind of spoiler for the first step of the UPDATE framework, which is to understand, is to make sure that before you’re biting the bullet on any of this, you’ve done your homework, you understand the costs, the setup, the future need to maintain before you jump into, jump into this with both feet.

[00:11:15] Daniel: It’s good to mention the UPDATE framework, let’s talk about it a bit. So us at Measurelab and you specifically Matthew, you’ve done a number of these server-side implementations or migrations or setups, whatever we refer to them as. And yeah, so the whole point of the UPDATE framework is you put together kind of a process to follow so that you and your team and people at Measurelab and externally can follow to potentially mitigate any of the mishaps and to make sure that you’re going in with your eyes wide open. You mentioned first part of that, but give us a run through, so what does UPDATE stand for and why did you write it? Where did it come from?

[00:11:45] Matthew: Okay, so update stands for understand, plan, declutter, action, transfer and evaluate. And it roughly sort of just breaks down into nice little columns, the stages at which we think from our experience of doing this for both extremely large clients with extremely complex, the Tag Manager containers and architectures within GCP to smaller clients with less requests and less traffic coming their way. It’s something that covers both extremes and makes sure that you are thinking about everything. It’s important to say that it’s not a checklist, we’re not trying to hold your hand through every single, make sure that this box is ticked and this is added in here. It’s more sort of a trying to be a broad strokes, remember to think about this, remember to have this at hand when you’re moving into this next stage, remember to have a proper plan in place.

[00:12:35] Dara: So Matthew, maybe this isn’t the right conversation to go into like really granular detail on each step, but one thing I was wondering, which might be useful, is to maybe give a, just a quick run through of maybe who would need to be involved because one thing I was thinking about is, Google did a really good job of pushing GTM as being a solution for marketers. So they didn’t have to go through all of these kind of development cycles and kind of worry about some of the things that you now do have to worry about again with server-side GTM. So, it might be worth going through each of the steps in UPDATE and just giving an overview of who within the business might need to be involved at each step and kind of who would do what.

[00:13:13] Matthew: Yeah, absolutely. Yeah like you say, I think it’s not just marketers, spoilers, but there’s definitely more people that need to be involved with this. So starting at the top then, so that you understand, I think as many people as you can get involved that are going to be directly affected by this move. Marketers, any other stakeholders in the business. From our side, it’d be analytics engineers, it’d be conversing with developers for the clients because there’s going to be some changes they need to make to code. It’s going to be working with our analytics consultants who have a better overview of the whole analytics stack. So really bringing in everyone and the point of the understand step is that, that everyone is on the same page, everyone knows what’s going to be involved, everyone’s available, ready at the right times to be able to pick up these different pieces, this sort of multidisciplinary approach to the migration.

[00:13:57] Matthew: And then that moves nicely into the planning stage where again, you probably need your developer, your analytics engineer, your analytics consultant, and any internal stakeholders to plan out every stage, a timeline of what’s happening. This can involve things like checking what traffic you’re receiving so you can start to us understand and agree upon your architecture. What’s your underlying server architecture going to look like? It can make decisions on, are you going to switch to using HTTP cookies rather than the standard GTM third party cookies that are normally set. What’s your KPI for this whole thing? We’d always encourage somebody who’s switching over to server-side GTM to have a reason for doing it and to have a measure. We’re confident that they will see the benefits, but it’s important to first set out those KPIs and understand what they are and that’s going to take a number of different people, a number of different decisions.

[00:14:45] Matthew: And then we start to get into the more technical side of things, the actual doing. Dan you already mentioned a little bit ago about how unwieldy GTM containers can be if they are not properly maintained, and they’re not looked after. So this is a great opportunity to declutter, get rid of a lot of stuff, a lot of superfluous years of third party tracking that’s long since been forgotten and is probably set up by somebody who left the company six years ago or something. Think we’ve all experienced those kind of GTM containers. So again, you need your analytics engineer or your implementation analyst, depending on who you have in your organisation, consultants, your internal marketing people, to be able to make decisions on what is and isn’t coming over, and really build out a migration plan about what’s going to move up to the server, how you’re going to do it.

[00:15:25] Matthew: And then the action step, which is going out, is setting up and provisioning your servers. It’s migrating all of those tags over, now you’ve got the migration plan in place and agreed upon strategy. The more and more you talk about it, the more and more things pop into your head. Oh, you need to do this, you need to do this, you need to do this, you need to do this, hence the framework. But again, an engineer needs to be in there because they’re going to have to go off and they’re going to have to set up the servers and everything as I already mentioned. Then we’re looking at transferring things over, again, a developer needs to be involved because they’re going to have to go into your code snippet, they’re going to have to swap out for your new server URL and subdomain. And then finally, when you’re evaluating, I think again anybody who’s touched the various components and different areas of the migration needs to be there to make sure that they’re happy that what they’re expecting to see is being seen. So in a nutshell, yes, there’s a lot more people that make this whole thing work rather than just marketing.

[00:16:21] Dara: And I’m going to ask you maybe a tough question to answer because obviously it’s different on a case by case basis, but do you think it’s something that could be useful for any type of business that then they might scale into it, so they might not use all of the full benefits, but as they kind of grow, they would then start to use some of the extra benefits of moving to the server-side? Or is it a case that it just wouldn’t be necessary for certain types or sizes of businesses?

[00:16:46] Matthew: I suppose it depends on what their main aims are really. If they’re kind of wanting to, let’s say, put their best foot forward in terms of security and data governance and things like that, and they’re wanting to have a gold standard to move from and build from. Then, yeah, it may make sense to set up a server-side container and then you’ve got all of your ability to control what data’s going where, be really granular with it, have a really good sort of data governance plan, only have your one, your own subdomain sitting in your content security policies, not 50 third-party URLs sitting in there. So from that perspective, if that’s their aim, and that’s something that they really want to strive for, then yes.

[00:17:23] Matthew: And the advantage is that a lot of the pricing we’re talking about having an internal resource to maintain this, not withstanding, a lot of the pricing on the Google Cloud platform scales, you know, because we’re talking about a number of requests that are hitting. Which is very closely related to how much traffic your site’s receiving, how many events your site’s receiving in a month-by-month basis. If you’re coming in as a smaller company, you’re not going to be paying your $300 plus a month within GCP, you’re probably more likely got a couple of servers scaling up to sort of, I don’t know, six at a maximum. And you may be paying $30 a month for those servers. So, yeah, I think depends on what you want to do, but there’s definitely benefits there if those things align.

[00:18:04] Daniel: I think it’s going back to what you said earlier Matt, around having a KPI, right? What is it you’re trying to measure and improve upon? And then making sure you have one to begin with, and then I suppose that’s side down to, you know, understanding whether or not it can be addressed with the move to the server side. I had a question around server-side tag manager and the kind of relationship with client side tag manager, and that is around, do you see a point in the future where, so right now it’s quite common to have both, right? You have a client-side GTM container that sends data into server-side GTM, and then you can fire some tags and, and I think one of the reasons for that is the fact that not all tags can be moved server side, right?

[00:18:40] Daniel: So we’ve mentioned like CAPI and Enhanced Conversions from Google and Meta they have, but some of the smaller platforms, they might not have even built out a way for sending data in via that method, in which case you need to keep some things in the client side. First of all, is that like recommended – like how do you approach that kind of thing? Because the other side of that is you might turn out that you can only move 10% of the stuff over to the server. And obviously is that relevant? Is that needed? Or is that going to make a big enough impact? But the other thing is, do you see a time where people will just move away from client-side GTM altogether and just use server-side Tag Manager? And if that’s the case, you know, is that in the near future? Is that a possibility? What do you think is going to happen around that?

[00:19:16] Matthew: So the first question around the functionality and not everything being over there. Yeah, absolutely I mean, everything has been moving in the direction of tag templates, both client side and on the server side recently, because they’re great, because they give you more granular control of the permissions. You can control what’s going in and out of those things a lot more. Part of the planning phase of the UPDATE framework is to look at that functionality and decide, right, is there anything sitting nicely on the community shelf or tag templates that just picks that up and moves it off to the server and we can just start using that straight away? If not, do you have the internal resource or are you willing to invest in maybe developing that tag template yourself?

[00:19:52] Matthew: If you have the API endpoint, which a lot of these custom HTML scripts will just have, it’s all they’re doing is they’re just sending data to an API endpoint. It’s not beyond the realm of possibility just to make that functionality yourself with a custom tag template within the server. So it’d be what’s already there, can we grab some of this, can we make some of this ourself, which may a lot of the case be, yes, we can. Well, let’s go and develop that, and for everything that’s missing, it would probably just still have to remain within the client side until these other third parties catch up and start to develop these, the server-side versions.

[00:20:22] Matthew: To the second point around having a server-to-server implementation. So just cutting out the middleman, if you will, and just having your website send event data straight to your server where it can then be passed and dealt with and sent off to third parties. Yes, I think that some people are already doing that. Some people already use just a server-to-server type setup. It very much depends on what you have internally, as a development resource. If you’re able to configure that and get the data just being sent directly through to the server where it can all be configured. One of the nice things about GTM, as we’ve already kind of discussed, is its user interface and the ease with which people can go in and start to just sort of set things up and manipulate things. The same is essentially true if you still have that client-side container, you could still be setting up custom tracking, just sending the data through to the server, so you may potentially lose a little bit of that ease of use for some people, if you move completely to a server-to-server model, I think.

[00:21:16] Daniel: Cool, so client GTM is safe for the time being, there’s no imminent danger of Google stopping supporting it and just rolling all over to the server. But yeah, it’s definitely useful for deploying new stuff for the server right? I know how useful it can be for doing that at the moment. I’m just thinking from Google’s perspective, would they want to keep the client-side GTM updated and feature-rich if that’s the way it’s going, but it sounds like it might be permanently part of the tool set really as, as a method of getting stuff into this server.

[00:21:40] Matthew: As a gateway drug almost, if you will. Do you know what I mean? If you’re coming up as a very small, you know, you’re a very small band of people setting up a company or something like that, and you just want to spin up a site, get GA4 up there and start to play with some tracking by just insisting on that, I don’t know, it may get more complex and they may lose that sort of growth through to server. Crystal ball, yes. I think it’ll stick around for a while.

[00:22:03] Dara: Are there benefits in terms of being able to use some of the other aspects of the GCPs? Are you better off having server-side GTM if you want to then enrich that data using some of the other tools available?

[00:22:14] Matthew: Yes, there are benefits outside of just what I already mentioned. I think for example we’ve done use cases where we’ve used something called a Firestore lookup variable, which is a built-in variable within server side, which allows you to just go and look up within a GCP Firestore table, which is a sort of key value pair database within Google Cloud platform. So it allows you to go in real time, look up, grab additional pieces of information, enrich your data within the server-side container, and then send it on to your third party endpoint. So one obvious use case for this, in theory, you could just be sending over like quantity and product ID from the client side, and then you could just using that product ID to look up inside of your fire store lookup table and grab all of the information about what that product is, colours, blah, blah, blah, blah, enrich the data with that data and then send it on to your, the third party endpoint.

[00:23:06] Matthew: How useful that is? I don’t know, it’s just a good demonstration of what could be possible. I think the way we used it previously, was we were labelling URLs based on for what, for some reason, I can’t remember exactly, we were saying this is part of this category, this is this category. All those categories were stored within the Firestore table, and then we just looked up the values and away we went.

[00:23:27] Daniel: It could be quite useful for stuff that you don’t want to be publicly visible, right? Not that people necessarily would dig into the code, but anything you track on your website is going to be visible and scrapable and monitorable by people you know, bots as well. And so if you are wanting to pass in, for example, like profit margins for your products, then you’re not going to surface that on the code, in the data layer, in the tags on your website. But you might want to enrich your data before it gets into Google Ads or Google Analytics 4 or something like that so that you can actually measure and optimise to profit rather than revenue. And I think these kind of things we might start seeing a bit more, more commonplace, I think with the move to server side is adding in this kind of context that we’ve learnt to work without just because we were too shy to put it out public right. Whereas now I think we get the opportunity to put that kind of stuff back into the data without it being visible to all.

[00:24:15] Matthew: There’s certainly, like we’ve already said, privacy and GDPR use cases that could be used where you’re not surfacing that information within the client side, it’s all hidden away and done within your server. It’s also relatively new that I imagine it’s going to be loads of cool and different use cases that people are going to be coming up with that we just see and go, oh yeah, of course that’s so obvious. Other things we could be doing with it, definitely.

[00:24:35] Daniel: So a lot of the way that we talk about server-side Tag Manager, the way it’s used is about sending data to the server and then kind of parsing it on and kind of scattering it out into the different platforms manipulating the data, redacting data, whatever. Is there any communication back to the, to the client though, with this whole new system, because within client-side GTM, you could, not that it was ever advised, but things like Google Optimize were built on this technology. But you could do visual changes, you could delete content from the page. You can make stuff happen on the website using Tag Manager.

[00:25:01] Daniel: Let’s say there was a time where there was no client-side GTM and it was all over in the server side. Is there that kind of two-way communication back to the website? Or is it all kind of one way to the server and then outwards from there?

[00:25:11] Matthew: The way the client-side sends the information over to the server container is via HTTP response, and that then goes back. So it goes to the server and then it sends information back to the client side to say, yes, I’ve received, and whatever other information that may be contained within there. And you can manipulate what information is going back in the other direction. You can, as I mentioned earlier, there’s something called a ‘client’ within the server container. Again, I will just voice my irritation about the fact they called it a client when the browser containers already called a client-side container. But anyway, something called a client and the client’s job is to grab hold of that, that HTTP request that’s coming from the browser container. Parse it, figure everything out and then send a response back to the, back to the browser container. So you can create custom clients, you can get them to do whatever you want them to do or send back whatever information you want to send back. Just dictate where it’s going to be, where that information’s going to be passed and sent to within your server container.

[00:26:07] Matthew: So yeah, it’s not a completely done in an air echo chamber. Not in the vacuum, you could be sending stuff backwards and that’s how the cookies are set as well. So one of the big advantages, or well, depends on your moral bent around, around privacy and the third party cookie. One of the things that was a big selling point for some people in the early stages of server-side GTM, was the HTTP cookie. So rather than someone like Safari being able to manipulate the expiry date of a cookie because it was set by your own domain technically, because it’s coming from a sub-domain. If you’re properly configuring your server container, it couldn’t manipulate that expiry date, and everyone’s like, oh, yay, that solves the problem of Apple manipulating our cookie expiry dates. They then change that to IP-related changes and that advantage has gone. There are other advantages to HTTP cookies, but that particular one is gone. But that’s how it’s set, sends the information back, stores the cookie.

[00:26:59] Dara: Going back to the point about needing kind of cross team buy-in for a server side GTM. In the old days there was pushback on client-side GTM from the internal tech teams because they didn’t like the idea of this thing being added to the website that they had less control over. So even though you’ve now got to bring more people back into the room, is it likely to make the tech team internally happier that they’re going to have a little bit more control over what’s actually happening?

[00:27:23] Daniel: I think this is where like it will, I think go down better, because before GTM is this kind of like on the fringe tool that the marketers have too much power and that’s their reticence to kind of implement it. Whereas this is like 100% squarely in ITs camp, the marketers have access to a proportion of that which they can play with safely. And I think that’s for me, the idea there is that we’re kind of appeasing IT and also not removing any capabilities from marketing. And I think this is where I find it interesting, but before the whole pretence of like client-side GTM is like, is a marketer’s playpen, you know, it’s just kind of implement, walkaway, WordPress module. They don’t even need to know it’s happened.

[00:28:02] Daniel: So Matt, if someone approached you, let’s say you’re at a conference or in a bar somewhere and someone comes up to you and says, oh, I’ve been asked to do a server-side GTM migration. Where the hell do I start? What’s the most important thing you tell them to, to consider before they walk into this kind of world.

[00:28:15] Matthew: One of the main things, one of my number one bullet points would be to make sure they understand it properly, make sure that they have the internal resource to be able to manage this long term. Make sure they understand the reasons for doing it. Why are you doing it? You doing it because you’ve heard about it and it sounds cool, or do you have genuine business reason that you want to get over onto this technology, that’d be the first thing. And then the second thing would be to understand what it’s going to cost them and doing so maybe go out, perform an analysis on your traffic, your site, understand your audience. How many events are you getting in a month, is my audience global or is it just within one region? What are my traffic patterns like within a day? Do they peak and trough, or, you know, all of these different traffic patterns lead into decisions around how you’re going to architect your underlying servers. And those decisions are really important and making sure that you’re not going to lose any data and that you’re not going to get some nasty surprises when it comes to cost. So I think understanding those two things, first and foremost, will give you a good foundational decision making set of rules to say yes or no, we’re going to do this, or we’re not going to do this.

[00:29:22] Daniel: Nice, and the other side of that is we’ve got the luxury or the privilege rather of being able to learn by doing. And we’ve got our own setup and we kind of know what we’re getting into, and we’ve got the experience, I suppose, doing it a number of times now. If someone didn’t have the luxury of being able to get their hands on a server-side container and to see it in action straight away. What would you suggest in terms of being able to go learn and figure this stuff out? Where’s a good place to go? Do you have any resources or people you follow to, to learn this kind of stuff?

[00:29:48] Matthew: Well, first of all, I’ll say Measurelab can help you. No, but yeah, like you say we do have the luxury of doing this for a number of clients, large and small. We get to go, we get to figure it out, we get to come up with these resources and things like that. In terms of where we figured a lot of it out, part of it is by doing, part of it is by leaning on something on the shoulders of some analytics giants. So I would always, pretty much for any analytical question say someone like Simo. To sort of toot our own horn for a second, we’ve been really trying to produce a lot of documentation ourselves at Measurelab because I think, like you alluded to earlier Dan, It’s a new technology and it can be really difficult to find resources. It can be really frustrating when you’re looking to an answer for a specific question, you just can’t find it, even with your years of Googling skills, honed as they are, you just cannot find the documentation because it doesn’t necessarily exist yet. Google’s documentation can sometimes be frustratingly inconsistent or lacking.

[00:30:44] Matthew: So that’s why we shared the UPDATE framework, our own sort of internal tool that we used to do these migrations. We have resources on Cloud Run being used for this, we’ve got upcoming stuff around load balancing, lots of different new learnings and new approaches to server side we’re trying to get out there. So us, and then there’s a few other blogs and things, and I think that things will start to appear more and more and more, as more and more people do this.

[00:31:08] Daniel: Nice, thanks. I’ll stick all these links in the show notes. So if you want to follow along with any of these, then feel free to click the link of the description.

[00:31:13] Dara: Just a final question from me anyway, Matthew. You mentioned earlier about pros and cons of using Cloud Run or App Engine. Is that something you could just quickly explain, give a little bit more detail on?

[00:31:25] Matthew: Like I’ve already kind of alluded to, when we were talking about that sort of piece of analysis that you need to do at the start of any of these kind of migration projects where you’re looking at your traffic levels, your peaks and troughs, how global is your audience. All of those questions ultimately go to help you decide if you’re going to go for something like Cloud Run, or if you’re going to go something like Google’s automatically provisioned solution, which is App Engine. The reason being with Cloud Run, for example, you can do a couple of things. You can scale to zero, so when there is no request being received, you can scale down to zero and you essentially pay nothing. So if you know for a fact you don’t get any traffic between 6PM and 9AM, then potentially a Cloud Run setup that scales down to zero will save you a lot of money in the longer term. So, something really useful to be aware of. If you’ve got a global traffic base, global usership, it may be worth using Cloud Run and adding a load balance in front of it that allows you to have a multi-regional deployment of your instances and it’ll serve the closest instance to that user. That can make a big difference to things like latency, but it also adds in another level of redundancy in case any particular region goes down. It can sort of be rerouted to another region.

[00:32:34] Matthew: Another thing that happened recently that some people in the audience might have been aware of. Over Black Friday, the US central App Engine flex service went down over Black Friday, so anybody with an automatically provisioned server, GTM server container the data didn’t get sent for a certain amount of time over that weekend, which is why Google then came out, started recommending Cloud Run themselves and put some documentation out there. There are advantages to App Engine in the fact that it is easy to set up. You can literally just make sure you’ve got a Google Cloud Platform billing account and just from within the UI in, in the server container, just provision a single App Engine instance. So that ease of use and that access is an advantage in of itself for, like I say, don’t set it up and rest on the laurels, because you may find yourself either in data, black hole territory, or with a surprise bill.

[00:33:22] Daniel: Or forget to update your credit card.

[00:33:24] Matthew: Or forget to update your credit card and suddenly you don’t have any data for however long, yes, exactly.

Wind down

[00:33:28] Dara: One last question and then you’re off the hook. And this is the infamous wind down question. So what have you been doing lately outside of work to chill out and rest and recover?

[00:33:38] Matthew: Nothing in the terms of relax, rest and recovery. I took a week off last week to build a wall. I split my front room in half, so I was building a stud wall and doing electrics and plumbing and things like that. So it was 13 hour days for six days to just get it done within a week. So I’ve come back to work fatigued and generally tired, so nothing really, work.

[00:34:03] Dara: So work is now the wind down, yeah. After the week of serious hard labour last week.

[00:34:08] Matthew: Yeah, the paid work has been really relaxing so far this Monday. But yes, that’s what I’ve been occupying myself with anyway over the past week.

[00:34:15] Dara: And this is a true story, we can tell our listeners, we have actually seen photographic evidence of this, that you did build a wall.

[00:34:21] Matthew: I did build a wall, yes. Not a lie, it’s a weird lie.

[00:34:28] Dara: Alright, brilliant. Thank you again for coming on the show for a second time, Matthew, and talking to us all about server-side GTM, and the UPDATE framework.

[00:34:35] Matthew: Thank you for having me.

Outro

Dara: That’s it for this week, to hear more from me and Dan on GA4 and other analytics related topics, all our previous episodes are available in our archive at measurelab.co.uk/podcast. Or you can simply use whatever app you’re using right now to listen to this, to go back and listen to previous episode.

Daniel: And if you want to suggest a topic for something me and Dara should be talking about, or if you want to suggest a guest who we should be talking to, there’s a Google Form in the show notes that you can fill out and leave us a note. Or alternatively, you can just email us at podcast@measurelab.co.uk to get in touch with us both directly.

Dara: Our theme is from Confidential, you can find a link to their music in the show notes. So on behalf of Dan and I, thanks for listening. See you next time.