This article describes how to implement SiteSpect using our cloud architecture. It assumes that end-user traffic is routed to the SiteSpect Cloud using an Fastly CDN. The SiteSpect Cloud then proxies requests back to your web server infrastructure or your Fastly 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 Fastly 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
Fastly CDN Option 1
If you do not cache HTML at the Fastly CDN, your deployment will be configured as in the following traffic flow. This configuration allows you to continue to serve static content from the CDN while allowing you to take full advantage of the SiteSpect platform.
End user => CDN => SiteSpect => Web Origin
Your Fastly 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 for Fastly CDN Option 1
Implement the following rules on your Fastly CDN configuration in this order:
- Ensure that the CDN always uses the SiteSpect Origin for requests that include /__ssobj/ or the ?SS_PREVIEW_EXP query string in the path.
- Ensure that requests for objects with /__ssobj/ or SS_PREVIEW_EXP in the path are not cached in front of SiteSpect. However, the following paths are an exception and may be stored at the CDN layer (we recommend a TTL of 60 minutes):
/__ssobj/core.js/__ssobj/core-debug.js/__ssobj/preview_history.js/__ssobj/inlinedit.js/__ssobj/core.js+ssdomvar.js+generic-adapter.js
Anything under /__ssobj/static/
- Follow these additional special handling instructions for requests for objects with /__ssobj/ or SS_PREVIEW_EXP in the path:
- Maintain and do not overwrite any cookies and caching headers set by SiteSpect.
- If the request includes SS_PREVIEW_EXP in the path, disable all Front End Optimization for the user’s session.
- Stop processing all other SiteSpect rules.
- If the request is for a binary object (provided by the client):
- Serve the request using the client’s defined caching rules or from the Client Origin.
- Stop processing all other SiteSpect rules.
- If the SSLB cookie is present in the request and has a value of 0:
- Serve the request using the client’s defined caching rules or from the Client Origin.
- Stop processing all other SiteSpect rules.
- If no SSLB cookie is present in the request, route the request to the SiteSpect Origin or to the Client Origin, based on an agreed upon percentage split:
- When routing the request to the Client Origin:
- Serve the request using the client’s defined caching rules or from the Client Origin.
- Optionally, on the response, set the SSLB cookie as a session-only cookie and give it a value of “0”, path or “/”, and set it to the top level domain (i.e., .example.com).
- Stop processing all other SiteSpect rules.
- When routing the request to the SiteSpect Origin:
- Do not cache the response.
- Maintain and do not overwrite any cookies and caching headers set by SiteSpect.
- Stop processing all other SiteSpect rules.
- If the SSLB cookie is present in the request and has a value of 1:
- Route the request to the SiteSpect Origin.
- Do not cache the response.
- Maintain and do not overwrite any cookies and caching headers set by SiteSpect.
- Stop processing all other SiteSpect rules.
Fastly CDN Option 2
If you cache HTML at the Fastly CDN, your deployment will be configured as illustrated below. This configuration allows you to continue to serve static content from the CDN, including HTML content, while allowing you to take full advantage of the SiteSpect platform.
End user => CDN 1st leg => SiteSpect => CDN 2nd leg =>Web Origin
Your 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 back to your CDN for content, preferably a cached response.
Rules for Fastly CDN Option 2
Implement the following rules on your Fastly CDN configuration in this order:
- When proxying a request to the SiteSpect Origin, the CDN must set an SSVisit:1 Request Header.
- If the SSVisit:1 Request Header is included in the request, then:
- The CDN must be able to accept a request from itself.
- Do not override any custom IP request headers previously set by the CDN (such as True-Client-IP).
- Do not override any custom geo location headers previously set.
- Serve content from the CDN cache or from the Client Origin.
- Stop processing SiteSpect rules.
- Ensure that the CDN always uses the SiteSpect Origin for requests that include /__ssobj/ or ?SS_PREVIEW_EXP query string in the path.
- Ensure that requests for objects with /__ssobj/ or SS_PREVIEW_EXP in the path are not cached in front of SiteSpect. However, the following paths are an exception and may be stored at the CDN layer (we recommend a TTL of 60 minutes):
/__ssobj/core.js/__ssobj/core-debug.js/__ssobj/preview_history.js/__ssobj/inlinedit.js/__ssobj/core.js+ssdomvar.js+generic-adapter.js
Anything under /__ssobj/static/
- Follow these additional special handling instructions for requests for objects with /__ssobj/ or SS_PREVIEW_EXP in the path:
- Maintain and do not overwrite any cookies and caching headers set by SiteSpect.
- If the request includes SS_PREVIEW_EXP in the path, disable all Front End Optimization for the user’s session.
- Stop processing all other SiteSpect rules.
- If the request is for a binary object (provided by the client):
- Serve the request using the client’s defined caching rules or from the Client Origin.
- Stop processing all other SiteSpect rules.
- If the SSLB cookie is present in the request and has a value of 0:
- Serve the request using the client’s defined caching rules or from the Client Origin.
- Stop processing all other SiteSpect rules.
- If no SSLB cookie is present in the request, route the request to the SiteSpect Origin or to the Client Origin, based on an agreed upon percentage split:
- When routing the request to the Client Origin:
- Serve the request using the client’s defined caching rules or from the Client Origin.
- Optionally, on the response, set the SSLB cookie as a session-only cookie and give it a value of “0”, path or “/”, and set it to the top level domain (i.e., .example.com).
- Stop processing all other SiteSpect rules.
- When routing the request to the SiteSpect Origin:
- Do not cache the response.
- Maintain and do not overwrite any cookies and caching headers set by SiteSpect.
- Stop processing all other SiteSpect rules.
- If the SSLB cookie is present in the request and has a value of 1:
- Route the request to the SiteSpect Origin.
- Do not cache the response.
- Maintain and do not overwrite any cookies and caching headers set by SiteSpect.
- Stop processing all other SiteSpect rules.
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:
- You manage one website with two subdomains, www and shop (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 across both subdomains.
- In SiteSpect, you would have one Site with four Domains (one for http://www.example.com, one for https://www.example.com, one for http://shop.example.com, and one for https://shop.example.com).
- All traffic routed to any of these four Domains is eligible for testing.
- As an end user transitions between HTTP and HTTPS, www and shop, their testing experience remains the same.
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.