Cross-origin tracking

You can implement behavioral targeting across your site's different origins (subdomains or protocols). An origin is a combination of a specific hostname, protocol, and port on your site. By default, Optimizely Web Experimentation only tracks events on the same origin. To track events that cross origins, you must set cross-origin event tracking.

You should set cross-origin tracking if your visitor often sees pages that are on different domains, subdomains, security protocols, or ports, and if you need to preserve experiment variations, behavioral targeting, or event tracking across these pages. 

For example, if your snippet is on https://shop.example.com, you can track events on that origin by default. Events generated on http://shop.example.com are not tracked because the security protocol is different, meaning a different origin. Likewise, events on http://example.com are not tracked because the subdomain is different. You need cross-origin tracking if you want to:

When you enable cross-origin tracking, you define a set of allowed and blocked origins. The origins you want to share visitor data with are the allowed origins. The origins you want to exclude from sharing are the blocked origins. 

Optimizely Web Experimentation can also set the cross-origin tracking allowed origins for you. When you enable auto-generated origins, Optimizely Web Experimentation automatically sets your allowed origins based on the URLs you use in the pages, URL targeting, and redirect experiments you create. You can manually move an origin from allowed to blocked if needed.

When you create a page, set URL targeting, or create a redirect variation, Optimizely Web Experimentation resolves the URL you provide down to the URL's top-level origin. The result mimics the scope of a cookie set on the base origin with a leading period. Visitor data is shared across all of the URL's subdomains and protocols.

If you set URL Targeting on https://shop.example.com, the auto-generated origin is example.com. Any page on that domain can access events from any other page, including:

Blocked origins take precedence, so a URL on your blocked origins list cannot access events from other origins even if you also set it as an allowed origin.

Cross-origin tracking is an account-level setting. Allowed, blocked, and auto-generated origins are aggregated across all projects in your account. 

If you use performance monitoring tools like Catchpoint, you see a synthetic increase in page performance and latency metrics. This change in performance is an artifact of the methods these tools use to track performance. It does not affect the actual performance of your page.

Optimizely Web Experimentation uses an iframe to seamlessly sync all events across those origins. This is done asynchronously and does not affect your visitors’ experience. However, you see the persistence of this iframe recorded in your performance monitoring tools as an increase in various page load metrics. These monitoring tools push out those measurements while waiting for the iframe to be added.

If you have a customer journey that does not cross origins, you may decide not to set cross-origin tracking at all. For example, if you run experiments exclusively on the domain https://shop.example.com and do not track events from a different subdomain (https://blog.example.com) or a different security protocol (http://shop.example.com), you may not need cross-origin tracking. 

If you do not track any events across origins, you can decide not to set it up. However, if you do not set cross-origin tracking and need to track events across origins, you risk losing event data.

Cross-origin tracking does not work if any of these are true:

Some browsers block cross-origin iframe localStorage if third-party cookies are disabled, and Optimizely Web Experimentation's iframe does not function when a visitor is on your website. In this situation, the Optimizely Web Experimentation iframe is from a third-party origin.

Events can be targeted across origins only for the current Optimizely Web Experimentation User ID, which is stored in the optimizelyEndUserId cookie. Browsers prevent sharing cookies across domains (for example,https://www.example.com and https://www.anotherexample.com) and across top-level domains (for example, https://www.example.com and https://www.example.net).

This means Optimizely Web Experimentation is unable to set consistent user IDs across such domains. For cross-domain targeting to work, you must manually sync the optimizelyEndUserId cookie across domains using other means. Optimizely recommends using the waitForOriginSyncfunction, as long as two snippets (projects) are linked and use the same localStorage namespace. (Using the same snippet across two domains is not necessarily required.)

For example, the following code would be implemented in the head tags before the Optimizely Web Experimentation Snippet, or in Project Javascript: