From "not having to bother IT" to inspiring thousands of digital marketers to learn some JavaScript, GTM has been transformative in our industry of data, analytics, and marketing.
Follow me on this trip down memory lane!
2/ The original idea was to make it easier (and less error-prone) to deploy marketing scripts on a website. GTM did this by introducing "tags", "rules" (AKA triggers), and "macros" (AKA variables).
The original UI was unpolished, but the power of the tool was tangible.
3/ From "firing rules" to tag fields, many of the things we see today in GTM were there already in the early days.
Google Tag Manager made it easy to deploy not just marketing tags but _any_ arbitrary JavaScript code with the Custom HTML tag.
4/ In early 2013, Tag Assistant was released, and it came with a Google Tag Manager integration.
From day 1, one of the main pain points with GTM has been in establishing a high quality data structure on the site. Tag Assistant was designed to help with this.
5/ In August 2013, GTM for apps was released.
It was always going to be a difficult release. Google Tag Manager just doesn't have the same type of freedoms and privileges on apps as it has on a web page. On top of that, the original SDKs were very difficult to implement.
6/ In October 2013, auto-event *tags* were released, and they were a game-changer.
You could add listeners on the page for clicks, form submissions, and more. These listener tags would automatically create Data Layer events to fire your marketing tags with.
7/ In early 2014, the Lookup Table macro was released.
This was the first in a line of GTM releases where a specific programming term ("lookup") was introduced to the masses. It led to some confusion over the lack of a partial match (wouldn't be a lookup then!).
8/ In early 2014, the History Listener tag was released.
You could automatically listen to window.history API events, such as pushState, popstate, replaceState... This made it easier to track SPA transitions, but measuring these things reliably was as flaky then as it is today.
9/ In mid-2014, the Preview and Debug pane was introduced.
This was an overlay on top of the page, which told you what types of events were being pushed to dataLayer and how GTM's tags, rules, and macros reacted to them. An absolute necessity for debugging GTM implementations.
10/ In October 2014, the first "GTM Summit" was held in Copenhagen.
Unfortunately it was very much an all-male panel. I'd like to think that if we did another summit today, the audience would be far more diverse.
11/ Also in October 2014, the Google Tag Manager programmatic API was released.
It is an amazing resource for creating new UX on top of GTM's functionality. However, I have a feeling it's still grossly underutilized today.
12/ In October 2014, another huge release. Google Tag Manager version 2.0 with a complete UI overhaul.
Auto-event tracking was also moved away from tags into triggers (formerly known as rules). This made it even easier to listen for and handle user interactions on a page.
13/ With triggers, you didn't have to worry about *when* the listeners are activated, as they are initialized as soon as you create one of these triggers.
It required a mental model shift, but it made it easier to create the triggers AND for Google to introduce new ones.
14/ In early 2015, the "matches CSS selector" trigger predicate was introduced.
Understanding CSS selectors and how they can be used for pinpointing specific elements on the page has become a core competence for Google Tag Manager professionals.
15/ Side note – in these days, the interaction between the Google Tag Manager product team and the community of users was incredible. Discussion around features and releases was prolific and honest. I really, really miss this (and I miss Google+, too!).
16/ In July 2015, Folders were released.
I still don't know what to do with them. They're a nice way to group related assets together, and admittedly today they have more functionality than in the first years of their existence. But still, a lot of untapped potential.
17/ In July 2015, we got syntax highlighting in Custom HTML tags (yay!).
Still no ES6 support, though...
18/ In August 2015, tag sequencing was released.
This is still to this day the only sure way of creating dependency chains in Google Tag Manager. If you need a tag to complete its work before another tag is allowed to begin its own process, you need sequencing.
19/ In November 2015, Environments were released.
The idea was that you could create separate container snippets for different environments (e.g. Staging, UAT), and publish your container versions in those, first.
20/ In May 2016, Google Tag Manager for apps was updated to run on top of Firebase.
This made it *much* easier to deploy GTM, but it didn't change the core pain points. GTM just isn't GTM when it comes to apps. Over the years, the situation hasn't improved at all.
21/ In August 2016, Workspaces were released.
They introduced rudimentary version branching and version control tools into GTM, and made it much easier to work collaboratively on a GTM container.
They also made Environments practically unusable, though.
22/ In August 2016, the new Material Design UI was released.
Have pity on people like me, who had to redo hundreds of slides of screenshots, training materials, course videos, blog posts...
23/ In October 2016, AMP containers were released.
You could now add a basic tracking setup on an AMP page. It was still tremendously difficult to set it up correctly, considering that AMP pages did not allow the execution of arbitrary JavaScript.
24/ In March 2017, version 2 of the Google Tag Manager programmatic API was released.
It introduced support for Workspaces, some new semantics, new types of resources...
I really wish people would build more tools on top of the API! It really is an amazing thing.
25/ In April 2017, we got Approvals (GTM 360 only).
GTM 360 is the paid version of Google Tag Manager. Luckily the vast majority of features is available in the free version, too. Enterprise-level stuff like Approvals and extra Workspace quota is restricted to the paid offering.
Two very, very important releases to server-side #GoogleTagManager. One of them is arguably *the most important* update to the platform in a long, long, time, and the other opens up a myriad of use cases for data enrichment at scale.
Read on!
First, we have ASYNCHRONOUS VARIABLES and PROMISES.
In short, you can use *variables* to run asynchronous operations (such as send HTTP requests or communicate with BigQuery), and anything the variable is attached to *will wait for it to complete*.
This is so useful, as it lets you do complex enrichment / API chaining without having to create custom clients or tags!
The new Promise API can be used to add this functionality to your template code, BUT: the send*, BigQuery, and Firestore APIs are automatically "promisified"!
The new Server container is now in public beta. You can create a new container in the Admin section of any Google Tag Manager account you have access to.
Server-side tagging is (for now) a @GCPcloud managed environment, which serves as a server-side proxy for all your analytics, marketing, and advertising needs.
See this video for a walkthrough of how to set it up:
So, #GoogleTagManager introduced “server-side tagging”, at SuperWeek, which finally gives me a chance to unload some thoughts about it :)
Server-side tagging translates to a new “Server” container running on a cloud VM in your own domain namespace. 1/6
You send HTTP requests to it from the browser, and it parses these requests (using a new “Client” format), typically dispatching them to their respective endpoints server-to-server (e.g. Measurement Protocol). 2/6
Some amazing things you can do with it:
- Hit validation and fixing before the hit is sent to the endpoint
- PII and privacy controls for the requests before dispatch
- Send same request to multiple endpoints
- Customize the HTTP response back to the client (e.g. Set-Cookie) 3/6