Managing implementation on multiple sites

A fel­low Site­Cat­a­lyst user recently asked me via Twit­ter how best to man­age deploy­ment on mul­ti­ple sites. Many com­pa­nies oper­ate sev­eral dis­tinct web sites; con­sider a firm that owns mul­ti­ple brands. If I own BrandA and BrandB, the odds are that each of these brands will have its own site.

This can become prob­lem­atic as the num­ber of sites you’re man­ag­ing increases. Let’s say Omni­ture intro­duces new func­tion­al­ity in the core JavaScript file (s_code.js). Now imag­ine that you’re man­ag­ing 500 sites, each with its own imple­men­ta­tion and JavaScript file. Sud­denly, if you want to upgrade to the lat­est release, you may need to make 500 sep­a­rate updates. This can ruin your entire month.

Gen­er­ally speak­ing, with a few major excep­tions (dis­cussed below), we have found that using a sin­gle, global JavaScript file across all sites is tremen­dously advan­ta­geous in cases such as these.

As one Omni­ture con­sul­tant man­ag­ing the imple­men­ta­tion for a large inter­na­tional brand told me, “This is exactly what we did for [cus­tomer]. Now, if we release a new fea­ture in the JavaScript code, I can have it up and run­ning for [cus­tomer], world­wide, after test­ing, in about five min­utes.” When you com­pare that to the amount of time required to roll out a sim­i­lar change across dozens or hun­dreds of sites, each with its own s_code.js file, it’s utterly minuscule.

At the same time, using a sin­gle JavaScript file across sites may require sig­nif­i­cant fore­thought and a solid strat­egy dur­ing ini­tial imple­men­ta­tion (or re-implementation). A poten­tial prob­lem with using a sin­gle JavaScript file across mul­ti­ple sites is that dif­fer­ent sites may use vari­ables dif­fer­ently. Cer­tainly, the s_account vari­able (which stores the des­ti­na­tion report suite ID), will likely change from one site to another. But the s.linkInternalFilters vari­able (which con­trols exit link track­ing), s.trackingServer (first-party cookie data col­lec­tion domains), and other vari­ables may need to be pop­u­lated dynam­i­cally based on the domain or some other site-specific criteria.

Many vari­ables, such as those men­tioned above, are com­mon to all imple­men­ta­tions and report suites; every site will need an s.linkInternalFilters value. But what hap­pens when one report suite uses eVar1 to store inter­nal search key­words and another suite uses eVar20 for this same pur­pose? How can you ensure that each site passes the data into the cor­rect vari­able for that par­tic­u­lar site?

The prefer­able option here is to stan­dard­ize vari­able usage across sites and report suites as much as pos­si­ble. Even though var­i­ous sites may have diverse KPIs, there are likely items that you will want to track across all sites. Cam­paigns pro­vides a com­mon, if sim­plis­tic, exam­ple. Plan in advance so that all of your sites will use s.campaign to track exter­nal cam­paigns and, say, eVar7 to track inter­nal cam­paigns. Where query para­me­ters are involved, use the same query para­me­ter to store track­ing codes in your URLs across all sites (for exam­ple, “cid=”).

Where this isn’t pos­si­ble, I’ll show in the exam­ple below how you can fairly eas­ily ensure that vari­ables are pop­u­lated dif­fer­ently and cor­rectly based on the domain (or some other criteria).

Exam­ple

Let’s con­sider BrandA​.com and BrandB​.com, both owned by the same com­pany. It would be great if both brands used a sin­gle JavaScript file; that way, when you need to make a change, you can do it one place, one time, and then it’s done across all of your prop­er­ties. To do this, you would have a sin­gle s_code.js file hosted some­where acces­si­ble to both sites. Within the file, you would detect the domain that the user hap­pens to be on (either branda​.com or brandb​.com), and then set s_account accord­ingly. For example:

// set report suite ID dynamically based on domain
if(document.domain.indexOf('branda.com') > -1) {
     var s_account = 'brandacom'
} else if(document.domain.indexOf('brandb.com' > -1) {
     var s_account = 'brandbcom'
}

And you can do sim­i­lar things to set any other vari­ables dynam­i­cally based on the domain of the site being accessed. For exam­ple, you would also need to set the s.linkInternalFilters vari­able in much the same manner.

// set s.linkInternalFilters dynamically based on domain
if(document.domain.indexOf('branda.com') > -1) {
     s.linkInternalFilters = 'javascript:,brandacom'
} else if(document.domain.indexOf('brandb.com' > -1) {
     s.linkInternalFilters = 'javascript:,brandbcom'
}

It may be that the sites you man­age have already been imple­mented, and already use the same vari­ables in dif­fer­ent ways. In that case, you can use the same logic just described to change the way that these vari­ables are used

// populate the internal search keywords into various eVars depending on report suite
if(s_account == 'brandacom') {
     s.eVar1=s.getQueryParam('kw');
} else if(s_account == 'brandbcom') {
     s.eVar23=s.getQueryParam('keyword');
     s.prop5=s.getQueryParam('keyword');
}

Where there is a large num­ber of vari­ables being used for dif­fer­ent pur­poses across report suites, con­sider pop­u­lat­ing them on page itself, rather than in the global JavaScript file. Vari­ables, once allo­cated for a spe­cific report­ing pur­pose, are not likely to be reap­por­tioned fre­quently, so putting them on pages typ­i­cally will not require a bunch of main­te­nance. This also helps to keep the size of the global JavaScript file under control.

Why you would not use a sin­gle JavaScript include

I’ve spo­ken to a num­ber of mem­bers of the Omni­ture Con­sult­ing team, and all agreed that the solu­tion described above is ideal in many cases. There are a cou­ple of rea­sons why you might not want to han­dle mul­ti­ple sites this way:

• Imag­ine that you work for con­sul­tancy that man­ages the Site­Cat­a­lyst imple­men­ta­tion and report­ing for a wide array of its own cus­tomers. Since these cus­tomers are dis­tinct enti­ties, each will have its own site to man­age. How­ever, you may not want Cus­tomer A to see all of the specifics of Cus­tomer B’s imple­men­ta­tion. In these cases, you may need to use sep­a­rate JavaScript files for busi­ness reasons.
• Host­ing a global JavaScript file in one place means that all of your sites will be hit­ting a sin­gle server to retrieve it. This can dra­mat­i­cally increase the demands on that server, poten­tially affect­ing site per­for­mance if the num­ber of page views across all sites is large enough. This will vary from com­pany to com­pany and from server to server, so unfor­tu­nately I can’t sug­gest a num­ber of page views at which point this would become problematic.
• If the num­ber of sites that you are man­ag­ing is small enough—say, two or three—it might be enough work to set up the dynamic pop­u­la­tion of vari­ables that it’s eas­ier just to main­tain sep­a­rate files.

Con­clu­sion

For me to believe that a blog post could answer all of your ques­tions on this topic would be pre­sump­tu­ous in the extreme, but I hope this dis­cus­sion at least gets the wheels turn­ing at your orga­ni­za­tion if you’re fac­ing this sort of a sit­u­a­tion and don’t know how to han­dle it. I hope it’s clear that the sug­ges­tion to use a sin­gle, global JavaScript file isn’t nec­es­sar­ily for every­one, but that in many cases it can make man­ag­ing a Site­Cat­a­lyst imple­men­ta­tion mul­ti­ple sites much easier.

As always, please feel free to shoot any questions/tips/suggestions to me by leav­ing a com­ment on this post, via Twit­ter (@OmnitureCare), or by e-mail (omniturecare@​omniture.​com). I always enjoy hear­ing from you!