Implementing SiteSpect with AWS


SiteSpect is a customer experience testing, personalization, and optimization platform that makes and tests strategic changes to your website, mobile, and other digital applications. We leverage the power of personalization, omnichannel experiences, and A/B and Multivariate Testing to optimize your customer’s experience and measure the impact on your bottom line. We do this by routing some (or all) of your traffic through SiteSpect.

Our unique architecture empowers full front-end and server-side optimization, managed through a single interface to deliver a unified customer experience.

SiteSpect sits between your users and your server and sees requests from your users and responses from your server. Targeting and personalization rules are applied on the request, while variations and data collection happen inline on the response, before the page is delivered to the browser. This allows SiteSpect to deliver an optimal user experience without compromising performance. For example, SiteSpect may display a different page layout, a variation of an Add-to-Cart button, or an updated Shopping Cart experience.

Deploying AWS

SiteSpect AWS consists of two Amazon Machine Images (AMIs), an Admin Instance and an Engine Instance, that are deployed on Amazon Elastic Compute Cloud (Amazon EC2) instances. The Admin Instance allows you to interact with the SiteSpect user interface; the Engine Instance handles your traffic to perform content modification and data collection. Together, they are called a SiteSpect Virtual Private Cloud (VPC). You can leverage the power and flexibility of AWS to deploy your own SiteSpect VPC.

SiteSpect VPCs can be deployed with full redundancy and functionality within and across multiple AWS Regions and Availability Zones and can scale horizontally to accommodate any traffic volume by adding Engine Instances to an existing cluster. This allows you to scale across multiple geographic locations with ease.

Your website today in AWS:

Simple example of how SiteSpect can be deployed in your AWS environment:

In AWS, an end user’s request to a website is routed through a public IP, typically an Electric Load Balancing (ELB) instance.  The ELBs then routes these requests through the SiteSpect engines in the customer’s AWS VPC. The SiteSpect engines then proxy the request to the origin web servers making request header modifications where appropriate for the tests and targeting campaigns that are running. The origin servers respond back to SiteSpect and apply content modifications and KPI collection where appropriate for the tests and targeting campaigns that are running.

Load Balancing

Using your existing infrastructure, you route traffic to SiteSpect AWS (via load balancing, CDN, DNS, or a combination of all three) and SiteSpect proxies the request to your web nodes. You have full control over what traffic routes to SiteSpect and when.

Load-balancing is used to distribute load across engine instances to ensure an optimal customer experience.

Setup & Deployment

The following are typical steps involved in an AWS deployment. No matter how your environment is configured, we will work with you to meet your needs.

  1. The customer sets up their SiteSpect VPC.
  2. SiteSpect shares an Admin AMI and Engine AMI to enable the customer to deploy SiteSpect in their AWS environment.
  3. The customer provides SiteSpect with access to their AWS environment through secure shell (SSH) and HTTP(s) access to the Admin Instance.
  4. The customer shares details regarding the Sites they want to configure and route through SiteSpect.
  5. SiteSpect configures the admin and engine with the site details provided by the customer.
  6. The customer configures any load balancers (such as AWS ELB) and routes traffic through its engines.
  7. SiteSpect validates the configuration.

AMI Instance Types

SiteSpect recommends EC2 M4 instances for both Admin and Engine nodes to benefit from Enhanced Networking. Specifically, the m4.4xlarge instance type has proven to be reliable and stable in prolonged benchmark and real life scenarios with consistent performance and scaling capability. Based on your needs and traffic levels, a different instance type might better support your requirements.


What data does SiteSpect collect?

SiteSpect handles secure traffic for some of the world’s largest retail and financial sites. We capture a variety of data our customers need to build optimal experiences. Data includes:

  • Campaign & Variations IDs Viewed by Visitor
  • Strings & Number Identifying Conversion Goals
  • Strings & Number Identifying Customer Behavior
  • IP Address
  • Geographic location
  • User agent
  • Device Type
  • Entry URL and Referrer URL
  • Visit Times & Duration

Data is collected at the SiteSpect Reverse Proxy Servers used to service our customer traffic. The physical location of the data depends on your traffic and geo location requirements. AWS gives you the flexibility to deploy in various Regions and Availability Zones, based on your needs.

How do you secure our data?

The SiteSpect data layer is designed to minimize service interruption and ensure stability. SiteSpect data is stored in a distributed relational database replicated across multiple data centers. While SiteSpect traffic management is distributed across the globe, all data is stored within the United States.

By deploying SiteSpect in AWS, customers are able to take advantage of established AWS security practices. SiteSpect utilizes the following security groups:

Admin to Engine Communication

  • 22 (SSH)

Engine to Admin Communication

  • 22 (SSH, only replies, connections initiated by Admin)
  • 4430 (API calls)
  • 3308 (mysql replication)

On Engines

  • 8000, 8001, etc depending on number of Site Identities
  • 22  (SSH)
  • 3306 (local mysql connection)
  • 65500 (Apache status)

Is SiteSpect PCI Compliant?

SiteSpect Cloud is audited and pen-tested annually by an independent security firm to maintain our PCI compliance. This audit includes a formal reviVew and approval of our employee controls and data security policies. These policies include:

  • Access restrictions to customer account data
  • Access to systems containing your sensitive information is logged and audited
  • Authentication: Use of single sign-on, strong passwords and 2-factor authentication
  • No 3rd party access is granted to customer data

Who will have access to our data? Do you ever sell our data to third parties?

Only authorized SiteSpect employees have access to SiteSpect Customers' data for purposes of direct customer support or validation of changes to our product. SiteSpect subcontractors may have access to customer data when analyzing or maintaining infrastructure. Data collected by SiteSpect is never shared with anyone outside of SiteSpect and its subcontractors. Data access practices are audited regularly as part of an independent PCI compliance process.

How do you manage security incidents, once detected?

SiteSpect takes security extremely seriously. We actively monitor logs and employ penetration testing and log analyses services in order to identify potential breaches. SiteSpect has an established and rigorous incident management process for managing security incidents. In the event of an incident, affected systems are isolated and shut down while engineers capture the necessary forensic information for root cause analysis. The impacted systems are then wiped clean. With the forensic data we have collected, we perform impact analysis and follow our protocol for communication. SiteSpect has PCI Forensic Investigators on retainer should escalation be appropriate.

Do you respect role-based permissions?

Yes. SiteSpect provides the ability to set multiple different user roles to support a variety of business and security concerns. With seven different user roles, you can configure users to edit global site features, create campaigns, modify existing campaigns, or only to view existing campaigns and report data. Workflow features can restrict who has permission to impact live traffic and push configurations live. We include audit tracking so you can always see what testing configuration has been changed by which users.