Ideally, all Digital Analytics code should be modularized so that it is easy to maintain and deactivate, if necessary. A single, server-side "include" file can be used on all dynamic pages within your site to accomplish this.

This "include" file contains logic to determine what type of page is being rendered, and based on the page type, writes the appropriate Digital Analytics JavaScript code into the page. The include file should also have flags that allow you to switch off the Digital Analytics JavaScript code, in case you need to prevent the Digital Analytics code from rendering for any reason, as well as an automated way of changing whether the tags point to the Digital Analytics test or production servers.

The Digital Analytics include file should be included in a global header, global footer, or other global include file used in the site. This enables the code to be immediately propagated to all pages that make use of this include file. Having access to these global include files allows you to avoid having to touch a large number of pages in the implementation process.

The main case statement

You can use a case statement in your logic to determine what type of page is being rendered and write the appropriate Digital Analytics JavaScript code. The case statement should have a number of checks for each type of page that needs tags other than the default Page View tag. Each of these checks would then render the appropriate tagging functions needed on that page type. The default case for pages that do not fall into any special cases would be to throw a Page View tag with the default naming convention.

Here is an example of a case statement in pseudo-code:

if (pageType is product details page) {
    render cmCreateProductViewTag() with appropriate parameters
} else if (pageType is shopping cart page) {
    render cmCreatePageviewTag(), cmCreateShopAction5Tag(), 
and cmDisplayShops() with appropriate parameters
} else if (pageType is order confirmation page) { 
    render cmCreatPageviewTag(), cmCreateShopAction9Tag(), 
cmCreateOrderTag(), cmDisplayShops(), cmCreateRegistrationTag() with appropriate
 parameters
} else ... 
    ...Do other page type checks here...
} else {
    default case, render cmCreatePageviewTag() with default naming convention
}

Disable the Digital Analytics data collection: On/Off flag

To provide for disabling of Digital Analytics tags, you can implement an on/off server-side flag that is evaluated on every tagged page. Digital Analytics data collection is disabled by setting a 'CMDisabled' cookie with the value "Y" as shown in the following code sample. The Digital Analytics libraries and tag function calls do not need to be removed from the page. If the CMDisabled session cookie is found set on a page prior to any tag function calls, no tag requests are sent from the browser, and no tags appear in testing tools (TagBar or Tag Introspector).

The following example demonstrates the implementation of an on/off flag in JavaScript:

if(coremetricsOffFlag) {
  CB("CMDisabled","Y");
}

This feature can also be used to selectively disable data collection if specific conditions are met, such as for a specific client IP address range or user-agent string. The following example demonstrates disabling data collection for a specific client user-agent string value:

if (navigator.userAgent.toUpperCase().indexOf("MOZILLA/5.0 (X11; LINUX I686;
 RV:2.0.1) GECKO/20110531 FIREFOX/4.0.1") >=0) {
    CB("CMDisabled","Y");  
}

Test/Production flag

If you are using the same code base in both your development and production environments, it is considered a best practice to implement a flag that determines on which server (development, staging, or production) the code is rendering, and that calls the cmSetClientID(…); function with appropriate values. Clients not using the Digital Analytics-hosted library must also call cmSetProduction();). For example, you can create a server-side flag to indicate whether the code is on the development, staging, or production server.

If you cannot create a server-side flag, a client-side flag can be implemented in JavaScript to call cmSetClientID(…); based on URL domain value, for example. However, using the URL is a much less dependable method of determining whether the code is rendering on the test or production server. You must maintain the URL-based rules to encompass all possible URLs in the production environment.

Example:

if(productionServerFlag)  {
     cmSetClientID("99999999",true,"data.coremetrics.com","thesite.com");
  } else {
     cmSetClientID("69999999",false,"testdata.coremetrics.com","thesite.com");
  }
…