Are you running AppMea­sure­ment 1.4.1 or later? Are certain tags no longer display­ing in the Adobe Digital Pulse Debug­ger? Are certain tags myste­ri­ously being sent as an HTTP POST instead of a GET? Does this make tag vali­da­tion more diffi­cult than you think it should be? Is this causing you to displace your aggres­sion in socially unac­cept­able ways?

If you answered yes to more than one of the above, you have come to the right place!

Why is this Happening?

On Septem­ber 18, 2014 Adobe released a set of updates includ­ing a new version of AppMea­sure­ment, 1.41. Within this updated javascript library is HTTP POST support. This is a really great thing as it fixes a long­stand­ing issue where request data from older Inter­net Explorer browsers would be trun­cated (leading to data quality issues and analy­sis headaches).

Read full release notes here.

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 Debug­ger does not see request data that is sent as HTTP POST.

This leaves you with a few other options (you prob­a­bly already know about some of them):

  • Use the network tab of the Chrome Devel­oper Tools window.
  • Use Charles Web Debug­ging 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 para­me­ters 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 decod­ing is done you are still left with a pretty ugly mess of a query string to read. This slows tag vali­da­tion to a tortur­ous crawl.

If you believe in karmic retri­bu­tion and you feel that due to bad deeds in your past you somehow deserve the aggra­va­tion of perform­ing these added steps for every tag request that happens to trip the thresh­old of 2,047 char­ac­ters in length stop reading right now.

How do I fix it?

The trick to fixing this so that you can go back to tag vali­da­tion as usual is to stop the HTTP POSTs on your local machine. The expla­na­tion below assumes that you are loading the AppMea­sure­ment 1.4.1 or later via Adobe Dynamic Tag Manager and that you have Charles Web Debug­ging Proxy at your disposal.

The first rule of AppMea­sure­ment is, “Don’t alter AppMea­sure­ment”. In fact the first line of any AppMeasurement.js says:


Well, it so happens that there are a couple condi­tional state­ments within appMeasurement.js that trigger the POST behav­ior at a thresh­old of 2,047 bytes. While I heartily endorse the first rule of AppMea­sure­ment for produc­tion 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 thresh­old from 2,047 bytes to 202,047 so that all tags sent from my work­sta­tion are sent using HTTP GET allow­ing me to use the same debug­ging tools for all my tag vali­da­tion.

The best way to make this change locally without getting caught up in change manage­ment discus­sions (or any discus­sions 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 loca­tions 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 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 loca­tion. This rule oper­ates on the body of the response and changes all occur­rences of “2047” to “202047”.


Essen­tially, we are chang­ing this:
to this:

Does this really work?

Of course it does. See the screen­shot below for proof. Here we have an Adobe Analyt­ics tag sent from AppMea­sure­ment 1.4.4 that is well beyond the normal 2,047 char­ac­ter thresh­old and since it is sent as a GET, we can see it nicely format­ted in the Adobe Debug­ger (or any other debug­ger that you choose).