I can do all these hacks through GTM. I can write all these time variables. I can write
all these listeners and all these scrapers. I mean, each time a new release comes up,
I'll just spend another eight hours to fix all my variables. Or you can look at what
part of the organization is causing this friction. Try to drill into that or fix that. And suddenly
you'll have a healthy data layer with great unit and functional tests, and you don't have
to worry about it. Hey there, Measure Geeks! Julian here, back
with another video. We've all heard this question before, can Google tag manager replace the
IT or the developers? This is obviously wishful thinking by some marketers out there. Sooner
or later, we all need to get our GTM snippet installed. And then we probably need to talk
to a developer. And especially when we do more complicated things with GTM, with data
layer and so on. But where does this mistrust and this tension maybe come from when we talk
about the relation between developers and marketers, especially when it comes to tracking
deployment and Google tag manager. This is just one question in a small panel discussion
that I had with Simo Ahava and Chris Mercer for Measure Summit. And we'll hear about this
in a bit. But if you want to check out the whole session, then you should definitely
head over to measuresummit.com and get your ticket right now.
All right, we still got lots to cover. So let's dive into the conversation with Chris
Mercer, myself and Simo Ahava at Measure Summit 2020. Um, I would say that GTM came or the
adoption was, was driven by marketers who said, Hey, we need this on the website. Agencies
then used it and, uh, to install tags. But on the other side we have developers, right?
So in inside of the inside of a company, there are, um, I would say that Google Tag Manager
made it better to communicate, um, what goes onto the website, but there's always this
tension between developers and marketers. So maybe, um, I don't know, Mercer maybe you
can speak to this too, where, um, how did you perceive it when, when you had to install
GTM and you got pushback from, from the IT Department.
Yeah I mean, we still went under that. There's still some clients with where their IT departments
because they see it as and I think rightly so, because of how it started, which was they
see it as you're punching a hole and I've got this big, giant backdoor now in my site
that you can, that you can mess with and it's kind of uncontrolled. But just now the story
has to get out there about templates because they didn't realize, especially, cause they
didn't really look at it. They were just kinda like, no, because marketing wants it and they
didn't really understand tag manager. I have gotten developers on the calls where I'm like,
okay, let's walk through this and here's what you can do. And then when we, when we explained
it, uh, we worked, we worked with a cable company, examples like a regional cable company
and we developers doing sprints and they didn't have tag manager.
And so we were working with them as big Ajax site. It was a, it was a total pain for measurement.
But when I work with a developer and I walked him through the data layer and I started talking
about like, listen, you can put stuff here, you have stuff here. Then all of a sudden,
and this is where I think it was, it was key that it required communication to see most
point, required somebody who's like, this is how I describe myself. I speak developer,
but I'm not fluent. Right. And a developer. So I can communicate a little bit, but I can
work with them with the data layer. And I'm learning, you know, the you know, how to describe
the, you know, the JavaScript arena, everything else as I, as the developer understood the
potential, they started coming back to me saying, well, do you think marketing would
be, would it be useful if marketing knew that they selected a certain package to this point?
I think marketing would love that. Right. And all of a sudden, bam, now you got the
two working together and marketing, seeing things in the data layer that's coming up
in every sprint. There's a new thing in there that they can, now they can measure or build
an audience off of, or, you know, create a report from, and the two sides are working
together, but it did require that communication. So that developers understood this. Wasn't
just busy work that you're doing. And what it really did is it took off a burden from
other things that they were being asked to do, because they could just put all these
signals in the data layer, the data layer drove all of the results, which is where the
beauty of the data layers, right? The data layer is your signals. And then if anything
changes on the site, it doesn't matter. Like do whatever you want to do on the site, just
make sure the data layer is telling the story. And as long as that happens, marketing, nothing's
going to break and no one's going to flip out. And once everybody sort of understood
the power of how that all came together, it was just golden.
Yeah. I think that's the, that's a wonderful way to put it. The, um, yeah when you, when
you think about the gradient of how to use GTM, is that at the one that have the line,
you have the complete independence from the development machine. Like you have, you can
write your event listeners through GTM, you can scrape stuff of the HTML. You can, you
can build your own variables with their values and kind of do a lot of, um, guesswork based
on what the site should look like. Um, obviously we all know who've been doing that stuff.
We know how fragile that is. Like even if a single HTML element changes on the page,
you can either can throw your entire implementation off. And then you have to think about what
to do things. Things like Google translate, which automatically translate texts on the
DOM. So it's sort of in your HTML variables might
not work anymore because they're looking for the wrong type of text content, or maybe there's
a different, a new currency introduced and suddenly the symbol is in a weird place. Um,
so, so there's this one, the one on the other end is this like 100% data layer fueled implementation
where everything, all this, uh, these signals that Mercer mentioned, all this semantic information
is, is added to the data layer. Uh, it's also an event driven data layer. So all the user
interactions are reflected in, in custom code that then pushes stuff into data layer. And
that will, that will, the truth is somewhere in between. You need both, you need, you need,
uh, you need some solid time scraping with maybe data attributes or something, but you
still need a really good data layer setup. The, the great thing about the more you do
with data layer is that when you have a good development environment, when you have able
developers working on it and on a good luck, kind of an agile setup, um, you can actually
add that data layer to be a part of the build process.
So the site will not build if the data layer doesn't pass the tests. So that way you can
basically ensure that if, if a new release of the site is designed and some API has changed,
so that instead of producing the enhanced eCommerce stuff into data layer, it just produces
an empty object. So a clear bug from GTMs point of view, that site won't build until
that new test passes. So now the developers have to go back and look what broke the data
layer. And this is unprecedented. You don't get that with GTM. There's no controls of
GTM that say that, Hey, something broke, do something that, I mean, you can build these
monitoring things that actively monitor GTM, but you need to build them yourself. So now
by having that part of the build pipeline, this is just one example of developer cooperation,
having that in the build pipeline itself, you're making sure that none of your business
critical information ever gets lost. And that's this, this, this, this, I know
that for many, it's a painful idea having to talk to developers, but this is also because
of stereotypes and kind of a, a very popular way to approach an organization. And this
is one of those myths that I've been like busting my ass off to break because an organization
is exactly what you make it to be. If it's, if it's like completely inflamed, if those
relationships are broken, I don't think GTM will fix that. You know, GTM is a great tool,
but it won't fix that broken organization. So at that point, you have to start figuring
out I can do all these hacks through GTM. I can write all these Tom variables. I can
write all these listeners and all these scrapers, and each time a new release comes up. I'll
just spend another eight hours to fix all my variables.
Or you can look at what part of the organization is causing this friction, try to drill into
that or fix that. And suddenly you'll have a healthy data layer with great unit and functional
tests, and you don't have to worry about a thing. So it's really about the more I, the
more I, and this always happens when I talk about GTM, I start talking about GTM and I
end up talking about the organization because that's how I see them. They're completely
symbiotic. There's you can't take one away from the other, if you want a really healthy
implementation. And I know I went so far away from what the original question was that I
don't know if we're even close anymore, but when we're talking about grading
And this is great, we talk about, uh, communication. And for me, uh, definitely when I look at
GTM, it taught me a new language to speak. I mean, even that concept with, um, versions
and publishing your version and workspaces, that is something that came out of the development
practices, the best practices. And now we have them in the tag management and the marketing
deployment. So to say as well, and when you go to a developer, he needs to normally ask
you this question. When do you want to fire this? Which pages under which circumstances?
Which data should be sent over, and this is all kind of baked in. So it's, it's kind of
genius. Um, when I first started using it that, uh, I, I was not aware of all of these
best practice, but now I totally understand why people do this in the development space.
Yeah. I think the, like the problem is the GTM doesn't enforce this. Like you can use
GTM however you want. And when you look at the majority of the blogs out there, and yes,
also many articles on my blog as well, they tell you how to do stuff through GTM, how
to fix things, how to hack things, how to add a cookie banner through GTM, or how to
add a popup or something, or, or how to, you know, add some form fields that send some
hidden data to your CRM, whatever you're, you're, you're making changes to the page
at that point. This brings me an in another tangent. But at that point, you have to remember
a very important thing that I think many people will gloss over is that so many of the world's
websites, so of the world's browsers block, GTM like that, like they, they have, uh, they're
using Firefox private windows. They're using Ghostery, they're using you
block origin or some tool that blocks GTM when you block GTM and you've spent all those
hours writing all that application logic into GTM, you're basically creating a discriminating
users who want to block GTM from having the perfect website experience. So this is, this
is another thing where people who are kind of frustrated with the developer pro development
process, instead of getting their kind of, um, you know, maybe their AB tests or something
running properly through a combination of work with, with like HTML attributes and then
the tool itself, they do everything through GTM or through the AB testing tool. And this
isn't in today's world. This is very, very dangerous if you want to offer a unified experience
to all your site visitors, but it's, um, but it all boils down to, um, you know, how you
approach the organization and my suggestion to anybody who kind of relates to being in
a situation where they just can't get anything through with a, it is to just make that the
focus of your efforts for the next quarter or something like try to figure out, start
with having like daily standups create, uh, a 15 minute time every day, where people from
development teams, UX designers, analysts, data scientists, business owners, anybody
with human, with a stake in the website or the app, 15 minutes every day, discuss where
you're going right now and, and use the 15 minutes to kind of air things out.
And then the next step would be to, to, um, Adam, the next, next step in the agile process
itself. But try to just try to break down those communication barriers, because they
are really the key to solving GTM, not figuring out how to write Java script in our custom
nation. And we'll take that's, that's inconsequential to creating a really good setup, just gave
me probation to not learn more JavaScript. You know, that I did. I did. And I'm going
to take everything I said just now back and come back to you, really people really need
to do all right. So there you have it. Pretty interesting thoughts, don't you think?
I'd love to hear from you. What tensions have you experienced maybe when you did tracking
deployments with Google tag manager, between developers and marketers, how do you see it.
Let me know in the comments down below, and if you want to catch the whole session as
well as many other sessions from top speakers in the industry, then it gets you a free ticket
measuresummit.com today. All right. As always, my name is Julian. Til
next time.