Create a Server-Side Campaign
      Back to home
      1. Help Center
      2. Build
      3. Create a Server-Side Campaign

      Server-Side / Origin Experiments

      An Origin Experiment in SiteSpect refers to a type of testing where the variation shown to users is determined by the origin web server rather than by SiteSpect directly manipulating the content. This is achieved by signaling the origin web server with a value that indicates which variation to show. The value can be communicated through various means, such as a cookie, header, query parameter, or URL.

      Note: this feature may not be enabled in your account; contact the SiteSpect Help Desk to enable Origin Experiments for your Site.

      In a typical SiteSpect campaign, assignment decisions are made during the response to a request for a new visit. However, Origin Experiment Campaigns differ in that these assignment decisions occur during the first request (or first pageview) of a new visit. SiteSpect then signals your web or application servers about the assigned Variations using specified values. Your origin servers can detect this signal from the initial request, and it will persist through all subsequent requests made by the visitor within the Origin Experiment Campaign, provided that audience and trigger rules are met.

      Remember that when using an Origin Experiment, you need to have fully developed both the existing and new experiences within your server or application.

      Common Issues with Launching New Features

      When launching a new website or introducing new functionality, there is uncertainty about the outcome. Here are some common challenges, often referred to as the push-and-pray method:

      1. Immediate Exposure: When the new site goes live, all visitors see it immediately. If there’s an issue, everyone is affected.
      2. Lack of Testing: Without proper testing, it’s impossible to measure the conversion rates of the new site accurately.
      3. Uncertain Causes: It’s difficult to determine if changes in conversion rates are due to the new release or other factors.

      How Origin Experiments Can Help

      Origin Experiments solve these problems by offering the following solutions:

      1. Reducing Unknown Variables: They eliminate as many unknowns as possible, ensuring a more controlled release.
      2. Optimal Initial Experience: They provide the best possible user experience from the first request.
      3. Controlled Testing: They allow you to test a new release or feature before enabling it for all traffic, ensuring any issues can be addressed without affecting all users.

      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:
        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.
      Note: When you use an Origin Experiment for release testing, your load balancer can detect the Origin Experiment cookie, parameter or header and route the request to the correct origin. In this way, you can use an Origin Experiment to implement blue-green releases.