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. The only way for a large website to deploy tags is using a tag management system alongside a data layer.
Using a TMS makes your implementation scalable. Even if you only implement a single tag today, you’ll certainly implement more later on. You need to consider the big picture.
This principle applies even for template-based sites. While 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.
A note about 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 fire those tags synchronously or asynchronously.
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 to deploy all tags through the TMS. If you suspect other teams are trying to circumvent the TMS, use a tool like ObservePoint to automatically monitor which tags are present in your production environment. The Tag Initiators feature is especially helpful for showing which tags are hardcoded and which tags fire through a 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 you’re not sure what a data layer is, you can check out this blog post. But to give you a quick summary, a data layer is a JavaScript object where you collect your most important data elements about the current page/visitor so you can pass that data back to your various solutions in your marketing and analytics stack.
If you configure your tags correctly, then you should be able to make changes to the data layer without requiring changes across your various tags. Note that if you have a TMS on your site, the TMS may have already added a data layer object for you.
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.
A key benefit of ObservePoint is the ability to audit the data layer at scale. With scheduled Audits, you can periodically verify that the data layer object is present and all its variables are correctly populated and formatted.
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 signUp, signup and sign-up on different pages.
Learn more about data layer naming conventions.
Naming pages
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.
In some cases, analysts use the page’s title tag as the page name, but this practice isn’t ideal since page titles often change. Create a unique name for each page that won’t change with time.
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.
Your typical implementation has two types of image request triggering: one for page load and one for events. Events could include anything from scrolling, clicking, hovering, or a complex Javascript event listener. Generally the event-based triggers are small image requests saying: “Oh, he just did this thing,” or “She just typed this.”
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.
To test whether event-based tags are working correctly across your site, you can use ObservePoint’s Action Set Library together with a Journey to simulate a user action on your site and verify that the right tags fire.
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.
If you’re concerned that your site is currently loaded with outdated technologies, a site-wide Audit can reveal where those technologies are so you can remove them.
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.
Below is a quick demo showing how companies use ObservePoint to test that their tagging implementation functions as expected.
Building out an ongoing governance practice takes time and effort. But in the long run, and with the help of an automated governance solution like ObservePoint, your website, your business, and your customers will thank you for it.
