When we hear Google Tag Manager, the first thing we think of is being able to manage third party tags through GTM. And the first tag that comes to mind is Google Analytics. Indeed, using GTM provides a huge advantage to us analytics types because it frees us up from having to get into a code release to get analytics changes pushed out. At the same time, it probably frustrates hardcore developers because it allows marketers and non-developers to circumvent the release process!
Using Google Tag Manager to Modify Site Experience
So where would one want to use this functionality? It would be ideal to use where the need to override the user experience is temporary or requires access to visitor attribute information such as channel, visitor type, products viewed, etc. Here are some scenarios where having this ability is a huge benefit:
- To show a coupon code in the header of each page but only for a specific channel (e.g. organic search)
- To show a call to action on a subset of product detail pages
- To show a variety of coupon codes in checkout based on products added to cart
So in summary, if you need to modify the user experience for a segment of traffic or for a short period of time, then Google Tag Manager can be a great tool for this exercise.
The Code to Make It Happen
To learn how to leverage GTM for experience optimization, let’s use the example of a company called Cool Widgets. Cool Widgets sells widgets on its website. It has product buckets of $0-$100, $101-$199, and $200-$400. Cool Widgets has found that its average order value is $75. In order to push up the average order value to $100, they have estimated that they need to offer a 10 percent discount on products priced $150 and above.
Cool Widgets is leveraging the GTM data layer to store cart information on checkout pages. So they have access to products that are in the cart on their checkout pages. Alternately, this information can also be pulled from the page itself. But then we get into best practices of using Google Tag Manager, and one of the things we advocate it to remain in sync with the development team rather than circumvent it. So having the development team actually own the task of populating the data layer ensures your code will have one less point of failure. More about Tag Manager best practices in an upcoming guide.
I’m going to assume that you already have a working understanding of GTM basics. If you need a refresher, take a look at our Google Tag Manager guides before proceeding.
We’re going to implement a message in checkout. The message will say “Looking for a coupon code? Use coupon code COOL10 to get a 10% discount. Terms and conditions apply.” And we want it formatted nicely like this:
The first step to create is a tag. This tag will contain the snippet of code that shows this message along with the formatting.
So under GTM interface, create a new “Custom HTML Tag.”
Rename the custom tag to something more appropriate. In this case, we renamed it to “COOL10 for 150 and above.”
This completes the tag coding. The other critical part of this setup is creating a trigger that will allow the tag to fire. So create a custom trigger in the GTM interface.
Cool Widgets uses a trigger called “Checkout Page on load.” And this trigger is Page View based. The way to read the above screenshot is that the trigger will fire when a page view occurs. It will only fire after the “DOM Ready” trigger executes. And finally, it will only fire when the URL contains the word “checkout.”
This trigger warrants a bit more explanation. There are multiple ways to create this trigger. So let’s start at the top – choosing the event. You could either select a “Page View” as the event or create a custom event. When you select a page view event, then there are three built in triggers available for you to choose from.
If you choose to build a custom event, then you can specify the event on which this trigger needs to fire. This can be a custom event you have defined or it can be a built-in GTM event. GTM provides you with three cool built-in events – gtm.js, gtm.dom, and gtm.load. These three events are actually the equivalents of the three triggers available when the “Page View” event is selected in the first step!
A quick note about the three events – gtm.js (“Page View” trigger type) basically means a page view has occurred. The entire page may not have loaded at that point. Just that the page view event got fired. This is not ideal for us to use because we need to modify the document. So the document has to render first. That leaves us with two choices – gtm.dom (“DOM Ready” trigger type) or gtm.load (“Window Loaded” trigger type).
“DOM Ready” means the document structure has loaded but without images and other assets. “Window Loaded” means the document has rendered fully along with images and any other assets. For the experience to be as seamless as possible, we want to load the coupon code message at the first possible opportunity. So we use “DOM Ready” trigger type or the gtm.dom event.
Once you have created the tag and the corresponding trigger, just associate the trigger to the tag you have created and you’re ready to publish the tag and see the results.
Let’s recap what we did here. We used Google Tag Manager to display a highly segmented promotional message based on the price of the product. Because the message needed to be displayed to a segment of Cool Widget’s traffic for a short period of time, it was best coded in a tag manager style setup rather than in the core code base. There are several simple variations to this example that can do some very powerful changes to the site. If you have any questions about this approach, feel free to contact us!