8. Tags & Tag Creation
This comprehensive course covers everything you will need to become a Manage power user - from deploying tags, data layers and event tracking to organizing your TMS strategy and properly QA and troubleshoot.
Learners should have a basic grasp of client-side web technologies.
Hello, and welcome back to the Ensighten Manage Training Series. It's time to cover one of the big topics that encompasses much of what you've learned and will still be fed into by the videos to come. Let's talk Tag Creation. As a quick refresher, the tags UI is where all of your existing tags live. It's where you can edit and update those tags, check their status, and manage their published state. Despite its name, tag creation doesn't begin on the tags tab. You can certainly find the ad tag button there, but that button is only going to navigate you to the app's UI, which you'll find on the left nav, anyway. You may recall from our tour that the apps UI is where we store a massive library of helpful applets or wizards to assist you in building your tags. You can search for a vendor by name here. And if by chance you don't find what you're looking for, our apps team can typically get a new app in place during the next two-week sprint. You'll find a huge variety of options for assistance in building tags here in the app's UI.
For our demo tag, I'll set the name to Global | Randy's Tag Company | Training pixel. A good naming convention can be extremely helpful as your account grows and the volume of tags increases. My personal preference on naming conventions is site property or location, separates vendor, separates purpose. This way, if I'm covering multiple sites or properties, I know exactly where the tag is expected to deploy, what vendor the code is for, and what specific purpose the tag serves. Purposes might be something as simple as base tag or ad pixel, but they're useful for complex tagging setups, like analytics, which can have a base tag, variables tag, event tagging, and more.
I'll add some sample values to my fields here. The values you use in your own tags will most likely be coming from the vendor, that could mean they've provided them for you directly, or they gave you an example tag, or perhaps their system allows for you to generate a tag for yourself. Whatever the case may be, if you're using an app specific to your vendor, then it should have prompt fields and example inputs to help you along the way. With the fields populated, I'll move on to the next step.
This example, I've chosen the space training. If you're practicing alongside this training, you've probably got a dev space you can use for the same purpose. In creating a tag, you'll choose its initial space. And then later, you can choose to merge or duplicate it into other spaces. Later when editing a tag, you won't be able to modify this space choice. That's what the merge is for. But you can always update the conditions, events, dependencies, and timings. In the conditions box, I'll select more to see the combined list of all conditions and events. The other options will get you a subset of what we're looking at to save you some time on searching in the future. Hopefully, you watched the conditions video, so you'll recognize these two orange ones in the list. This is the case for all new tags, with the exception of those with mandated conditions. If I add some of these other conditions, the global one would be removed automatically. You can also see here an important quality of conditions that you should remember. Conditions added here are logically ORed together. If any of the conditions applied to a tag are satisfied by the page requesting tagging, the tag will be served to that page. These are not additive or logically ANDs.
Similar to the global condition, the only exception to this rule is mandated conditions. If a mandated condition is applied to a space, it must be satisfied by all tags within the space. And then the remaining conditions are still OR setups. You'll also notice some events in this list. We haven't gotten to those just yet, but you'll learn about how to create them and how they can be used as conditions in a future video.
Below the conditions box, you'll also see a collapsed section called timing settings. Expanding this, you'll find two features helpful in controlling your tags' order of execution in relation to other tags. The choose which tags must fire-first-field, allows you to declare dependencies. These are tags that must both be present on the page and have executed before your current tag will be allowed to do so.
Dependencies are great when you have to set up configuration tags and want to make sure that your event tags fire off after that setup. The how soon should the tag fire drop-down allows you to control execution time. The default, as soon as possible, tells the tag to fire as soon as it is able within the asynchronous execution timings. In short, this tag will fire immediately once it arrives on the page. The other two options will delay the tag firing to what's known as DOM ready or DOM loaded in web development and page performance terminology. That means when the page has loaded all of its first-party content and is interactable by the user, and when the page has fully loaded all of its resources to the page. The latter two options can have minor page performance benefits but come with a risk of data variance if the user's internet is slow or they navigate away from the page quickly.
With all that done, we can hit Save and find ourselves back in the tags UI with the search filters automatically set to locate your new tag. It will be in the enabled and uncommitted state unless you pressed Save and Commit. In which case, of course, it will be in the enabled and committed state.
Now you can revisit some of the learnings from our UI tour. After your tag has been created and you land back on the tag screen, you have some further options with your new tag. We discussed previously the view details and edit options, but the rest are probably new to you. Commit is part of the publish cycle, and I'll come back to that shortly. Disable and its opposing enable, are for declaring the intention to turn a tag offer on. A very important thing to remember when you're working on tags. To modify a tag that is already live on some page, you must complete the publish workflow. A tag that is already live to your website will not be turned off if the only thing you've done is click Disable, more on that soon. The merge button is how you can duplicate or overwrite a tag in one space to another. If the tag doesn't already exist there, it will be duplicated in its destination space. If it does, the tag in that space will be overwritten with the content of your source. This is an important distinction because, despite the term merge, the contents are not being combined, they're being overwritten.
Set expiration will give your tag a maximum lifetime, at which point it will no longer be allowed to execute on your pages. It will still be served to those pages though. So be sure to clean up your expired tags if you're using this feature. The duplicate option will send you back to the app's UI where a copy of your tag will be generated with the same name and content. This is great when you need to create multiple versions of a tag.
Finally, the delete button is for deleting tags. There's a bit of tricky behavior here, though, in that if your tag has never been live, clicking delete can remove it instantly. But if it has been live, you must finish the publish workflow. Publishing is a simple process with a few steps and some feature stops in between. To send a tag live to your site, you'll need to first commit it and then publish the space it lives in. And as a quick note, these two steps can be done in bulk for many tags, no need to do them individually. Committing a tag or tags locks them in place so they can no longer be edited unless uncommitted or published. It also makes them available in the nexus test environment, which is for localized testing. And we'll cover that in the debugging in QA video.
Once your tags are committed, you can click the publish button, and the publish summary will pop up. If you had selected a tag before clicking publish, you may notice a space has already been selected for you. If you hadn't, you'll need to select your space from the dropdown. This is very important. Publishes occur at the space level, not on individual tags. That means you will be publishing any and all changes that are waiting in a space. Even if you're not the one who made those changes. When the summary window populates with all of the things getting published, be sure that you're okay with that list. Once you're ready, click Publish again in this new window and the operation will begin. You'll see a pulsing icon in the upper right corner of your window. And soon enough, a check icon will indicate your publish has been completed and the published content is live. This usually takes around 60 seconds, but larger accounts or larger publishes can take more time.
Now that your tags are published, their current state on the live site is locked in until another publish takes place. That means if you edit a live tag within manage, it's not going to instantly update on the live environment until you go, again, through the published workflow.
Tags are a topic we'll be revisiting in the future. And the one you should probably be the most comfortable with as you work in the TMS. Join us for the next video on "Data Layers."