1. Help Center
  2. Third-Party Integration

Implementing SiteSpect Cloud with Cloudflare

This article describes how to implement SiteSpect using our cloud architecture. It assumes that end-user traffic is routed to the SiteSpect Cloud using a Cloudflare CDN. The SiteSpect Cloud then proxies requests back to your web server infrastructure or your Cloudflare CDN for content.

Deployment Description

The Technical Overview and Deployment Options sections provide details on how your site is deployed through SiteSpect as well as some information about the SiteSpect infrastructure.

Technical Overview

SiteSpect’s technology allows you to test the user experience—web or mobile, front-end changes or updates to code or infrastructure—all without the need to use tags.

While SiteSpect offers different types of implementations, this document specifically discusses using an Cloudflare CDN to front your traffic and having the CDN route requests to the SiteSpect Cloud.

The SiteSpect Cloud then proxies a request back to your web server infrastructure, either directly or using another request to your CDN. Your infrastructure then responds back to SiteSpect with content. It is at this point that SiteSpect takes measurements and makes dynamic modifications to the HTML based on rules designed by your SiteSpect developer. This modified HTML is returned to the end user, whose browser renders the content.

Deployment

The Cloudflare CDN is deployment is configured as in the following traffic flow image. This configuration allows you to continue to serve static content from the CDN while allowing you to take full advantage of the SiteSpect platform.

Your Cloudflare CDN will be configured to route all HTML objects to SiteSpect, while routing most all other objects to your web server infrastructure. SiteSpect will provide a DNS name that your CDN will use as an origin when routing traffic to SiteSpect. Traffic received by SiteSpect will be proxied to your web server infrastructure for content.

Rules to be implemented on the CDN configuration:

1.Change the origin to SiteSpect.

2.Follow below caching instructions for each and every domain. Note that they are order dependent:

2a. Bypass caching for the following: 

    •  /__ssobj/ard.png*
    • ?SS_PREVIEW_EXP* 
  • /__ssobj/*

2b.  Cache the following with a recommended TTL of 60 mins:

  • /__ssobj/*.js
  • /__ssobj/static/*

Action on Cloudflare configuration - under Page Rules, implement the following:

  1. www.example.com/__ssobj/ard.png*       Cache Level: Bypass 
  2. www.example.com/?SS_PREVIEW_EXP*  Cache Level: Bypass
  3. www.example.com/__ssobj/*                     Cache Level:Bypass
  4. www.example.com/__ssobj/*.js                 Edge Cache TTL: an hour
  5. www.example.com/__ssobj/static/*        Edge Cache TTL: an hour  

SiteSpect Bypass Mode

SiteSpect Bypass uses DNS to point traffic away from us.  SiteSpect would point traffic directly to your Origin when in Bypass mode.  


System Architecture and Configuration

SiteSpect configurations are centrally managed through the SiteSpect web interface, where SiteSpect users also setup their test and targeting campaigns and run reports analyzing the results of those tests.

Technology Points of Presence

The SiteSpect Cloud is designed with resiliency, redundancy, and efficiency in mind. Traffic is routed through our Points of Presence (POPs), currently nine, strategically located in different parts of the US and Europe. Site visitors are dynamically routed to the best performing POPs based on network conditions for their geographic locations.

Within each SiteSpect POP, traffic is directed to devices called engines, reverse proxy devices with SiteSpect code. Each engine has the same configuration as all other engines. Site visitor sessions are managed using cookies. Site visitors can route from engine to engine and POP to POP without any effect on the customer experience.

SiteSpect uses advanced DNS technologies to ensure that visitors are always routed to the best performing entry point into the SiteSpect Cloud at all times.

Deployment Process

To ensure a successful launch, the deployment process is a coordinated effort between SiteSpect and the technical teams that manage your web infrastructure, security, and network. SiteSpect will provide a detailed project plan with checks and balances, as well as specific instructions.

Prerequisites

Health and performance objects

You will need to deploy two objects to your web infrastructure. These are basic HTML files used to verify SiteSpect’s ability to proxy requests all the way to your origin as well as measure which route is fastest for different geographic regions. Note: SiteSpect accesses these objects multiple times per second; deploy them onto a static portion of your site.

Security/SSL Certificates

SiteSpect is configured to handle both HTTP and HTTPS traffic. 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. The options are:

  • Use your existing certificate and key file.
  • Provide a new certificate and key file.
  • SiteSpect can generate a certificate signing request (CSR).
  • SiteSpect can provision a self-signed certificate (not recommended for production sites).

Authorized users within your organization directly upload SSL key files. SiteSpect employees do not handle SSL keys.
SiteSpect automatically tracks SSL certificate expiration. SiteSpect sends automatic notifications to active users approximately 45 days in advance of the certificate expiration to coordinate updating the certificate.

Change Management

SiteSpect directly manages system patching and upgrades in a transparent manner.

SiteSpect Sites and Domains

SiteSpect logically groups client 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 route 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.

The following provide 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 an end 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 an end user transitions between HTTP and HTTPS within the subdomain, their testing experience would remain the same.
  • When an end user transitions between www and shop, their sessions are treated independently from one another.
  • The resulting test data is also separate. Data for www does not intermingle with data for shop.

Support

For technical support, contact helpdesk@sitespect.com or +1-617-859- 1900, x2. (Toll free number: 1-888-544-0224, x2).

SiteSpect’s business hours are 9 AM – 8 PM ET. Emergency 24/7 support is available outside of SiteSpect business hours at +1-617-859-1900, x2.