Skip to main content

Cross-domain tracking

What is cross-domain tracking and when do you need it​

Kameleoon supports cross-domain tracking, which allows tracking of visitors across different (sub-)domains. This means that a visit that started on one domain and continued on another related domain can be considered as a single visit. Enabling this option is recommended if you want to use session data across all your domains for advanced behavioral targeting in personalization campaigns. This will unify the data stored in the local storage for each (sub-)domain.

If you choose an implementation tag that does not support cross-domain tracking, a visit that starts in one domain will be tracked as a new visit once it reaches another related domain. This means that all data gathered on one domain (such as page views, time spent on site, etc.) will be reset on another domain. As a result, targeting based on such criteria can produce unexpected results when cross-domain tracking is not used. For example, if you have a personalization campaign triggering at the fourth page viewed, a visitor who sees three pages on your first website and loads a fourth page on a new domain website will trigger the personalization only if cross-domain tracking is used.

To use cross-domain tracking, you need to add an additional tag to your HTML source code.

Cross-domain tracking tag​

In order to enable cross-domain tracking in Kameleoon, you must host an iFrame file (provided below) on your website's main domain. This iFrame will be loaded whenever a visitor navigates to a page with a URL that does not match the main domain of the website. The iFrame HTML file is small and static, containing only immutable code that is used to save and restore visitor data in the Local Storage.

note

You should fetch the original file at the URL https://developers.kameleoon.com/resources/iframe_template.html. Right click on this link and choose "Save link as..." on your browser.

Inside the iFrame code, you should modify two variables (follow the comments inside the file to do so):

caution

To ensure optimal performance, it is crucial to set up appropriate caching for the iFrame file. Since the file remains static and does not change, there is no need for the browser to redownload it. To achieve this, you can configure caching on the server using the following HTTP header: Cache-Control: max-age=2592000

In addition to hosting the iframe, you also need to include the following installation snippet provided below. Make sure to provide the correct value for the kameleoonIframeURL variable in the implementation code. This variable should be set to the URL where the iFrame is accessible on your own website.

<script type="text/javascript">
  // Change the value of this URL to point to your own URL, where the iFrame is hosted
  window.kameleoonIframeURL = "https://www.customerdomain.com/path/to/kameleoon-iframe.html";

  window.kameleoonLightIframe = false;
  var kameleoonIframeOriginElement = document.createElement("a");
  kameleoonIframeOriginElement.href = kameleoonIframeURL;
  window.kameleoonIframeOrigin = kameleoonIframeOriginElement.origin || (kameleoonIframeOriginElement.protocol + "//" + kameleoonIframeOriginElement.hostname);
  if (location.href.indexOf(window.kameleoonIframeOrigin) != 0) {
    window.kameleoonLightIframe = true;
    var kameleoonProcessMessageEvent = function(event) {
      if (window.kameleoonIframeOrigin == event.origin && event.data.slice && event.data.slice(0,9) == "Kameleoon") {
        window.removeEventListener("message", kameleoonProcessMessageEvent);
        window.kameleoonExternalIFrameLoaded = true;
        if (window.Kameleoon) {
          eval(event.data);
          Kameleoon.Analyst.load();
        } else {
          window.kameleoonExternalIFrameLoadedData = event.data;
        }
      }
    };
    if (window.addEventListener) {
      window.addEventListener("message", kameleoonProcessMessageEvent, false);
    }
    var iframeNode = document.createElement("iframe");
    iframeNode.src = kameleoonIframeURL;
    iframeNode.id = "kameleoonExternalIframe";
    iframeNode.style = "float: left !important; opacity: 0.0 !important; width: 0px !important; height: 0px !important;";
    document.head.appendChild(iframeNode);
  }
</script>
note

It is essential that the iFrame file be hosted on your servers in the main domain of your website. If you have multiple domains, choose the most significant one. Your technical team must carry out this mandatory step. Technically, Kameleoon always uses your main domain to store content in the browser's Local Storage. If the current URL matches the main domain, the Kameleoon engine can directly write data to the associated Local Storage space. However, if the URL belongs to another domain, we will load the iFrame file, which contains static code that can only read and write Kameleoon data on the main domain.

info

The cross-domain tracking snippet can be used in a Tag Manager installation without any problem.

Cross-domain vulnerability​

When using a cross-domain setup, a minor security issue arises. Since all Kameleoon visitor data will be written in a Local Storage belonging to an external domain, a malicious website could potentially read this data by including your iFrame in their page. Once loaded, the iFrame will always return the Kameleoon data via a postMessage() call. This could include any custom data that you may have set up, which may contain confidential or sensitive information.

note

This exploit is limited to visitors who first visit your website and then visit the malicious site, so it is a front-end exploit. Therefore, it is not possible for an attacker to obtain data for all your visitors. Nevertheless, you can enhance security by restricting access to the iFrame to a specified list of domains and subdomains, including your own. This list must be provided in the allowedDomains variable within the static iFrame file.

To enhance the security of the Kameleoon iframe, we have implemented the following three measures:

  1. Restricting access to identified domains: The iframe code includes an allowedDomains variable that specifies which domains are authorized to request the iframe. Only the domains listed in this variable can load and execute code from the Kameleoon iframe. This ensures that the iframe cannot load or execute outside of your own domains.

  2. Restricting access to identified site codes: The iframe code also includes a siteCode variable that ensures only a Kameleoon engine with the specified site code is permitted to request the iframe.

  3. Prefixed Local Storage: The iframe (and Kameleoon in general) can only read and write entries that begin with the prefix "kameleoon". No other data can be read or written, adding an extra layer of security.

note

To enable cross-domain tracking through Kameleoon, it is necessary for the Kameleoon iFrame to load on all of your domains. Therefore, you should not set an X-Frame-Options response header.

Last updated on