Today is an excit­ing day, with the release of Site­Cat­a­lyst v14.9. The lat­est and great­est ver­sion of Site­Cat­a­lyst includes a num­ber of awe­some fea­tures, includ­ing the highly antic­i­pated 25 addi­tional Cus­tom Traf­fic vari­ables, 25 addi­tional Cus­tom Con­ver­sion vari­ables, and 20 addi­tional cus­tom events. This release also includes a new ver­sion of JavaScript data col­lec­tion code, ver­sion H.22.1. As I have been doing for the last lit­tle while, here’s a quick post explain­ing the new fea­tures. Now you can decide whether or not to upgrade your own Site­Cat­a­lyst imple­men­ta­tion. So, here we go.

  • The big one is the abil­ity to cap­ture data in the new vari­ables men­tioned above. If you are going to use s.eVar51 or up or s.prop51 or up, use H.22.1 code. (Tech­ni­cally this was pos­si­ble in H.22 code, released in Sep­tem­ber 2010, but of course the reports them­selves weren’t avail­able at that time.) Once again, just to be clear, you need to upgrade to H.22 or H.22.1 if you are going to use s.eVar51 through s.eVar75, or s.prop51 through s.prop75. Set­ting these vari­ables in pre­vi­ous ver­sions of code will not work—data for the vari­ables will not be collected.
  • You know that IE behav­ior where the browser has a max­i­mum URL limit of 2,083 char­ac­ters? Pre­vi­ously, if you were cap­tur­ing more than 2,083 char­ac­ters of data in your Site­Cat­a­lyst image request, IE sim­ply would not send the request, and no data would be cap­tured from that page view. That doesn’t hap­pen very often—as it hap­pens, 2,083 bytes leaves room for a LOT of data collection—but it did hap­pen from time to time, and it was very hard to detect man­u­ally (although Dig­i­talPulse does it auto­mat­i­cally for you). Any­way, code ver­sion H.22.1 intro­duces auto­matic trun­ca­tion of the image request in IE if the request is longer than 2,047 bytes (note the path limit in the Microsoft KB arti­cle linked above) so that Site­Cat­a­lyst will always cap­ture basic traf­fic data if your request is crazy long. Every­thing up to the last com­plete vari­able value under the 2,047 limit will be cap­tured and reported. In other words, if trun­ca­tion cuts off a vari­able value in the mid­dle of it, that value will be dis­carded to avoid fill­ing your reports with garbage. Note that Adobe has never imposed a total character/byte limit on image requests, and data col­lected in browsers that do not apply their own char­ac­ter lim­its will con­tinue to be com­plete and untrun­cated; this applies only to IE.

So, in short, you want to upgrade to H.22 if…

  • You want to use the new vari­ables intro­duced in Site­Cat­a­lyst v14.9.
  • You have long image requests that might exceed 2,083 characters.

There you have it. As always, please feel free to sub­mit JavaScript code sug­ges­tions at the Idea Exchange; we’re lis­ten­ing! And if you have any ques­tions about this code release or any­thing else related to the Adobe Online Mar­ket­ing Suite, leave me a com­ment or send me a tweet (@benjamingaines).

6 comments
Jonathan
Jonathan

Hi Ben, This new version is pretty interesting. We added a custom function to test if the "s_i_rsid" image request was exceeding the characters limit and we will now remove this functionnality. It was a critical update especially for order confirmation pages for some retail site where several products could increase the image request length. Combining this new feature with additional variables, it makes a really good improvement and gives us further flexibility. Good work, Jonathan Roy, Eng. -- Director of Web Analytics Devrun Inc.

mig
mig

The Media snippet in the media_tracking_implementation_guide.pdf on page 34 (pdfpage38) is corrupt (in the 07/15/2010 version of the file). I can't do anything with the Media module without that snip to paste into my s_code.js file. Help!?!?

nic
nic

Hi Ben, we already have a solution in place which suits us better (skipping not the last but some less used variables). Is it possible to turn your mechanism off? Or is it possible to determine the length of the request _before_ your mechanism starts (and then shortening it our way)? so long nic

Ben Gaines
Ben Gaines

Jonathan, Thanks! That's great feedback, and I'm glad to hear that the updates were helpful to you. As someone who struggled for years to diagnose seemingly inconsistent issues with data transmission in IE (particularly, as you've said, on pages with long s.products strings), I am also *really* excited about the update! Thanks, Ben

Ben Gaines
Ben Gaines

Mig, I see what you mean. I don't think the code sample in the doc includes the full media module—it's just a snippet. The intent wasn't for users to get the media module itself from the code samples, but rather to demonstrate how to implement it once it has been received from your Account Manager or ClientCare. For a variety of reasons, I don't believe we have plans to include the full media module in the documentation, but I would be happy to send it over to you if your AM or ClientCare can't do it. Thanks, Ben

Ben Gaines
Ben Gaines

Nic, Great question. At present there is no option to override the built-in truncation in the JS file. However, depending on how you have built your system for shortening the request, it's certainly possible to make your system execute before ours does, thus ensuring that our JS code never needs to perform truncation. Thanks, Ben Gaines Product Manager Adobe Systems, Inc.