Deployment and Implementation Overview
      Back to home
      1. Help Center
      2. Implementation, Deployment, and Security
      3. Deployment and Implementation Overview

      SiteSpect Implementation

      FAQs


      What information do we need to provide to implement SiteSpect Cloud on our infrastructure?
      To configure your testing and targeting program in SiteSpect, you must route traffic through a SiteSpect Cloud environment. Your origin remains untouched, but certain pieces of information are needed to route traffic correctly. This information tells us which websites to route through SiteSpect, which protocols to use, and on which ports to listen. Specifically, we'll need front-end URLs, back-end URLs, and any applicable SSL certificates.

      The front-end is made up of the protocol (http or https), the hostname, and the port (usually 80 or 443) through which site visitors interact with your website. In most cases, this is the URL that has been in use prior to implementing SiteSpect. 

      The back-end is the origin address (the origin server's IP address or hostname) to which SiteSpect connects when proxying requests for site visitors. This is where SiteSpect goes to get content. Often the protocols and ports are the same as the front-end, but clients may use different settings and even choose a different IP address from the one used for public DNS settings. When a back-end hostname is in use, SiteSpect will perform a DNS lookup on the hostname to obtain an IP address.


      SiteSpect is configured to handle both HTTP and HTTPS traffic. To do so we deploy an SSL certificate and key for your site’s traffic onto the SiteSpect Cluster.  There are several options for deploying certificates for your site.

      Once we have that information, we can then build out your new SiteSpect instance. This includes configuring all sites listed, certificates, and CDN or DNS configurations. This process takes only minutes in our Cloud. While we do that, we'll ask you to deploy healthcheck files which allows SiteSpect to communicate with your web servers and detect the status of the connection, the healthcheck request is sent approximately once per second.

      If you have separate stage and production environments, we'll repeat the configuration for your production environment.  Finally, once everything has been staged all that's left to do is update your CDN or DNS configuration to start routing traffic through SiteSpect.

      For DNS deployment, we would ask you to reduce the TTL of your DNS record to 300 seconds. This should be done at least 24 hours in advance of your go-live date.


      How long does it take to implement SiteSpect on our infrastructure?
      SiteSpect has been deployed and tests have been run as quickly as 3 days. We collect the above mentioned requirements from you to configure the system, which usually takes about 3 - 5 hours on our side. If you have a CDN, then there may be additional rules that need to be applied and that may elongate the implementation process by a few additional days.


      What resources do you need from the client side to implements SiteSpect?
      To ensure a successful deployment, the implementation process is a coordinated effort between SiteSpect and your technical teams that manage your web infrastructure, security, and network.


      How do you work with our CDN during implementation?
      SiteSpect provides a list of simple rules that you must deploy to the CDN. We work closely with your team and your CDN vendor to ensure that these rules are set up correctly and in a timely fashion.


      Does SiteSpect pass-through files that aren't typically tested?
      Yes, by default images, javascript libraries, and CSS libraries that are hosted on a domain that is routing through SiteSpect will be passed-through. These options are configurable but the typical scenario is that page sources and JSON represent what most clients want to test on or measure.


      Can we access our original page that our origin is serving, even when 100% of our site traffic is routing through SiteSpect?
      When the control variation group in any campaign is previewed, the default or original pages are shown. If it is desired to test a condition where SiteSpect is completely removed, There are a couple of options:

      1. To go to the unmodified page that the origin is serving, without routing traffic through SiteSpect, you can modify your local host file to force traffic for a host name to go to a certain IP address.
      For example, if the origin IP is 63.2.3.4, and the hostname is www.example.com, add below entry into your host file:
      # Go to the Origin for www.example.com
      63.2.3.4    www.example.com
      1. Alternatively, if your site is configured to support it - setting the SSLB=0 will signal the load balancer to route around SiteSpect.

      How does SiteSpect define a Site and Domain?
      SiteSpect logically groups client site configurations into two sections: Sites and Domains.

      • A Site is a logical grouping of configurations. Campaign configurations and data are shared across all traffic that routes within it.
      • A Domain is the virtual host used for proxying traffic.

      A Site may have multiple Domains, but a Domain can only belong to one Site. Here are some examples:
       

      Example 1 – A single subdomain, HTTP and HTTPS traffic:
      • You manage one website (www.example.com).
      • You have both HTTP and HTTPS traffic.
      • In SiteSpect, you would have one Site with two Domains (one for http://www.example.com and one for https://www.example.com)
      • All traffic routed to either Domain is eligible for testing.
      • As a user transitions between HTTP and HTTPS, their testing experience remains the same.
      Example 2 – Two subdomains, HTTP and HTTPS traffic on both, testing user behavior across both:
      Example 3 - Two subdomains, HTTP and HTTPS traffic on both, testing user behavior on both subdomains but isolated from each other:
      • You manage one website with two subdomains www.example.com and  shop.example.com.
      • You have both HTTP and HTTPS traffic for both subdomains.
      • You want to be able to test a user’s experience separately for each subdomain and do not want to intermingle the resulting data.
      • In SiteSpect, you would have two Sites with two Domains each (one for http://www.example.com, one for https://www.example.com on Site 1, and one for http://shop.example.com, and one for https://shop.example.com on Site 2).
      • All traffic routed to any of the four Domains is eligible for testing.
      • As a user transitions between HTTP and HTTPS within the subdomain, their testing experience remains the same.
      • When a user transitions between www and shop, their sessions are treated independently.
      • The resulting test data is also separate: data for www does not intermingle with data for shop.