Simo Ahava Profile picture
Husband | Father | Blogger | Keynote speaker | Co-founder @8_bit_sheep & @team_simmer | https://t.co/28NTuGuLDJ | https://t.co/5G0y15XBxK | @simoahava@masto.measure.chat

Oct 1, 2022, 25 tweets

🎉 #GoogleTagManager is 10 years old, happy birthday! 🎉

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.

Thread continues here:

Share this Scrolly Tale with your friends.

A Scrolly Tale is a new way to read Twitter threads with a more visually immersive experience.
Discover more beautiful Scrolly Tales like this.

Keep scrolling