Origin Experiments

Origin Experiments are Campaigns that allow your origin web server or load balancer to identify which Campaign and Variation Group a visitor is assigned to on their initial HTTP request, and on subsequent requests during their visit. This allows your website to return content not easily created using traditional Campaigns. This feature may not be enabled in your account; contact the SiteSpect Help Desk to enable Origin Experiments for your Site.

SiteSpect normally makes assignment decisions during the response to the request for a new visit. Origin Experiment Campaigns work differently in that the assignment decisions for Origin Experiment Campaigns occur during the first request (first pageview) of a new visit. SiteSpect then signals your web servers which Variations visitors have been assigned to using values you specify.

SiteSpect can signal your origin in a number of different ways. It can send a signal using a URL parameter, a custom HTTP request header, or a cookie (the cookie persists in the subsequent response). The signal sent by the SiteSpect Origin Experiment identifies which Campaigns and Variations visitors have been assigned to. Your origin servers behind SiteSpect can see this signal starting from the initial request. SiteSpect inserts this signal into all requests a visitor makes when the visitor is assigned to an Origin Experiments Campaign.

Keep in mind that when you use an Origin Experiment, you have to have built both experiences, the existing and the new one, in their entirety within your web application.

When you launch a new website or introduce some new functionality, you may be daunted because you don’t know how it’s going to go. You may face the following common issues, which are collectively known as the push-and-pray method:

• When you push out the new site, all your visitors see the new site; if there’s a problem with the new site, all visitors are exposed to it.
• You can’t measure conversion for a new site if you can’t test.
• You can’t tell if conversion changes are due to the new release or some other cause.

Origin Experiments solve these problems. They provide the following solutions:

• They remove as many unknown variables as possible.
• They provide the right experience from the first request.
• They allow you to test a release or new feature before you enable it for all traffic.

Use Cases

You can use an Origin Experiment to:

• Beta test a whole new website. Say you've spent months of development hours reworking your site. You want to make sure you don't expose all your visitors to the new experience right off the bat. You can use an Origin Experiment to test the new site with a sample of your visitors.
• Perform feature flag testing:
• Test a new search algorithm.
• Test a new checkout flow.
• Test some other feature or functionality.
• As part of your regular site release cadence for such things as canary releases or blue/green deployments.

How does it work?

Origin Experiments work as follows:

1. First, a visitor makes a request to your website; that request goes to SiteSpect.
2. If the visitor is assigned to an Origin Experiment Campaign that visitor is associated with a special header, cookie, URL, or query parameter as defined in the Campaign. If the Origin Experiment Campaign uses a URL or Query Parameter as its Type, SiteSpect changes the URL of the request to go somewhere else as it proxies forward to your origin.
3. The request now goes to the origin with that header, cookie, URL, or query parameter. You configure your origin web application or load balancer to look for the Origin Experiment header, cookie, URL, or query parameter and then execute the change only when it exists in the request with the correct value.
   1. Cookie: This is the most typical setup. You can determine your own Cookie Name or name it SSOE (SiteSpect Origin Experiment). In the Campaign, you then provide that Cookie Name and Value that serves visitors with a specific experience. For example:
      • Cookie Name: SSOE
      • Cookie Value: 1a
   2. Query Parameter: Part of the URL (i.e., request URL), specifically the parameters in the URL are used to serve a specific experience. For example, you can search for the Parameter page=home and replace it with page=home&mvt=returnvisitor. Visitors see the experience here:
      • http://www.mysite.com?page=home&mvt=returnvisitor
   3. URL: The URL serves visitors with a specific experience. For example, if you search for the URL http://mysite.com/products and replace it with http://mysite.com/new-products, visitors see the experience at the latter. The URL in the browser still says http://mysite.com/products, but the visitor sees the new content that was served by the origin web application at http://mysite.com/newproducts.
   4. Header: Let’s say you want to test a new product search algorithm. You could achieve this using an HTTP Header. For example:
      • Header Name: ABProdSearch
      • Header Value: Control or NewSearch
4. The origin delivers a changed experience back to SiteSpect which passes it back to the visitor's browser.