Code version H.21 released

Analytics · By On · 8 Comments

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.)

  • http://insightr.com James Dut­ton

    Hey Ben,

    Quick ques­tion — and I think you answered it in your arti­cle — for those who are already using the Dynam­i­cOb­jec­tIDs plu­gin (which I believe only gen­er­ates unique id’s for objects in the dom with an href) would you need to do what you’re propos­ing here? Or is it because the Dynam­i­cOb­jec­tIDs plu­gin doesn’t work on these kind of objects you’d need to hard­code an s_objectID?
    If this is the case, do you think the engi­neer­ing team will take note that increas­ingly IA’s and devel­op­ers are link­ing con­tent with more ‘funky’ code than sim­ply hrefs, so the s_code needs to effec­tively get smarter — in other words might Dynam­i­cOb­jec­tIDs (if it doesn’t already) cover more link­able objects?

    As always, great reading!

    Cheers, James.

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Great ques­tion, James. I believe the plug-in goes through document.links to get an array of the links on the page, so a ele­ment would not be cov­ered. You’d need to imple­ment s_objectID man­u­ally on ele­ments, at least based on the cur­rent ver­sion of dynam­i­cOb­jec­tIDs. And I do agree and expect that plug-ins and base code will con­tinue evolve to meet the needs of users in this regard and oth­ers. You’ve offered an excel­lent spe­cific reminder of this, though, and we’ve taken note of it.

  • Hen­rik Schack

    Re: IE and Fire­fox report­ing onclick han­dlers dif­fer­ently to Clickmap, how much of a dif­fer­ence is there ?

    /Henrik Schack

  • Hen­rik Schack

    Hm but couldn’t the Omni­ture track­ing code com­pen­sate for these dif­fer­ences, and make sure to track things “right” across dif­fer­ent browsers ?

  • jasonz

    What about tags? Any rea­son why you chose over ? If you assign an s_objectID, would it make a dif­fer­ence what the tag is?

    Also, why don’t you sug­gest to han­dle the onclick assign­ment in a sep­a­rate JS file and keep the JS out of the HTML?

    Thanks!

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Jason,

      I’m not sure I under­stand the first ques­tion entirely, but you are cor­rect in your sug­ges­tion that the type of tag mat­ters less when s_objectID is used.

      Regard­ing your sec­ond ques­tion, there are actu­ally ways to do exactly what you’re rec­om­mend­ing. Omni­ture Con­sult­ing offers a JavaScript “plug-in” that can be placed in the s_code.js file to assign s_objectID val­ues dynam­i­cally; I believe it is designed to work only on links, but I could be wrong, and it could cer­tainly be tweaked by the Con­sult­ing team to work with or other ele­ments, too, if that’s a major concern.

      Thanks,
      Ben

  • jasonz

    Thanks for the response — it looks like I wrapped the tag names in < and > my tags got yoinked. The first ques­tion was

    “What about input tags? Any rea­son why you chose but­ton tags over input tags? If you assign an s_objectID, would it make a dif­fer­ence what the tag is?

    • http://blogs.omniture.com/author/bgaines Ben Gaines

      Ah! That makes sense :)

      We didn’t choose but­ton tags over input tags per se; input tags have been mea­sur­able in ClickMap for years. Rather than choos­ing between the two, we added sup­port for both. Both them do require s_objectID, how­ever, because they do not have hrefs.