Those of you who logged in to the Admin Con­sole in Site­Cat­a­lyst since this past Thurs­day after­noon to gen­er­ate new JavaScript code may have noticed that we released code ver­sion H.21. The pri­mary pur­pose of this update was to add ClickMap sup­port for the <but­ton> ele­ment, so that you can see the num­ber of clicks on form but­tons using the ClickMap plug-in. If need to be able to report on but­ton clicks imme­di­ately, you may want to con­sider upgrad­ing to this new code ver­sion after test­ing it exten­sively in a devel­op­ment environment.

Speak­ing of ClickMap sup­port for the <but­ton> ele­ment, we strongly rec­om­mend using the s_objectID vari­able in the onclick event han­dler of your <but­ton> ele­ments. In our expe­ri­ence, use of <but­ton> almost always involves an onclick event han­dler which per­forms the button’s prac­ti­cal func­tion (e.g., sub­mit­ting a form, launch­ing a pop-up, etc.). They never involve an href (and never should). This leaves ClickMap need­ing to use the onclick func­tion to iden­tify the page ele­ment, and this gets messy—especially when you con­sider that IE and Fire­fox report them to ClickMap differently.

For­tu­nately, there’s an easy solu­tion: put an s_objectID variable—with a value unique to each dis­tinct button—in the onclick for the but­ton. 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 sec­ond exam­ple above—IE will assume a type of “but­ton,” and other browsers will assume a type of “sub­mit.” This means that depend­ing on which browser you are run­ning ClickMap in to view the page, you will see a dif­fer­ent num­ber of clicks for the but­ton, as it will only be report­ing on the por­tion of the data which matches the implied type for the browser you are using. This lim­i­ta­tion is also over­come 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.