-
Lesson Overview
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.
Transcription
Welcome back to the Inside and Manage training series. In this video, I'll be covering reformatting vendor code. This will be a quick look at how to read the code provided in your vendor's tag and extract from it the pieces relevant to you so that you can build a tag in an app. First, let's take a look at some helpful functions that you may need if you have to build a custom tag when reformatting the vendor's code. These all live in the bootstrapper library, so they're already on your pages and you don't need any extra definitions.
Bootstrapper InsertScript is a quick and efficient way to call a new JavaScript file to your page. It accepts a single string argument, which is the URL of your script. Bootstrapper Load Script Callback performs the same function, while also allowing for a callback function argument to be declared. This function will execute its content once the script you're requesting has finished downloading and executing on the page. Bootstrapper Image Request will help you make calls for pixels or more likely, to send some data via a pixel request and accept a single string URL.
You'll recall when we were talking about tag creation that Tags execute on specific timings. Those functions can also be helpful for building your own tags and when you're doing debugger QA. Like the Helper functions, these exist in the Bootstrapper library, and each of them accepts a single argument in the form of a function. This function is what would be your normal tag code if you were using one of the vendor templated apps. Bootstrapper Bind Immediate and its twin Bind Dependency Immediate are intended to execute their contents immediately or as quickly as possible when the dependency is available.
This maps to the as soon as possible timing in the UI, Bindom Parsed and Bind dependency Dom Parsed maps to the once the page is interactive timing and is similar to Dom Ready if you're familiar with that term. Binding your tag this way means that it will execute only after the content of the Dom, which is the base HTML of the page before any modifications by scripts or anything else has been parsed by the browser, but still potentially before everything has completed its load on the page. Bindomloaded and Bind Dependency Domloaded pairs with the once the page is fully loaded UI option, and in simple terms, it's going to try to make your tag the very last thing that loads to the page. This timing can be a little unreliable, as it's always going to wait for other scripts or files to load in before attempting to do its own work. And if those files are loading slowly, that means this tag could be waiting a very long time.
Still, if your goal is to make sure a tag is the last fire on a page, this is your simplest option. There's one more binding available, but you won't find it in the UI. Bootstrapper Bind page specific completion is normally only used by the bootstrap itself, but it's certainly one you could use in your custom tags. This binding's timing window is when Insight and is done with its work. This isn't aligned with a timing window relevant to the page itself.
It may happen very early or very late, or anywhere in between, depending on what your other tags are doing. The binding here sets your tag up to wait until all other tags that aren't using this binding have finished loading Insight and cannot deploy no Script tags. The no Script tag is an HTML element that says only run this code if JavaScript has been turned off for this page. Since the bootstrap and all of your tagging are JavaScript, they of course could never be running in that scenario. Some vendor tags will include two options for output a JavaScript version and a static image pixel version wrapped in no Script tags.
The easy reformatting here is simply removing any references to no script, as they will be unusable anyway. Local or Windows scoping does not always work when placed into a function. In previous videos, I've mentioned that we execute all of the content of your tags within functions that's their scope inside of a function. Some vendor tags make the assumption that they're going to be installed directly onto the page, which makes the scope the entire page, which is referred to as the window. When you declare a local variable, it only exists within the scope provided.
So if you declare a variable on the window, it's everywhere, but if you declare it within a function, it only exists within that function. If some other script or tag were to then attempt to refer to that variable later, it would likely throw an error because the variable did not exist in its scope. The solution here is to be sure that variables declared in your tag are at the appropriate scoping. Perhaps you need to add a window dot to make sure that they're at the window level. However, I would caution you not to do this just because you can, as it risks variable collision among similar tags.
If you're comfortable doing so, it's safer to modify the vendor's code to use an object that definitely belongs only to that tag. Some vendor tags are written as if they should be synchronous but shouldn't be. This practice has been fading over the years, but we do still see it on occasion. It was once very common in the industry to make it seem like a vendor's tag could only function properly if placed synchronously in the head of the page, when in reality the only goal was to ensure the tag ran first and was difficult to remove once it had been placed. It is important to remember that some tags do actually require synchronous functionality, so be sure to ask yourself what is this tag doing?
And could it be asynchronous instead? You can easily convert these tags to a non blocking Asynchronous form using the Helper functions I discussed previously. As you can see on the screen, some vendor tags include calls to Document Write, but shouldn't on the same thread as the previous slide. Some tags wanted not only synchronous timing, but the ability to write even more content directly into the page using the Document Write function. Thankfully, this practice has almost completely faded as Document Write is neither safe nor practical to use outside of some very few specific circumstances.
The same Asynchronous functions will assist you in replacing Document Write as well. That's all for vendor refactoring and reformatting with the tips this lesson, you're well on your way to being able to tackle any tag a vendor provides to you. Thanks for watching and I'll see you in the next video on Event Tracking.