Helpful Implementation Tip – Rewrite HTML on Page Load with Charles Proxy

There are a variety of methods and tools used for debugging and QA’ing an analytics implementation.  While simply using the developer tools built into your favorite browser will usually suffice for some of the more common QA needs, there are times that a more robust tool is needed.  One such situation is the need to either swap out code on the page, or add code to a page.

To use an example, there are many times that a new microsite will be launching, but due to dev sprints/cycles, the Tag Management System (TMS), and dataLayer, that you are going to be working with hasn’t been added to the site yet.  However, you may need to get some tags set up in the TMS and ensure they are working, while the engineering team works on getting the TMS installed on the site. In these situations, it would be very difficult to ensure that everything in the TMS is working correctly prior to the release.  This is one of many situations where Charles Proxy can be a useful tool to have available.  

Charles Proxy is a proxy tool that sits in the middle of your connection to the internet.  This means that it captures and processes every bit of information that is sent between your computer and the internet and therefore can allow you to manipulate that information.  One such manipulation you can perform is to change the body of any response that is received from a web server, i.e. the HTML of a web page.

To go back to my example above, let’s say that I wanted to install Google Tag Manager (GTM) on a webpage.  I would open up Charles, go to the Tools menu and then go to Rewrite. I would then create a new rule that replaces the “</head>” text with the dataLayer definition, GTM snippet and then the “</head>” text. (See below for how this is setup).  This will result in the browser (only on your computer and only while Charles is open with the rewrite enabled) receiving an HTML response that contains the GTM snippet.

Example Setup

Step 1: Open the Rewrite tool from the “Tools” menu.

Step 2: Click the add button on the bottom left to add a new Rewrite rule.  Then click on the Add button on the middle right to add a configuration for which domains/pages to apply this rewrite rule to.

Step 3: Click the Add button on the bottom right.  This will allow you to specify what action you want to take on the domains/pages that you specified.  For this example, you will want to choose a “Type” of “Body” and “Where” of “Response” as you are modifying the Body of the response. Under “Match” you are going to put the closing “</head>” tag as this is where you are going to install the TMS.  Then, under “Replace”, you will put the snippet you want to place before the closing head tag (in this example, the TMS and dataLayer tags) followed by the same closing “</head>” tag. When you are done, click “OK” to close the Action window.

Step 4: Click OK on the Rewrite Settings window to save your rewrite rule.  Then refresh the domains/pages in your browser to see whether your new rewrite rule is working as expected.

Why use Charles instead of standard browser developer tools?

While you could perform this same task using the developer tools in your chosen browser, that would have to be done on each page that you need to QA, each time a page is loaded.  A Charles rewrite, on the other hand, would be automatically placed on each page load. It also ensures that the GTM snippet and dataLayer are loaded in the correct place in the DOM and that everything fires in the correct order.  This is essential to ensuring that your QA doesn’t return different results than it would on your production site (or staging site once the GTM snippet is placed).

There are many ways that Charles rewrites can be used.  Here are a few examples of when I utilize rewrites –

• Changing the container bootstrap/container that is used for staging sites (this is less common, but sometimes needed depending on the situation);
• Adding/changing core JavaScript that is needed for analytics to function;
• Modifying HTML to test out specific scenarios with tracking (instead of having to do so in the browser’s developer tools on each page load);
• Manipulating the dataLayer on each page prior to a staging site update.  This can be useful for testing out a tagging plan prior to sending to a dev team (which helps to ensure less back and forth in QA when something wasn’t quite defined correctly in your requirements).

I hope you have found this information useful.  What are your thoughts? Do you have any other great use cases that I may have missed?  Leave your comments below!