Are you run­ning App­Mea­sure­ment 1.4.1 or lat­er? Are cer­tain tags no longer dis­play­ing in the Adobe Dig­i­tal Pulse Debug­ger? Are cer­tain tags mys­te­ri­ous­ly being sent as an HTTP POST instead of a GET? Does this make tag val­i­da­tion more dif­fi­cult than you think it should be? Is this caus­ing you to dis­place your aggres­sion in social­ly 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 Sep­tem­ber 18, 2014 Adobe released a set of updates includ­ing a new ver­sion of App­Mea­sure­ment, 1.41. With­in this updat­ed javascript library is HTTP POST sup­port. This is a real­ly great thing as it fix­es a long­stand­ing issue where request data from old­er Inter­net Explor­er browsers would be trun­cat­ed (lead­ing to data qual­i­ty issues and analy­sis headaches).

Read full release notes here.

Why does it Suck?

As I said ear­li­er, this is a great thing, but the bad part about it is, as not­ed 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 oth­er options (you prob­a­bly already know about some of them):

  • Use the net­work tab of the Chrome Devel­op­er Tools win­dow.
  • Use Charles Web Debug­ging Proxy
  • Use anoth­er tool (Fid­dler, HTTP­Fox, Fire­bug, etc) that does the same thing.

The prob­lem here is that although these tools do a great job of show­ing the query string para­me­ters of an HTTP GET, when it comes to POSTs you have to copy the pay­load into anoth­er 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 pret­ty ugly mess of a query string to read. This slows tag val­i­da­tion to a tor­tur­ous crawl.

If you believe in karmic ret­ri­bu­tion and you feel that due to bad deeds in your past you some­how deserve the aggra­va­tion of per­form­ing these added steps for every tag request that hap­pens to trip the thresh­old of 2,047 char­ac­ters in length stop read­ing right now.

How do I fix it?

The trick to fix­ing this so that you can go back to tag val­i­da­tion as usu­al is to stop the HTTP POSTs on your local machine. The expla­na­tion below assumes that you are load­ing the App­Mea­sure­ment 1.4.1 or lat­er via Adobe Dynam­ic Tag Man­ag­er and that you have Charles Web Debug­ging Proxy at your dis­pos­al.

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


Well, it so hap­pens that there are a cou­ple con­di­tion­al state­ments with­in appMeasurement.js that trig­ger the POST behav­ior at a thresh­old of 2,047 bytes. While I hearti­ly endorse the first rule of App­Mea­sure­ment for pro­duc­tion code, I feel that when it comes to my local ver­sion, I can do what I please (and so can you). I have cho­sen 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 val­i­da­tion.

The best way to make this change local­ly with­out get­ting caught up in change man­age­ment dis­cus­sions (or any dis­cus­sions at all) is to use a Charles Rewrite rule to watch for the s-code-con­tents request from your brows­er to the DTM serv­er and mod­i­fy the response as it comes back across the wire. Below are the details of this sim­ple rewrite rule.

The screen cap­ture 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 serv­er. Note the host name is Note that the path must con­tain “s-code-con­tents-“ which is always on the request that we want to change.


The next screen cap­ture 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­tial­ly, 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 Ana­lyt­ics tag sent from App­Mea­sure­ment 1.4.4 that is well beyond the nor­mal 2,047 char­ac­ter thresh­old and since it is sent as a GET, we can see it nice­ly for­mat­ted in the Adobe Debug­ger (or any oth­er debug­ger that you choose).