Blog Post:A fellow SiteCatalyst user recently asked me via Twitter how best to manage deployment on multiple sites. Many companies operate several distinct web sites; consider a firm that owns multiple brands. If I own BrandA and BrandB, the odds are that each of these brands will have its own site. This can become problematic as the number of sites you're managing increases. Let's say Omniture introduces new functionality in the core JavaScript file (s_code.js). Now imagine that you're managing 500 sites, each with its own implementation and JavaScript file. Suddenly, if you want to upgrade to the latest release, you may need to make 500 separate updates. This can ruin your entire month. Generally speaking, with a few major exceptions (discussed below), we have found that using a single, global JavaScript file across all sites is tremendously advantageous in cases such as these. As one Omniture consultant managing the implementation for a large international brand told me, "This is exactly what we did for [customer]. Now, if we release a new feature in the JavaScript code, I can have it up and running for [customer], worldwide, after testing, in about five minutes." When you compare that to the amount of time required to roll out a similar change across dozens or hundreds of sites, each with its own s_code.js file, it's utterly minuscule. At the same time, using a single JavaScript file across sites may require significant forethought and a solid strategy during initial implementation (or re-implementation). A potential problem with using a single JavaScript file across multiple sites is that different sites may use variables differently. Certainly, the s_account variable (which stores the destination report suite ID), will likely change from one site to another. But the s.linkInternalFilters variable (which controls exit link tracking), s.trackingServer (first-party cookie data collection domains), and other variables may need to be populated dynamically based on the domain or some other site-specific criteria. Many variables, such as those mentioned above, are common to all implementations and report suites; every site will need an s.linkInternalFilters value. But what happens when one report suite uses eVar1 to store internal search keywords and another suite uses eVar20 for this same purpose? How can you ensure that each site passes the data into the correct variable for that particular site? The preferable option here is to standardize variable usage across sites and report suites as much as possible. Even though various sites may have diverse KPIs, there are likely items that you will want to track across all sites. Campaigns provides a common, if simplistic, example. Plan in advance so that all of your sites will use s.campaign to track external campaigns and, say, eVar7 to track internal campaigns. Where query parameters are involved, use the same query parameter to store tracking codes in your URLs across all sites (for example, "cid="). Where this isn't possible, I'll show in the example below how you can fairly easily ensure that variables are populated differently and correctly based on the domain (or some other criteria). Example Let's consider BrandA.com and BrandB.com, both owned by the same company. It would be great if both brands used a single 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 properties. To do this, you would have a single s_code.js file hosted somewhere accessible to both sites. Within the file, you would detect the domain that the user happens to be on (either branda.com or brandb.com), and then set s_account accordingly. 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 similar things to set any other variables dynamically based on the domain of the site being accessed. For example, you would also need to set the s.linkInternalFilters variable 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 manage have already been implemented, and already use the same variables in different ways. In that case, you can use the same logic just described to change the way that these variables 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 number of variables being used for different purposes across report suites, consider populating them on page itself, rather than in the global JavaScript file. Variables, once allocated for a specific reporting purpose, are not likely to be reapportioned frequently, so putting them on pages typically will not require a bunch of maintenance. This also helps to keep the size of the global JavaScript file under control. Why you would not use a single JavaScript include I've spoken to a number of members of the Omniture Consulting team, and all agreed that the solution described above is ideal in many cases. There are a couple of reasons why you might not want to handle multiple sites this way: Conclusion For me to believe that a blog post could answer all of your questions on this topic would be presumptuous in the extreme, but I hope this discussion at least gets the wheels turning at your organization if you're facing this sort of a situation and don't know how to handle it. I hope it's clear that the suggestion to use a single, global JavaScript file isn't necessarily for everyone, but that in many cases it can make managing a SiteCatalyst implementation multiple sites much easier. As always, please feel free to shoot any questions/tips/suggestions to me by leaving a comment on this post, via Twitter (@OmnitureCare), or by e-mail (omniturecare@omniture.com). I always enjoy hearing from you!
Author: Date Created:June 8, 2009 Date Published: Headline:Managing implementation on multiple sites Social Counts: Keywords: Publisher:Adobe Image:https://blogs.adobe.com/digitalmarketing/wp-content/uploads/no-image/no-image.jpg

A fellow SiteCatalyst user recently asked me via Twitter how best to manage deployment on multiple sites. Many companies operate several distinct web sites; consider a firm that owns multiple brands. If I own BrandA and BrandB, the odds are that each of these brands will have its own site.

This can become problematic as the number of sites you’re managing increases. Let’s say Omniture introduces new functionality in the core JavaScript file (s_code.js). Now imagine that you’re managing 500 sites, each with its own implementation and JavaScript file. Suddenly, if you want to upgrade to the latest release, you may need to make 500 separate updates. This can ruin your entire month.

Generally speaking, with a few major exceptions (discussed below), we have found that using a single, global JavaScript file across all sites is tremendously advantageous in cases such as these.

As one Omniture consultant managing the implementation for a large international brand told me, “This is exactly what we did for [customer]. Now, if we release a new feature in the JavaScript code, I can have it up and running for [customer], worldwide, after testing, in about five minutes.” When you compare that to the amount of time required to roll out a similar change across dozens or hundreds of sites, each with its own s_code.js file, it’s utterly minuscule.

At the same time, using a single JavaScript file across sites may require significant forethought and a solid strategy during initial implementation (or re-implementation). A potential problem with using a single JavaScript file across multiple sites is that different sites may use variables differently. Certainly, the s_account variable (which stores the destination report suite ID), will likely change from one site to another. But the s.linkInternalFilters variable (which controls exit link tracking), s.trackingServer (first-party cookie data collection domains), and other variables may need to be populated dynamically based on the domain or some other site-specific criteria.

Many variables, such as those mentioned above, are common to all implementations and report suites; every site will need an s.linkInternalFilters value. But what happens when one report suite uses eVar1 to store internal search keywords and another suite uses eVar20 for this same purpose? How can you ensure that each site passes the data into the correct variable for that particular site?

The preferable option here is to standardize variable usage across sites and report suites as much as possible. Even though various sites may have diverse KPIs, there are likely items that you will want to track across all sites. Campaigns provides a common, if simplistic, example. Plan in advance so that all of your sites will use s.campaign to track external campaigns and, say, eVar7 to track internal campaigns. Where query parameters are involved, use the same query parameter to store tracking codes in your URLs across all sites (for example, “cid=”).

Where this isn’t possible, I’ll show in the example below how you can fairly easily ensure that variables are populated differently and correctly based on the domain (or some other criteria).

Example

Let’s consider BrandA.com and BrandB.com, both owned by the same company. It would be great if both brands used a single 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 properties. To do this, you would have a single s_code.js file hosted somewhere accessible to both sites. Within the file, you would detect the domain that the user happens to be on (either branda.com or brandb.com), and then set s_account accordingly. 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 similar things to set any other variables dynamically based on the domain of the site being accessed. For example, you would also need to set the s.linkInternalFilters variable 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 manage have already been implemented, and already use the same variables in different ways. In that case, you can use the same logic just described to change the way that these variables 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 number of variables being used for different purposes across report suites, consider populating them on page itself, rather than in the global JavaScript file. Variables, once allocated for a specific reporting purpose, are not likely to be reapportioned frequently, so putting them on pages typically will not require a bunch of maintenance. This also helps to keep the size of the global JavaScript file under control.

Why you would not use a single JavaScript include

I’ve spoken to a number of members of the Omniture Consulting team, and all agreed that the solution described above is ideal in many cases. There are a couple of reasons why you might not want to handle multiple sites this way:

  • Imagine that you work for consultancy that manages the SiteCatalyst implementation and reporting for a wide array of its own customers. Since these customers are distinct entities, each will have its own site to manage. However, you may not want Customer A to see all of the specifics of Customer B’s implementation. In these cases, you may need to use separate JavaScript files for business reasons.
  • Hosting a global JavaScript file in one place means that all of your sites will be hitting a single server to retrieve it. This can dramatically increase the demands on that server, potentially affecting site performance if the number of page views across all sites is large enough. This will vary from company to company and from server to server, so unfortunately I can’t suggest a number of page views at which point this would become problematic.
  • If the number of sites that you are managing is small enough—say, two or three—it might be enough work to set up the dynamic population of variables that it’s easier just to maintain separate files.

Conclusion

For me to believe that a blog post could answer all of your questions on this topic would be presumptuous in the extreme, but I hope this discussion at least gets the wheels turning at your organization if you’re facing this sort of a situation and don’t know how to handle it. I hope it’s clear that the suggestion to use a single, global JavaScript file isn’t necessarily for everyone, but that in many cases it can make managing a SiteCatalyst implementation multiple sites much easier.

As always, please feel free to shoot any questions/tips/suggestions to me by leaving a comment on this post, via Twitter (@OmnitureCare), or by e-mail (omniturecare@omniture.com). I always enjoy hearing from you!