– I need to do exactly this. We are now loading all of our js files asynchronously except for s_code.js, and Firebug is showing that even though it’s right before our tag, it is blocking most of our images. Just wondering if there are any pitfalls. Having trouble finding anyone who’s done this before.

I’ve played with the event capturing approach before, but I didn’t even think of using the event capturing technique when I built this. That’s a really good idea now that you mention it. Since I’m basing the search off of markup elements anyway I can rewrite this whole thing to use one event to capture every link. It would even fix the “Links added after page load” gotcha.

Thanks for pointing that out! I can’t think of any downsides to using that technique for Omniture tracking. I know there were some event bubbling issues in older browsers but I don’t even bother supporting browsers that old anymore.

Also, for the record I’ve used this script on pages with hundreds of links before and saw no visible delay, but I’ve never benchmarked it, and I’m always on fairly powerful computers.

Thanks for the insightful post – but I’ve also good disagree with your implementation :)

For many webpages, this script will be attaching hundreds (thousands?) of event handlers. That’s going to be slow.

Plus if you dynamically add any links to the page after the fact, then you’re tracking code isn’t going to run on them.

Much better to use an event delegation approach and attach a single event handler to the document element and then listen for clicks whose target is a link. This is how jQuery’s “live” method works.

http://api.jquery.com/live/

Karl Swedberg also wrote an excellent introduction to the technique on Learning jQuery:

http://www.learningjquery.com/2008/03/working-with-events-part-1

Cheers,

John

Thanks for the specifics. Very helpful. I’ll try to build a proof of concept with the info you gave me.

> Why is RDC a pain to set up? … this is a fairly easy change.

For normal situations, yeah it’s easy. But I would have to make that change for, well a lot of sites. My company has over 500 Omniture enabled sites live. Every little task becomes far more complex when you have that many sites. I will need to change how we do Omniture one day, but it will probably be a while before I can dedicate the time that it will take.

@Ben

I hope my suggestions will be helpful. Thanks for taking the time to review the article and my complaints about Omniture. I too am glad we got to have this conversation. I’ve learned quite a few things about Omniture from talking with you and Andreas.

I’ve read your exit link article. The technique is very similar to mine but we have different coding styles. In fact the overall process is exactly the same, iterate through links, attach events, run events. We use some different keywords and structure, but overall they are very similar.

Thanks again,
Ben

I completely understand your point about form names. It looks like the site was using the “Form Analysis” plug-in, which is a nifty little code snippet that can, in cases such as these, be a complete nightmare. We actually don’t even give it out anymore unless the customer is working with our Omniture Consulting group so that we can help avoid situations like the one you described. In many, many cases, there are more efficient, more powerful, and just plain better ways to analyze form usage/abandon.

As Andreas pointed out, we’ve made a number of code improvements over the past several years. H.5 code puts you, I believe, in late 2005; even H.17 is almost two years old now. Many of the incremental improvements we’ve made since then help to address some of the issues you mentioned; in any case, I will definitely be sharing your feedback (which was extremely detailed — you obviously know what kind of info developers need!) with our Engineering and Product Management teams.

> Why wasn’t 2o7.net simply converted to run this
> system by default?

That is a great question, and I don’t have the answer presently. I’ll do my best to find out and report back to you. Generally, though, we’ve tried to make the RDC transition as painless as possible.

> I’ve had some bad experiences with Omniture plugins
> (for instance the form issue I cited earlier). Can
> you point me to some documentation for this plugin?

The linkHandler plug-in is fairly innocuous, but I am guessing it would actually be even easier for you to write your own “plug-in” to add an event handler to every link on the page. I did something similar for automatic exit link tracking a few months ago; you can read about it at http://is.gs/6n. (NOTE: WordPress keeps deciding to replace my straight quotes with smart quotes, even inside of a <pre> and a <code>, so if you decide to use the code make sure to locate and change those to straight quotes.)

Anyway, this is a fantastic conversation and, as I said, I will be circulating it around the office. Feel free to let me know if you have any other concerns that I might have missed.

Thanks,
Ben

Andreas

Thanks for your input, it is really helpful to hear some other opinions and options.

> I recently did some speed testing for my implemenations and my s_code (H20.3
> + tons of custom code) runs withing ~83ms in FF3.5 at the page load. I think
> that’s not too bad.

83ms isn’t a terrible number, but it isn’t great either. That’s about the same number that my testing revealed.

> Starting with H20.3 the pagecode is not obfuscated anymore

Oh thank god. It’s about time. This is my single biggest complaint about Omniture. It’s just plain dumb to obfuscate a tracking script.

> OMTR actually only adds the 500ms timeout if the link will be opened in the
> same window AND the timeout will be shortened if the image returns faster

I wasn’t aware of this. In my experience there is a noticeable lag on dynamic links (like jQuery tabs) in pages when they get tracking code attached to them.

> look into RDC to get fastest response times

Omniture Regional Data Collection is something that I am looking into for a couple products. This is another huge improvement for the service. But it is a bit of a pain to set up and get running. From what I understand it works just like a CDN. Why wasn’t 2o7.net simply converted to run this system by default?

> including this script as an additional file would add so much additional
> load time … add it to your existing Omniture script

Ahh, yeah of course you are right on this one. I’ll fix that.

> I’m not sure why you do not use existing Omniture code and so benefit from
> existing event handlers. I think in regards of saving execution time you
> should go that route.

Can you be more specific? I don’t know of any way to hook into Omniture events to attach code like this.

> Look into the s.linkHandler plugin

I’ve had some bad experiences with Omniture plugins (for instance the form issue I cited earlier). Can you point me to some documentation for this plugin?

@Richard

Thanks for the link. I’ll have a look at them. The first thing I did was view source on their page, where I found this:

// Yep, we use GA too, we do two very different things...for now. =)
var gaJsHost...

lol I like them already.