- Optimizely X Web Experimentation
- Optimizely X Web Personalization
This article WILL HELP YOU:
- Test two landing pages, homepages, or any other pages against each other
- Set up redirect experiments (split URL tests), which redirect visitors from one URL to another
- Ensure that you can track events on both your original and redirect pages
Redirects at a glance
Redirect experiments, or split tests, allow you to compare two separate URLs as variations in an A/B test. For example, you might create a redirect experiment that compares two versions of a landing page.
- Use redirects if your variation code exceeds 200 lines
- Check Redirect with live query parameters included to keep the parameter attached in the variation
- Leave Allow Additional Redirects unchecked to prevent subsequent redirects
- Use an event to track clicks on the redirected variation
What to watch out for
In Optimizely, redirect experiments help you test whole pages against each other. You can create "split URL" experiments that redirect visitors to a different URL as a variation.
This is useful when comparing landing pages, or multiple versions of a single page that lie on different URLs. Testing whole pages against each other is a proven way to perform deep experimentation.
In this article, you will walk through each stage of setting up a redirect experiment: setting up the experiment targeting, settings up the metrics, and creating the redirect variations.
1. Set up a page to redirect visitors from
To set up a redirect experiment, first determine where the experiment should activate. This is the URL that visitors are redirected from. It's also the page where visitors are bucketed into the experiment. We'll call this the "original URL" in the rest of this article.
Based on the audience conditions that you set up, some visitors may remain on this page while others will be bucketed into a variation that redirects them to a different page.
For example, if the experiment redirects from atticandbutton.us/homepage to atticandbutton.us/accessories, then the original URL is atticandbutton.us/homepage.
Set up a new page that targets only the original URL that you're redirecting visitors from. This will the page that you add to your redirect experiment.
2. Set up a page to track events across both URLs
In most redirect experiments, you'll want to track an event on both the original URL and the redirect URL. You'll create one page that captures both URLs where you'll add and track events.
When running redirect experiments, it's important to track metrics that apply to both the original and redirect pages. We recommend running redirect experiments on pages with similar roles and purposes to ensure the impact is tracked correctly.
First, create a page that captures both URLs:
Create a new page that you'll use to add the events you'll track in this experiment. From the dropdown, choose A set of URLs and target both the original URL and the redirect URL.
If the experiment redirects visitors from atticandbutton.us/homepage to atticandbutton.us/accessories, this page should target both URLs.
Next, add a new event to this page. Navigate to Events > select this page > select Create Event.
Sometimes, the selector for the same event may be named differently on your two pages. Make sure the selectors from both pages are included.
For example, if you want to track a Shop Now button both in the original (atticandbutton.us/homepage) and in the redirect URL (atticandbutton.us/accessories). Here's how to include both:
Open both URLs in your browser.
Right-click the button element and select Inspect Element. A console will pop up, and the element will be highlighted on the page.
Right-click the highlighted element and select Copy > Copy selector.
Paste this selector into the Selector field of the click event. You can add multiple selectors by separating them with commas.
Click Save to track events across both pages.
3. Set up the experiment
Navigate to Experiments and click the Create New > A/B Test.
Add the first page you created, which targets only the original URL. This is the only page that should activate your redirect experiment.
Add the events you created in Step 2, which you'll use to measure success.
Add an audience, if you like.
Adjust the traffic allocation and distribution between your variations, if you like. The original variation is the original URL; the next variation is the URL that visitors are being redirected to.
Take care when choosing to use asynchronous conditions to target redirects, such as geotargeting, List Attributes, and some third party analytics integrations. When you use asynchronous conditions to target a redirect, the initiation of the redirect may be delayed. During the delay, you may see other experiments activate or events tracked on the page that visitors are being redirect from. If you've defined a metric based on those events, you may see those visitor actions reflected on your Results page.
The Optimizely snippet must be implemented on all pages where the experiment will run and where events will be tracked. Make sure the snippet is included on both the original URL and the redirect URL. Otherwise, some visitors and events may not be tracked.
Experiments that redirect to a different domain may experience tracking issues for those redirected visitors. Learn more about cross-domain tracking.
4. Add the redirect to your variation
Next, you'll set up the redirect to the variation URL.
Under Manage Experiment > Variations, select the variation (not the original). This is where redirected visitors will land.
Under Create Options, select Redirect:
If you select URL, paste in either the complete URL or the relative path where you'd like visitors to be redirected to.
If you select Code, define a function that returns a URL string where you'd like to redirect visitors:
When you load a redirect page, you won't be able to edit it with the Visual Editor. Instead, you'll see this prompt:
5. QA and publish your experiment
Congratulations! You've set up a redirect experiment. All you need to do now is QA the experiment and publish it live to your visitors.
Indicate the canonical link. To improve SEO link and ranking signals, the redirected page should indicate that the original page is the preferred (canonical) destination. Add a
<link>element with the
rel="canonical"attribute into the
<head>section of the redirected page. Check out this Google Support Doc for more information.
Exclude the redirect URL. To avoid redirects on the redirect URL itself, make sure to exclude the redirect URL via the page targeting settings.
Unblock Optmizely's redirect. By default, when you set a redirect, Optimizely blocks other redirects for 5 seconds so that you will not cause an infinite loop of redirects. Click to learn about unblocking the redirect.
Client typically have three main concerns with redirects
- Will visitors see a flicker of images/old page loading prior to being redirected?
- No, Optimizely redirects will hide the body of the original page using CSS, so there will be no flashing/flickering
- How does the redirect work?
- We use window.location.replace. This is called immediately after the bucketing decision.
- Origin page will not load and no additional requests will be made on the original page after this location.replace is called.
- In Chrome, in-flight XHR requests are cancelled by the browser when location.replace is called
- How can we ensure mobile visitors don't have a poor experience?
- You can do a QA cookie-gated experiment, and evaluate performance by using Chrome dev tools (using throttling and device emulation)
- Will the user be able to click the Back Button in their browser to go back to the origin page?
- No. We use window.location.replace(), so the back button will not bring the user back to the original homepage.
- Having the Snippet as high in the head as possible is vital
- Having any asynchronous components for this experiment will delay the redirect from happening. This includes asynchronous audience conditions (ie, geotargeting) and conditional page activation that does polling or some other async operation.
- Canonical <link> tag - You should add a link tag to the head of your page which tells Google that the canonical version of the page lives at a different URL. We provide some details on that here.
- Robots.txt entry - search engines that respect this convention will skip over URLs that follow the disallow directive - Robots documentation here.
Clients typically have client-side analytics tools in place, and want to make sure that the data being transmitted to those systems is useful. On the post-redirect (variant) page, the document.referrer is actually the pre-redirect page URL, which is not very useful. In some cases, the client may want to report that the true referrer was the document.referrer of the pre-redirect page.
They can use our getRedirectInfo method (docs) to capture the original referrer if they'd like to pass it to their third-party analytics systems:
var redirectInfo = window.optimizely.get('state')
var realReferrer = redirectInfo.referrer;
Messaging to customers concerned about redirects
- We have had high-profile clients run long-standing, high-trafficked redirect experiments - even on their homepage!
- They did not observe any adverse effects to their SEO
- They did not observe material impact to their bounce rate.
- These are anecdotal, but it's worth mentioning that a highly risk-averse company trusted us to handle a Homepage redirect
- Please do not mention "State Farm" (NDA)
- SEO impact is out Optimizely Web client's control - it's largely dependent on how various engines index dynamic content, and there is no consistent documentation out there to accurately characterize SEO impacts of client-side redirects.