Digital Analytics or equivalent web analytics software functions by storing a cookie in the user’s browser. The cookie stays in the browser whilst on the same domain as the cookie specifies, but once the domain is changed, the cookie is lost. To enable tracking across domains, this cookie must be carried with the user, by means of attaching it as a URL parameter on all required domains.


A standard URI can be made up of various components. Here is an example, using the SCL website.

There are 4 different components that make up this URI (note: this will not always be the case, there may be greater or fewer).

Protocol – “HTTP”
The protocol that the website is using. Most websites use HTTP, but for an extra layer of encryption, some will use https.

Hostname – “”
This is where the website is “located”; DNS translates this hostname into an IP address that can be used by other networking protocols. The protocol along with the hostname is also known as the URL.

Query String  – “?param=123”
This will be the focus of cross-domain tracking. When a redirect takes place (such as a user clicking a link on a webpage), this query string, unless used by the site in some way, effectively ignored. You can test this by typing in a popular webpage domain, followed by a “?” with anything after it (e.g., So long as there does not exist a query string originally, the query parameter should stay when the webpage is loaded. This principle can be used as a basis to carry the tracking cookie cross domains.

Hash/Fragment – “#body”
This is used as an extra parameter, usually to identify a certain part of a document. In this case, the body.

There are a few points to consider before Javascript development can begin. First is the size of the final Javascript file. Since the script will be placed on every page where cross-domain tracking wishes to take place, it has the potential to be loaded thousands of times by thousands of people. The size of the file should therefore be minimal. The Google Closure Compiler can be used to shrink the final .js file down; it may only be by a few kilobytes, but when the script is loaded potentially millions of times, it could save a sizeable amount of site performance.

The next thing to decide is which domains need to be tracked across. There’s no point using this file to track on the same domain, as the cookie is stored in the user’s browser whilst they are on it. There’s also no point in tracking across domains which don’t belong to you or have no web analytics software enabled on them. Some sort of whitelist is required, and this is up to the developer to decide which domains are going to be tracked across, and how this whitelist is implemented.

Global scope pollution should also be considered. Javascript used for tracking tags such as Digital Analytics requires a lot of global functions, to fire the correct tracking tags when a user visits a specific page. For this reason, it is recommended that the global scope of the webpage document be not polluted by functions created from the cross-domain tracking Javascript file, so as not accidentally overwrite an important function.

Another slightly less technical considerations are the names of the query string and the cookie name. Within reason, the query string can be called anything, so long as it is different from existing query strings. It is recommended that the cookie name is called the same as the cookie used by the web analytics software (e.g. Digital Analytics uses “CoreID6”).


Once these perquisites have been considered and completed, the method for enabling cross-domain cookie tracking can be started. The final Javascript file must have two different functionalities:

  1. The “origin” end: Add on the tracking cookie onto every hyperlink existing on the webpage that corresponds to a hostname in the whitelist
  2. The “receiving” end: Get the cookie from the URI, and store it in the user’s browser as a cookie, using the receiver side domain to store it, and clean up the URI

Whilst differing, both steps require similar sorts of URI manipulation, in reverse order from each other.


The script must loop through every link on the webpage it is deployed on, and check to see if the hostname of the link exists in the whitelist. If it does, the query string can be added on to the URI. However, by referring to the URI example at the start of this article, there may already exist query or hash parameters. If a hash fragment exists, it must be split off and saved. If there are no query parameters, the tracking cookie can be appended onto the URI, after a “?”. In the case that there are already query parameters, the tracking cookie must be appended with a “&” after the last query string. The hash fragment must be added back on afterwards, as to not break the existing link.


The script must then store the tracking cookie, by splitting off the query parameters from the URL and Hash fragment, if there is one. Once split, the correct parameter needs to located in the query string, and the value stored as a cookie, under the chosen cookie name. The correct domain must also be used here; it’s no use storing the tracking cookie under the old domain, so the new one must either be pulled using “document.hostname”, or passed in as a parameter before the script is executed. If the user is using HTML5, “history.pushState” can be used to change the URI currently displayed to the user, and take out the query string, that is no longer required.

There are many different ways this cookie can be retrieved from the URI, but the most straightforward is the split() function that String type variables have in Javascript. This allows you to return a list of strings, split up on a given string. For example, in the case of the SCL URI, if .split(“?”) was called, [“”, “param=123#body”] is returned. Using this knowledge, the URI can be split apart, the correct components retrieved and stored, and then the rest of the URI constructed back together at the end of the process.