Those of you who logged in to the Admin Console in SiteCatalyst since this past Thursday afternoon to generate new JavaScript code may have noticed that we released code version H.21. The primary purpose of this update was to add ClickMap support for the <button> element, so that you can see the number of clicks on form buttons using the ClickMap plug-in. If need to be able to report on button clicks immediately, you may want to consider upgrading to this new code version after testing it extensively in a development environment.

Speaking of ClickMap support for the <button> element, we strongly recommend using the s_objectID variable in the onclick event handler of your <button> elements. In our experience, use of <button> almost always involves an onclick event handler which performs the button’s practical function (e.g., submitting a form, launching a pop-up, etc.). They never involve an href (and never should). This leaves ClickMap needing to use the onclick function to identify the page element, and this gets messy—especially when you consider that IE and Firefox report them to ClickMap differently.

Fortunately, there’s an easy solution: put an s_objectID variable—with a value unique to each distinct button—in the onclick for the button. For example:

<button type="submit" onclick="var s_objectID='abcd1234';myFormSubmitFunction();">

<button onclick="var s_objectID='some_unique_value';launchPopup();">

(Also, note that while the “type” attribute is not expressly required, when it is omitted—as in the second example above—IE will assume a type of “button,” and other browsers will assume a type of “submit.” This means that depending on which browser you are running ClickMap in to view the page, you will see a different number of clicks for the button, as it will only be reporting on the portion of the data which matches the implied type for the browser you are using. This limitation is also overcome by using s_objectID.)

8 comments
jasonz
jasonz

Thanks for the response - it looks like I wrapped the tag names in < and > my tags got yoinked. The first question was "What about input tags? Any reason why you chose button tags over input tags? If you assign an s_objectID, would it make a difference what the tag is?

jasonz
jasonz

What about tags? Any reason why you chose over ? If you assign an s_objectID, would it make a difference what the tag is? Also, why don't you suggest to handle the onclick assignment in a separate JS file and keep the JS out of the HTML? Thanks!

Henrik Schack
Henrik Schack

Hm but couldn't the Omniture tracking code compensate for these differences, and make sure to track things "right" across different browsers ?

Henrik Schack
Henrik Schack

Re: IE and Firefox reporting onclick handlers differently to Clickmap, how much of a difference is there ? /Henrik Schack

James Dutton
James Dutton

Hey Ben, Quick question - and I think you answered it in your article - for those who are already using the DynamicObjectIDs plugin (which I believe only generates unique id's for objects in the dom with an href) would you need to do what you're proposing here? Or is it because the DynamicObjectIDs plugin doesn't work on these kind of objects you'd need to hardcode an s_objectID? If this is the case, do you think the engineering team will take note that increasingly IA's and developers are linking content with more 'funky' code than simply hrefs, so the s_code needs to effectively get smarter - in other words might DynamicObjectIDs (if it doesn't already) cover more linkable objects? As always, great reading! Cheers, James.

Ben Gaines
Ben Gaines

Ah! That makes sense :) We didn't choose button tags over input tags per se; input tags have been measurable in ClickMap for years. Rather than choosing between the two, we added support for both. Both them do require s_objectID, however, because they do not have hrefs.

Ben Gaines
Ben Gaines

Jason, I'm not sure I understand the first question entirely, but you are correct in your suggestion that the type of tag matters less when s_objectID is used. Regarding your second question, there are actually ways to do exactly what you're recommending. Omniture Consulting offers a JavaScript "plug-in" that can be placed in the s_code.js file to assign s_objectID values dynamically; I believe it is designed to work only on links, but I could be wrong, and it could certainly be tweaked by the Consulting team to work with or other elements, too, if that's a major concern. Thanks, Ben

Ben Gaines
Ben Gaines

Great question, James. I believe the plug-in goes through document.links to get an array of the links on the page, so a element would not be covered. You'd need to implement s_objectID manually on elements, at least based on the current version of dynamicObjectIDs. And I do agree and expect that plug-ins and base code will continue evolve to meet the needs of users in this regard and others. You've offered an excellent specific reminder of this, though, and we've taken note of it.