Guide

4 Custom HTML Tag Use Cases for eCommerce

Custom HTML tags, and examples of how you can apply these today in your own marketing tagging process.

Brad Redding:

So we’ve looked at built-in tags and how you can leverage those and take advantage of those within your tagging process. Now, let’s look at another type of tag, which is our custom HTML tag. These can be used for many different things. I’m going to focus on just a few that you can apply today to your own marketing, tagging, or just general event tagging process.

Custom HTML tags come in many different shapes and sizes and forms and they can do really an array of things as it allows you to input any custom JavaScript, any custom HTML, really anything that you would want to add to your site, whether it’s a third-party script or potentially metadata or anything else. A data layer push, which we’re going to look at shortly.

Let’s start with a data layer push. An example of a custom data layer push, which we’re going to send as an event. Let’s take a look at the front end again and just go through our GTM summary here of all of our just built-in and some of the native autobox events that are firing. The first time you load up Google Tag Manager and enter preview mode, reload your homepage, you’re going to see events like page view, DOM ready, window loaded and if you have clicks enabled, you’ll see different click events that are executing as you can see here.

These are all built-in events that you can create triggers. We went through the seven different types of triggers that you can create for your store. A custom HTML tag allows you to push any type of custom data layer event that you might not be able to execute within your code base, or just doesn’t make sense to execute in your code base. For example, we talked about site speed performance and how Google Tag Manager can help your site control third-party scripts and third-party ordering and when things execute. Let’s look at an example here of a custom HTML tag, which we’ve set up as a simple data layer push.

We have an event, it is a five second delay, so that’s the name of the event, just like page view is an event. This event name is going to be a five second delay. The trigger that we have assigned to this is a built in trigger that we’ve looked at already and the interval is 5,000 milliseconds, which is five seconds, and it’s set to run on every page and just trigger one time.

Now when we reload the page, and we’ll wait five seconds, you’ll see the five second delay event triggered. Now, what might we want to use that for? One of the previous examples with site speed optimization that we discussed was using Zendesk with their live chat tags are scripts that are running on the site.

In this case, we are using the custom HTML tag to push an event. After five seconds of page load, and then attached to this event we have our Zendesk live chat. So the user is going through the site. They’re browsing, five seconds goes pretty quick if you’re browsing a site or just waiting for the site to load in general.

At that point in time, Zendesk loads after five seconds instead of having Zendesk loading on page view. Again, this is all about ordering of your scripts and something that makes sense to try to improve the user experience and this simple example of a custom HTML tag use. We just created a data layer dot push, we have an event, we can name this whatever we want. We can name it, in theory, if you just want to call it the Zendesk event, we can save it. Refresh. And the event is really driven by the trigger that we have associated to it. Now if I go ahead and refresh the front end here. After five seconds, you’ll see we now have an event called Zendesk and you’ll see the tag to not execute because if we look at our Zendesk live chat tag, we have the Zendesk script here.

We have our trigger and the event name is actually five second delay. We’d have to change this to match the new event name that we created, which is Zendesk. After refreshing one more time, we’ll see our Zendesk event executed and now our Zendesk live chat tag triggered.

You’ll notice that the Zendesk live chat tag itself is a custom HTML tag. That’s one example of a custom HTML tag use. You have a custom data layer push where it’s really based on the trigger we created. We have another custom HTML tag, which is our Zendesk live chat tag associated to that new event. Now we have a pretty creative way of controlling when this script, which is important to the user experience, but maybe doesn’t need to load initially and how we can apply that to the site.

Example number two. Probably seen this in some of the other videos we’ve gone through so far. This is just a simple custom HTML tag type and we’re sending a watched video track event to Klayvio. So, the site-wide Klayvio script is already running. It has a standard events, and we want to enrich the data that we’re sending to our email provider. Then we can start segmenting our list.  If people are watching videos on our site, we have a way that we can create a segment or credit custom a list, or add that as part of nurture sequence or a drip sequence, where if they’ve watched a video, or potentially if we added another custom tag here that watched 50% or a hundred percent of video, that might mean it’s something different than a user who did not watch a video.

This is another simple example. We have the custom HTML tag type. This does not exist as a built in tag that you can select that we looked at previously. Many other marketing channels allow you to push in custom events just like we see here. If we look at the front end, I had triggered a YouTube play, and you’ll see we have our event that executed here.

Now let’s take that one step further and start going into our tag types or our general marketing tags, like a Facebook or ad words, etc., that don’t exist as a builtin tag type. So we need to implement all of the page views, all of the base pixels, all the custom events through either custom HTML tags or through custom templates. With Facebook, we have six or seven different tags, which are all custom HTML tag types. This is where all of the Facebook required pixel code is ultimately implemented. We have the entire script and the no script that we see here. In the case of the base code, there are a few different variables that we have to switch out here in order to implement and have this Facebook site-wide pixel tag execute accordingly.

It functions just like the built in tags, where you have the advanced settings for setting the tag priority. You can set tag firing options, sequencing, adding any trigger that you want, that functions the same as our built in tag types. The main difference is you have the ability to implement fully custom JavaScript or HTML inside this custom tag.

These all function very similar and we’ll get a little bit deeper into Facebook specific tagging in a future chapter. We’ll just look at one other one here. This is a view content, so a product view where we’ve defined the parameters, mapped those to our variables. In this case, we’ve assigned it to our product detail view trigger.

Now let’s look at maybe something that’s a little bit more obscure. If you’re running any affiliate marketing or really any marketing channel that has a little bit more of a custom implementation process, then you will likely get some requirements documentation that has, in this case, we’re looking at Rakuten which I think this is a 15 page document, and it’s providing you different examples of how to implement their tagging or their conversion tags or different custom event tags.

In many cases you’re going to get this. You’re going to get a copy of the script, which one thing to look out for and one of the downfalls or potential risks of the custom HTML tag type is simply taking this script here, copying it, and pasting it into Google Tag Manager. But what happens when I do that is you can see the order ID, the currency, the customer status.

These are all variables in the order ID here and if you just look at the labels here, these have not been mapped to variables that exist in your data layer. These would be the exact values that are returned if you were to just simply copy and paste this into your Google Tag Manager account, without changing these out for data layer variables that match your specific store.

Looking at this in practice, here’s the conversion tag that we have inside of GTM. And let’s just expand this out. We’ve taken the same required conversion tag, so we just look at some of the specific conversion variables, and we moved that into our own tag. Let’s just look here at order ID, customer status, et cetera, to begin.

These have been mapped to our own data layer variables that exist in our store. These would function in the same way, just like you would implement or update any other variable and other tags that we looked at. These need to map to variables that exist in your store. Now, one thing to look out for in Rakuten or others that are looking for a line item data, and we provide a copy of an example container that you can apply to your own store for this, is our line item data.

Here, if we look at line items, they’ve listed out there looking for quantity, unit price, skew, product name, etc. But what happens if you have multiple items in an order? Very common, this may not work at all, or it will only pick up the first product depending on how you’ve set up your variables. It’ll only pick up that first product.

This is another thing to look out for when it comes to custom HTML tags. Many times there is some sort of requirement to modify the script as they provided an extract out line item. This is looped through, if you had five products in an order, then ultimately they’re going to want to see five different products here.

The way that you do that, and there’s many different ways to go about this, is we are going through and mapping out or pulling all of our e-commerce purchase products. This is our native purchase objects where we have all the products contained in the order looped through. And then we’re basically mapping out the IDs or variable parameter names, our enhanced eCommerce primary names, ultimately to what Rakuten is looking for.

They have a very specific naming convention that they’re looking for. Unit price, category, quantity, product name, and we’re simply mapping that to the variable names that exist inside of our data layer as you loop through the entire e-commerce purchase product object. We’ve gone ahead and built out this variable, we have our transformed line items.

Then the line items line that they’re looking for, again, just going back to our requirements document, we have the line items here. We’re simply setting that to the variable that we’ve created up top. This is definitely a little bit more complex for standard marketers that don’t have a deep technical background or can’t write custom JavaScript, but more than anything is just be aware, if you’re provided some sort of requirements documentation that has product requirements or product details in it, that we’re likely going to need to do some sort of customization to get this set up properly where we’re ultimately passing back each individual product in that purchase tag.

That’s one of the big things to consider when it comes to HTML tags is really be sure that the requirements that are provided, digest them, review them, or have someone else review them, send them some to us. At least we can give you a heads up on does it require customization, or does not. Another thing to consider with custom HTML tag types is it is really allowing you to implement, or anybody who has access to GTM, implement any custom JavaScript. That opens up the risk of bad code, code that might break, other code that lives on her store. For example on Magento sites in the past I’ve seen more add to cart triggers. They ultimately trigger two add to carts. When a user is adding an item to the cart, it’s actually adding to because of poorly written or poorly executed custom HTML tags.

And also just keep in mind the ordering. If you do have custom JavaScript that you are adding to your GTM account to your store, to your code base, just be cognizant of how it’s going to impact the user experience. Because if you’re front loading a whole bunch of custom JavaScript at initial page view, just going back to the front end here, if you have a whole bunch of custom JavaScript that’s running on our page view event, all of that needs to execute and will execute and potentially hold up other things from executing on your store.

We’ll take a look at custom templates, which is close, cousin, and probably then really the next phase of custom HTML tags as Google starts to wrap more privacy and just general safety around custom JavaScript and custom HMTL tag usage inside of GTM.

(“Elevar”) is strongly committed to protecting and respecting your privacy rights.