Enhanced redirect analytics
Skip Ahead
- Run redirect experiments across origins
- Track events and visitors of a redirect experiment in third-party analytics
In response to a redirect event tracking issue, we updated how Optimizely X tracks data across origins for redirect experiments. When performing a redirect, the snippet can now store information about the campaign decision in a cookie, allowing the snippet on the post-redirect page to track the decision to various analytics back ends.
If you are using enhanced redirect analytics, you'll see this dialog when using the redirect feature:
Supported redirects and analytics integrations
Enhanced redirect tracking supports redirects from:
-
One origin to another within a single cookie domain
-
One snippet to another, even between unlinked projects, as long as the two snippets are in the same account.
Additional configuration may be necessary when redirecting from one snippet to another.
Enhanced redirect tracking also supports analytics tracking with:
-
Optimizely results (including with X Events API enabled)
Unsupported redirects and analytics integrations
Enhanced redirect tracking does not support redirects from one cookie domain to another.
Enhanced redirect tracking also does not support analytics tracking with Clicktale. If you use enhanced redirect tracking with Clicktale analytics tracking, you may not see any visitors in the redirect variation.
Third-party analytics and redirecting to a page with a different snippet
We don't include code for all possible integrations in every snippet. That would waste bandwidth and slow your page load time. Instead, we add integration code to the snippet when you enable an integration for a project or experiment.
If you are using a third-party analytics integration and redirecting to a page with a different Optimizely snippet in your account, the post-redirect snippet needs to have the analytics integrations enabled separately. This means if you intend to track the redirect experiment using a tool like Google Analytics, the snippet on the page you are redirecting to needs to also have the Google Analytics integration enabled. Because integrations are typically enabled on a per-experiment basis, this could mean the post-redirect snippet doesn't know about the redirect experiment and its integration settings.
Here are a few suggestions for working around this constraint:
-
Enable the integration for all experiments in the project where the post-redirect snippet lives (this option is not available for all integrations)
-
If there is already an experiment running in that snippet that is using the integration, the redirect should work properly, although you might experience issues like another user pausing the test before yours is complete
-
Create an A/A test for that post-redirect page's snippet where you use the Google Analytics integration
Debugging the redirect cookie
Append ?optimizely_log=debug
to your URL and open the developer console in your browser. Search the log for a line containing Optly / Relay / Found redirect cookie
. That line will contain the cookie information. The cookie is set on pre-redirect page and the Optimizely log is reading and printing it from the post-redirect page.
If you parse the cookie information by "&" you can review the data passed from the pre-redirect page to the post-redirect page.
Relayed field name | Purpose | More info |
---|---|---|
a |
Account ID | |
aId |
Activation ID | |
as |
Audience IDs | |
cV |
X Web client version | |
d |
Decision ID | |
i |
Visitor ID | |
isv |
Integration string version | Indicates the analytics naming convention |
l |
Campaign ID | |
lN |
Campaign Name | Unavailable if masking descriptive names |
lP |
Campaign Policy | |
n |
Snippet Revision | |
ns |
localStorage Key Namespace |
|
p |
Project ID | |
r |
Referrer | Empty string if the referrer couldn't be determined on the pre-redirect page |
s |
Session ID | |
t |
Time since Unix epoch | Use a converter if you want a more readable timestamp |
v |
Variation ID | |
vN |
Variation Name | Unavailable if masking descriptive names |
x |
Experiment ID | |
xN |
Experiment Name | Unavailable if masking descriptive names |
What to watch out for
-
An opted-in snippet will set a large (but temporary) cookie for the duration of the redirect. Specifically, it will set an optimizelyRedirectData cookie that can contain ~500 characters, or even more if there was a long referrer URL to the pre-redirect page. This could cause the customer's server to return an error instead of the expected post-redirect page (but only for redirected visitors, and only in the immediate aftermath of a redirect; pausing the redirect experience will restore functionality).
-
We recommend that you QA the redirect experience on the customer's servers before unlocking it for live visitors.
-
Cookie size will decrease in the distant future. See Phase 3 of the redirects launch plan.
-
If you encounter any issues, ping @nikhil in the #analytics-redirects Slack channel, and feel free to follow the opt-out instructions at the bottom of this page.
Third-party analytics
If you're expecting results via one of the supported third-party analytics integrations, you need to make sure the integration is included in the post-redirect snippet even though that the integration may not be explicitly enabled for any campaign or experiment in that snippet.
For a redirect to a basic, project-specific snippet
You likely don't need to do anything here because you're original page and redirect page are on the same snippet and would include the 3rd party analytics tracker in the snippet if you enabled it for the experiment.
If you're redirecting to a separate snippet and want to ensure the 3rd party plugin is included in the snippet, you can follow these steps to add it.
Emulate the post-redirect project, go to Settings > Implementation > Optimizely, and ensure that the Overridden Defines section includes the following if enabling Adobe Analytics:
{ ... "__ANALYTICS__": { "ADOBE": true }, ... }
or the following if enabling Mixpanel:
{ ... "__ANALYTICS__": { "MIXPANEL": true }, ... }
or both:
{ ... "__ANALYTICS__": { "ADOBE": true, "MIXPANEL": true }, ... }
Each integration that you specify may increase the size of the snippet payload, so only include integrations that the customer is likely to use in their pre-redirect snippets.
If the project has no other Overridden Defines, remember to remove the trailing comma. The UI will warn you if you forget.
For a redirect to a custom snippet
Emulate the account, open your browser's developer console, and enter
(function(snippetName) { $.ajax('/api/v1/snippets').then(function (data) { var snippet = _.find(data, { resource_id: snippetName, }); var newOverriddenDefines = _.extend({}, snippet.client_build_settings.overridden_defines, { "__ANALYTICS__": { // Only include if necessary "ADOBE": true, // Only include if necessary "MIXPANEL": true, }, }); return $.ajax('/api/v1/snippets/' + snippet.id, { type: 'put', contentType: 'application/json', data: JSON.stringify({ "client_build_settings": { "overridden_defines": newOverriddenDefines } }), headers: { 'x-csrf-token': optlyConfig.csrf } }); }).then(function () { console.log('Enabled new cookie redirects in snippet:', snippetName); }, function (e) { console.log('Error enabling new cookie redirects in snippet:', snippetName, e); }); })('SNIPPET_NAME');
after replacing SNIPPET_NAME
with the actual name of the post-redirect snippet and after filtering the list of integrations (ADOBE
, MIXPANEL
, etc.) as necessary. Each integration that you specify may increase the size of the snippet payload, so only include integrations that the customer is likely to use in their pre-redirect snippets.