In today’s world of microwave ovens and fast food restaurants, instant messaging and texting, and any answer you need (whether right or wrong) available on the Web, we have come to expect instant gratification, perhaps even beyond what is reasonable. Of course, this extends itself to troubleshooting and debugging your Web site as well. We need to try something, see the results, fix it, try it again, add something, see it work, and change it again.
As you need to make changes to your site analytics, you may find yourself waiting on a code release cycle, unable to simply add that prop, eVar, or plugin that will give you the actionable data you desire. Enter Adobe Tag Manager.
I’m going to follow a brief tangent here because I think it will help the overall understanding of this post. Let’s take one second to understand how Tag Manager works (at a high level).
Instead of your page code loading the s_code.js configuration file, when you are using Tag Manager you reference a “loader” file. This loader file is really just a pointer to Tag Manager, referencing a “container” (feel free to do air quotes on all of these quoted terms – it’s fun). The container in Tag Manager houses the code that you used to have in the s_code.js file, and the code library (code below the line – which you should never change) is added automatically by Tag Manager. This is one of the advantages of using Tag Manager (there are lots of great reasons to use Adobe Tag Manager – see your Account Executive for more info) – that the SiteCatalyst configuration code now sits in an interface that a SiteCatalyst Admin can get to and update without having to get on IT’s to-do list. Cool.
So we’re excited to be using Tag manager. Got it. However, have you noticed that every time you make a change to the s_code in Tag Manager, you have to wait several minutes for the file to deploy to the servers around the world? What to do? I have just the thing for you.
Using Charles and Adobe Tag Manager
I’m sure that other packet sniffers have a similar function, but in this article, I’ll show you how to use Charles and the “Map Local” function to get around having to wait for deployment of your Tag Manager file every time you make a change.
Saving the file from Tag Manager
- First, we’re going to put comment “markers” in the SiteCatalyst s_code so that we know what stuff to copy back in – Just trust me on this, you’ll thank me later.
- Next, copy all of the code from the container in Tag Manager (using the Preview function). This includes anything at the top that looks “Tag Manager-ish” as well as the “code blow the line” at the bottom
- Save it into a file on your machine
Mapping to the local file in Charles
- Right-click and choose “Map Local.”
- Point it to your saved JS file that is holding your s_code.
- Now, as long as Map Local (and your specific rule) are enabled, you will be able to make changes to the local s_code, and see those changes right away. Just like Mr. Pibb + Red Vines, that’s crazy delicious.
OK, I’m done testing…now what?
- After you’re done testing all of your changes, and are happy with it, you can now copy the file back into the Tag Manager container and deploy it (in any of the environments – Dev, Stage, or Live). But here’s where step 1 is going to come back into play…Assuming you just changed SiteCatalyst stuff, and not any dependent code from Tag Manager, or code addons (in other words, assuming you only changed stuff between our comments that we put into the code in step 1), you can now copy ONLY the code between our handy-dandy comment codes, and paste that back into the SiteCatalyst code block in Tag Manager.
// TOP OF SITECATALYST CODE IN TAG MANAGER
[All the changed code is here and waiting for you to copy it]
// BOTTOM OF SITECATALYST CODE IN TAG MANAGER
Well, I hope you like this tip. Once you get used to it, you will love having that quick response to your changes as you test new tracking solutions on your site. It’ll be as sweet as popping those pizza rolls in the micro and having them out in a minute. It’s like… magic.