Your website undergoes a lot of stress.
Day-in, day-out, you expect it to work tirelessly, delivering experiences that are consistent, useful and exciting.
In the meantime, you continue to layer on new tags for analytics, remarketing, event-based personalization, and other needs.
To keep your website running well despite a growing tag implementation, you should follow website tagging best practices. These tagging best practices will make your implementation scalable and accurate, and help keep your website at peak performance.
Below are five things you should know and do when tagging your website.
1. Use a tag management system (TMS)
For the enterprise, tagging each page one at a time is out of the question. There’s really only one way for a large website to deploy tags: using a tag management system alongside a data layer.
Using a TMS makes your implementation scalable. Even if you’re implementing only one single tag right now, you’ll be implementing something similar in nature again and again. You need to consider the big picture.
The same goes for template-based sites. Even if you could deploy tags via a template, this isn’t best practice. As you grow your site, you’ll notice that there are always going to be exceptions to the template. You will run into situations where you want a tag to run this way, or you’re introducing a new tag that only gets fired on specific parts of your site (or for specific users). As great as your templated site may be, it can’t keep up with that kind of customizability.
Consider these two additional use cases showing the benefits of a TMS:
- Tag management systems help you keep a handle on tags even when top-level architects leave your company.
- Tag management systems grant accessibility to power analytics users or administrators to make changes themselves.
The need for a TMS is obvious. Use a tag management system.
Synchronous vs. asynchronous tag loading
Most tag management systems and the tags they deploy are compatible with asynchronous loading. You should always go asynchronous as long as your tag doesn’t have dependencies. For tags that do have dependencies, evaluate what those might be and make a judgment call on if you should be using synchronous or asynchronous with those tags.
Don’t fire tags outside the TMS
Sometimes people circumvent the process of using a TMS to deploy a tag because they consider it to be more convenient, when in reality it shouldn’t be. If you’re running a site that’s larger than a blog or personal site, I personally can’t think of a single example of why it would be better to deploy a tag outside of a TMS.
So, as a general rule, make sure all tags are being deployed through the TMS. Automatically monitoring tags in your production environment can help you make sure people aren’t deploying tags outside the TMS.
2. Implement a data layer
When preparing to write this blog post, someone asked me:
“When do I need a data layer, and when don’t I?”
My response: “You need one.”
Unless you have a small website that you don’t expect to grow, a data layer is one of the most important components of your data implementation. It’s the one ring to rule them all. The more complex your site gets, the more you need a data layer.
If your various tags are utilizing your data layer correctly, many changes can be made at the data layer level, without requiring serval changes across your various tags.
If you have a TMS on your site, the TMS may have already added a data layer object for you. There are various methods you can use to push values into that data layer for your TMS—and other applications—to access, including DOM event handlers or the
As with tags, you should frequently verify that your data layer is collecting the right data (such as a
productID on each product page) so your tags have access to the data they need.
3. Use clear and consistent naming conventions
In many cases, you won’t have control over the names of analytics variables or the data types contained within those variables. These are the out-of-box variables that you don’t really have to worry about.
But when you do have control over variable names or values, the main thing is to be consistent. For example, when passing product categories, make sure everyone is passing the same set of categories. The same goes for channel variables—make sure everyone has consistent definitions and naming conventions for each channel. For some companies, it makes sense to adopt a number-based system for such variables.
Here are some additional best practices for naming conventions:
The data layer
You have full control over what you name the variables and values in your data layer. In this case, it’s good to keep things intuitive. If you’re talking about a page category, the variable
pageCategory will make perfect sense. You might consider looking at what your TMS recognizes by default as well.
You will, of course, need to establish a standard across the company of the values that fit within that variable, so you don’t get people putting in
sign-up on different pages.
You can learn more about data layer naming conventions in this blog post.
Some people will take a hierarchy of how they got to a page and they’ll pass that into the page name variable and that becomes the whole page name. But many analytics tags have their own variable to do something like that. So for a page, stop naming your pages based on a hierarchy, because there are other variables that show you how a visitor got there.
4. Implement event triggers properly
Event triggers are a type of tag that allows you to pass data to your data layer (and therefore, your TMS) whenever a custom event happens.
Something to be aware of: I’ve seen a lot of people use page load image requests when they should be using event triggers. Technically you can fire page load triggers whenever you want, including on events, but you will cause an overinflation of default metrics that the page load trigger is set up to track, such as page views.
I once worked with one major retailer that instead of using event-based triggers used page load image requests, and inflated their page views and even some of the events that were set to fire.
As a result, they ended up overspending by tens of thousands of dollars just on the additional image requests alone. This doesn’t include the additional cost to correct the issue and the incorrect metrics they were then stuck with for that time period it was implemented incorrectly. They could have avoided that problem if they had used event triggers.
An example where you may want to make a page load call multiple times is if you have content that loads dynamically, such as when you scroll down and additional content is added to the bottom of the page.
5. Create a plan for sunsetting tags
Most people have a really good deployment lifecycle, but they don’t have a good call to retirement for their tags. If you have a proper TMS implemented, it’s easy. But a lot of people have stray tags on their site just because they didn’t have a good sunset practice. They think about deploying tags, not taking them away.
Make sure to periodically review the tags you have on your site so you can make sure that old tech is being removed. If you were to audit your website right now, you might be surprised by some of the technologies that are still deployed.
Get Your Website Tagging Back on Track
I’ve worked with many companies who have website tagging that has gotten out of hand and are looking to realign with best practices. The best way to go about that process is to conduct frequent tag audits that identify potential tagging errors.
About the AuthorLinkedIn More Content by Jake Garrett