Let’s face it; your site is never fast enough. That’s why you use pre­cious devel­op­ment time to:

  • Lower page weight
  • Cache more of the page
  • Opti­mize JavaScript
  • Use con­tent deliv­ery net­works (CDNs) to push con­tent closer to the visitor

For this rea­son, there’s one part of your site that we’ve been work­ing to speed up: the ana­lyt­ics. For instance, ear­lier this year we release ver­sion H.20 of our JavaScript code. It’s the fastest yet-taking advan­tage of native browser func­tion­al­ity to avoid any notice­able JavaScript delays. More recently we’ve built a regional data col­lec­tion net­work, push­ing our con­tent (the 1×1 pixel image) closer to your site vis­i­tors. This sec­ond enhance­ment is excit­ing because it’s built on a very robust, very smart archi­tec­ture; and because it’s light­ning fast.

As of today, five data col­lec­tion cen­ters have been setup around the globe, each respond­ing to mil­lions of requests in less than half the time of the stan­dard net­work. Those col­lec­tion cen­ters are in Lon­don, Tokyo and the US, with more being con­sid­ered globally.

What Does this Mean For You?

In short, this means that your site will be faster for vis­i­tors around the globe. If you’re curi­ous, here’s a descrip­tion of some details. If not, just skip to the “Results” section.

Your data is processed in one of two US-based data cen­ters. Cur­rently, vis­i­tors to your site request lit­tle images from that data cen­ter, regard­less of where they are in the world. Long dis­tances, espe­cially across oceans, can result in poor response times for those images.

Regional data col­lec­tion lets site vis­i­tors request data from the data cen­ter near­est them, not nec­es­sar­ily the data cen­ter where your data is processed. Those data col­lec­tion cen­ters respond imme­di­ately with an image, and then for­ward the data on to the data cen­ter for processing.

This works just like a CDN-pushing con­tent closer to the vis­i­tor for faster response times.

The Results


On aver­age, the new sys­tem responds in half the time of the old sys­tem. Response time for vis­i­tors in North Amer­ica improves by 38%, while response time for Euro­pean vis­i­tors drops by a whop­ping 83%! Here’s some more detail:

How to Get On the New Network

This is when peo­ple typ­i­cally ask: is there any rea­son not to use regional data col­lec­tion? The answer: no. Come over as soon as you can. We’re mov­ing cus­tomers over as quickly as our capac­ity allows, so it’s a first-come first-served pri­or­ity. Here’s the gen­eral process:

  1. You tell your account man­ager you’d like to migrate
  2. Omni­ture gets ready by deploy­ing your SSL certs and/or giv­ing you col­lec­tion domain info
  3. After your go-live date, you make the switch by either
    a. Updat­ing your DNS CNAME record (first party cook­ies only), or
    b. Updat­ing your JavaScript file(s)

More details are avail­able in the white paper RDC (Regional Data Col­lec­tion) Tran­si­tion, avail­able in the Knowl­edge Base (arti­cle 9937).

Typ­i­cal Follow-On Questions

Once we start talk­ing about regional data col­lec­tion, a num­ber of ques­tions come up. I’ve addressed many of them here. Your AM should be able to answer any others.

Will data take longer to show up in reports?

No; at least not that you’ll be able to notice. Col­lec­tion cen­ters for­ward data to pro­cess­ing cen­ters in sec­onds. Since traf­fic data is typ­i­cally avail­able in 30–120 sec­onds, you prob­a­bly won’t notice the change.

Is this sys­tem as robust as the cur­rent system?

Yes, in fact it’s more robust. Not only does each col­lec­tion cen­ter have redun­dancy built through­out, the net­work of col­lec­tion cen­ters pro­vides another layer of redun­dancy. If a col­lec­tion cen­ter is unable to reach the desired pro­cess­ing cen­ter, it for­wards the data to a col­lec­tion cen­ter that can send the data to a pro­cess­ing cen­ter. Addi­tion­ally, if one col­lec­tion cen­ter goes com­pletely down for any rea­son, we have mul­ti­ple back-up col­lec­tion cen­ters ready to step in.

What about regional pro­cess­ing centers?

Cus­tomers out­side of the US typ­i­cally won­der whether they can get faster report speed by hav­ing a data pro­cess­ing cen­ter in their region. While we are con­sid­er­ing build­ing those out, we’re cur­rently focused on other ways to speed up report­ing around the globe.

Where will the next regional col­lec­tion cen­ters go?

We’re con­sid­er­ing many loca­tions for 2010, but we’re not ready to talk about any yet. We’re going to focus on areas where you have or will have the most vis­i­tors, so let me know if you’ve got plans to expand to new regions. Your AM will be able to con­nect us if you’d like to talk to me directly.

Sum­mary

Regional Data Col­lec­tion is live and in use by high-volume sites. I’ve helped mul­ti­ple cus­tomers through the migra­tion process, and it’s sur­pris­ingly sim­ple to move over. Call your account man­ager to get started, or down­load the whitepa­per if you want some more details.

4 comments
Bret Gundersen
Bret Gundersen

If you're on first party cookies, you don't need to touch the code on your site. It's a very simple DNS change. If you're using 2o7.net, we'll transfer visitors' cookies from 2o7.net to omtrdc.net, which requires H code. You may not be aware that version H of the JS file supports version G page code, so you'd just need to swap out JS files in that case. KB article 1826 has a whitepaper on how to use version H of the JS file with G page code.

Heather Aeder
Heather Aeder

Do you have to be on H code to take advantage of this? Or will it work with G code as well?

Bret Gundersen
Bret Gundersen

Excellent point, James. Omniture account managers are reaching out to customers over the next few weeks, to recommend this. Your account manager has access to average response times by region, so I won't list them all here. But to give you an example, image response times in the UK, measured by Gomez and Keynote, average 392 milliseconds without RDC, and 25 ms with. On the other hand, the network topology in Asia prevents quite as dramatic of an improvement. Average response times in Asia go from 547 milliseconds to 352. These will improve as we introduce more collection nodes in that region. I'm glad you asked about the use of asynchronous scripts. The async flag is an HTML 5 feature. Based on our research, the only browser that supports asynchronous JavaScript is Firefox 3.6, which is still in beta. So using that flag now probably won't impact the speed of your site much. However, we are planning to include this in our standard tags in the future, as HTML 5 becomes more prevalent.

James Dutton
James Dutton

Bret, Interesting article, though based on what I've read here I assume this is a process recommended for all Omniture customers - I can't see any reasons why an organisation might be concerned about the migration (beyond the *potentially* complex issues of js file migration). As such would it not be appropriate for Omniture account managers to share this with their customers as a matter of courtesy to say 'hey there, we're now considerably faster.. would you consider these steps?'. I'd be curious if you could share just how bad the US centric system was before / after - particularly for European and Asia customers - care to share response times? Can you also share an opinion on the use of asynchronous script / function calls and Omniture's plans to support this method? I'll certainly be encouraging clients to add this to their project pipeline. Cheers, James.