Today is an exciting day, with the release of SiteCatalyst v14.9. The latest and greatest version of SiteCatalyst includes a number of awesome features, including the highly anticipated 25 additional Custom Traffic variables, 25 additional Custom Conversion variables, and 20 additional custom events. This release also includes a new version of JavaScript data collection code, version H.22.1. As I have been doing for the last little while, here’s a quick post explaining the new features. Now you can decide whether or not to upgrade your own SiteCatalyst implementation. So, here we go.

  • The big one is the ability to capture data in the new variables mentioned above. If you are going to use s.eVar51 or up or s.prop51 or up, use H.22.1 code. (Technically this was possible in H.22 code, released in September 2010, but of course the reports themselves weren’t available 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. Setting these variables in previous versions of code will not work—data for the variables will not be collected.
  • You know that IE behavior where the browser has a maximum URL limit of 2,083 characters? Previously, if you were capturing more than 2,083 characters of data in your SiteCatalyst image request, IE simply would not send the request, and no data would be captured from that page view. That doesn’t happen very often—as it happens, 2,083 bytes leaves room for a LOT of data collection—but it did happen from time to time, and it was very hard to detect manually (although DigitalPulse does it automatically for you). Anyway, code version H.22.1 introduces automatic truncation of the image request in IE if the request is longer than 2,047 bytes (note the path limit in the Microsoft KB article linked above) so that SiteCatalyst will always capture basic traffic data if your request is crazy long. Everything up to the last complete variable value under the 2,047 limit will be captured and reported. In other words, if truncation cuts off a variable value in the middle of it, that value will be discarded to avoid filling your reports with garbage. Note that Adobe has never imposed a total character/byte limit on image requests, and data collected in browsers that do not apply their own character limits will continue to be complete and untruncated; this applies only to IE.

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

  • You want to use the new variables introduced in SiteCatalyst v14.9.
  • You have long image requests that might exceed 2,083 characters.

There you have it. As always, please feel free to submit JavaScript code suggestions at the Idea Exchange; we’re listening! And if you have any questions about this code release or anything else related to the Adobe Online Marketing Suite, leave me a comment 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.