Are you running AppMeasurement 1.4.1 or later? Are certain tags no longer displaying in the Adobe Digital Pulse Debugger? Are certain tags mysteriously being sent as an HTTP POST instead of a GET? Does this make tag validation more difficult than you think it should be? Is this causing you to displace your aggression in socially unacceptable ways?
If you answered yes to more than one of the above, you have come to the right place!
Why is this Happening?
Why does it Suck?
As I said earlier, this is a great thing, but the bad part about it is, as noted in the release notes, the Adobe Debugger does not see request data that is sent as HTTP POST.
This leaves you with a few other options (you probably already know about some of them):
- Use the network tab of the Chrome Developer Tools window.
- Use Charles Web Debugging Proxy
- Use another tool (Fiddler, HTTPFox, Firebug, etc) that does the same thing.
The problem here is that although these tools do a great job of showing the query string parameters of an HTTP GET, when it comes to POSTs you have to copy the payload into another tool (such as Eric Meyer’s URL Decoder/Encoder tool to decode it. Once the decoding is done you are still left with a pretty ugly mess of a query string to read. This slows tag validation to a torturous crawl.
If you believe in karmic retribution and you feel that due to bad deeds in your past you somehow deserve the aggravation of performing these added steps for every tag request that happens to trip the threshold of 2,047 characters in length stop reading right now.
How do I fix it?
The trick to fixing this so that you can go back to tag validation as usual is to stop the HTTP POSTs on your local machine. The explanation below assumes that you are loading the AppMeasurement 1.4.1 or later via Adobe Dynamic Tag Manager and that you have Charles Web Debugging Proxy at your disposal.
The first rule of AppMeasurement is, “Don’t alter AppMeasurement”. In fact the first line of any AppMeasurement.js says:
DO NOT ALTER ANYTHING BELOW THIS LINE !
Well, it so happens that there are a couple conditional statements within appMeasurement.js that trigger the POST behavior at a threshold of 2,047 bytes. While I heartily endorse the first rule of AppMeasurement for production code, I feel that when it comes to my local version, I can do what I please (and so can you). I have chosen to boost the POST threshold from 2,047 bytes to 202,047 so that all tags sent from my workstation are sent using HTTP GET allowing me to use the same debugging tools for all my tag validation.
The best way to make this change locally without getting caught up in change management discussions (or any discussions at all) is to use a Charles Rewrite rule to watch for the s‑code-contents request from your browser to the DTM server and modify the response as it comes back across the wire. Below are the details of this simple rewrite rule.
The screen capture below shows the locations where the rewrite rule will run. We only want to run the rule on the request that gets the appMeasurement.js from the DTM server. Note the host name is assets.adobedtm.com. Note that the path must contain “s‑code-contents-“ which is always on the request that we want to change.
The next screen capture shows the rule that Charles will run for this location. This rule operates on the body of the response and changes all occurrences of “2047” to “202047”.
Essentially, we are changing this:
Does this really work?
Of course it does. See the screenshot below for proof. Here we have an Adobe Analytics tag sent from AppMeasurement 1.4.4 that is well beyond the normal 2,047 character threshold and since it is sent as a GET, we can see it nicely formatted in the Adobe Debugger (or any other debugger that you choose).