[Guide] Technical information and security

• Summary: our Approach to Performance and Security
• Front-End
• Using AB Tasty
• Troubleshooting
  

Summary: our Approach to Performance and Security

Since the creation of the AB Tasty platform, providing our customers with a top-rated infrastructure has always been our priority. Throughout the years, we have been improving, redesigning and using the latest technology to make sure to achieve our goal.

We also continuously audit and review our process and most importantly the potential points of failure of our infrastructure to make sure we have taken the appropriate measures to avoid or mitigate the risk and to provide the appropriate answer in case of a security issue.

The way we manage this is detailed below.

Script generation and enforcing user access

The process of building a new script is an internal workflow that is executed directly in our protected infrastructure. Each new build goes into a full automated compilation process to guarantee the compatibility and integrity of each script. Unitary tests and automated QA are also performed to ensure the final quality of the file before being put into production.

Any issue automatically stops the production line and alerts are raised to the adequate team.

The JS script that will modify, display information and collect data on your visitors’ browser is entirely controlled and generated by the web interface. It is therefore critical you control who has access to the AB Tasty interface and how.

You will be provided with at least one “Administrator” privileged account allowing you to manage the users that have access to your AB Tasty account.

At any time, you can have a clear view of who has access to what and permanently remove a user.

Access is secured behind an authentication portal and no account can be shared: only nominative accounts are possible. You can enable Multi-Factor Authentication for more security directly in your AB Tasty Account Settings.

Only authorized users identified and named by you have the right to update the script and push new modifications in production.

Managing trusted sources of scripts

Compiled scripts are stored in a storage server in our secured and private infrastructure. 

Each script generates a single service instance (lambda) which will invalidate the CDN cache for this file each time a new version is put into production.

The CDN is required to authenticate itself to AB Tasty private storage when it receives a cache invalidation request. If the SSL certificate is validated, AB Tasty can then push the new script in the CDN.

This advanced design helps to protect from potential attacks.

CDN Security and performance

To avoid experiencing latency known as “Flickering Effect”, our goal is to ensure your visitors receive the best experiences possible without any flickering effect.

We are currently using AWS CloudFront and the excellence of its network to deliver the script to anyone accessing our resources. A user will always download the script from the closest geographical servers OR from the fastest one available.

CloudFront constantly monitors its servers for health and speed to provide load-balancing on its infrastructure.

AB Tasty also constantly monitors its own specific script delivery on various points of the globe and with a “user-like” methodology, to gather relevant and accurate measures of the actual performance for each customer.

Web performance

Once the AB Tasty script has been downloaded from our CDN, it is time for execution.

Depending on your business rules, several controls are operated. However, in order to reduce our footprint on your website as much as possible, we have determined that controls are more time and resource-consuming than simply running our entire script. That’s why this list has been stripped down to the essentials. For example, checking for Split Test (redirection: HTTP 302) will always be one of the first checks since it requires prompt execution.

Our execution is made asynchronous. All account settings, campaign information and modifications are stored in a JSON file which is passed to our “Modifications Engine”, an independent and optimized module, the only task of which is to apply OR remove the modifications. This module will check the required targeting when needed and will apply the requested modifications while being synchronized with the browser’s life cycle (requestAnimationFrame()).

The result is an indistinguishable refresh of the DOM to apply the adequate HTML / CSS / JS whenever it is needed.

Storage and backup

Finally, none of the above would be relevant without the ability to store and retain the data in a secure way.

Every customer has their own AB Tasty database, which is separate from the others.

We perform full encryption and databases are retained in our secured and private infrastructure at our hosting partners’ datacenter, Google Cloud Platform.

Front-End

JavaScript tag

Implementation

We provide both synchronous and asynchronous tags. Both can be found in the AB Tasty Settings.

Settings > Tags implementation > Generic Tag

China specific tag

We also provide a dedicated tag for China with a dedicated delivery infrastructure (CDN).

Settings > Tags implementation > Generic tag for Chinese audience

Compatibility with Tag Management System

We have a native integration with Commanders Act, Tealium and Google Tag Manager. A smooth integration with other TMS is also possible. Please refer to your provider for more guidelines.

Implementation best practices

In order to prevent any delay in the application of the modifications (known as « Flickering Effect ») we recommend the following implementation:

• Synchronous tag
• In the <head> of the webpage
• On top of all other scripts
• Hard-coded (not in a TMS)

Please adjust the implementation depending on your needs and particularities. However a deteriorated implementation by you can lead to bad performance once put into production.

AB Tasty Script

Execution

The AB Tasty tag will download a JS script that will be executed as soon as download is complete. The script will try to execute again on DOM Ready if it couldn’t before because of pending targeting criteria.

For specific website configuration or experiments, a specific configuration can be set up per experiment to let the script wait until the targeting criteria are met. It will then frequently check for the availability of its condition (every 16 ms).

Once executed, the script will apply every modification as a custom layer on your website to replace styles and will execute JavaScript queries to manipulate the DOM.

Technology

The script runs on native JavaScript and doesn’t require any external libraries.

For the ease of creating modifications, a parameter can be set to inject jQuery 1.7.1 into our framework. This version of jQuery is embedded in our framework and won’t interfere with your own.

Size and download time

The script weighs around 35 kB. The number of tests launched simultaneously has a direct impact on the AB Tasty tag (total of around 70 kB for 10 running experiments). 

Chrome Extension

We provide an AB Tasty Chrome extension that has several functions:

- It will simulate the presence of the tag if you try to launch the editor on a website where you haven’t implemented the tag yet. You will notice that the URL won’t contain the usual URL parameter: “?abtasty_editor=testID”.

If you are trying to launch the editor from the AB Tasty dashboard, expect a slight delay and a reload of your website since our tool starts by trying to launch the editor via the tag before by-passing it through the extension.

- It will allow you to inject the script into the webpage.

You can create a campaign directly from your website instead of going into our interface.

- It will display information such as running campaigns and active campaigns on the current URL and allow you to request the update of your AB Tasty script. It will also display the presence of the AB Tasty tag and the time of the last update in the footer.

- Finally, it will allow you to force the reset of JS behaviors. You might be using JS libraries that rewrite basic JS methods that can conflict with our editor. Checking this box will help you override these libraries and fix potential issues.

AB Tasty Object

The script will generate a JS Object that can be read and utilized for various purposes. This Object is named “ABTasty” and contains information about account configuration, campaign results and external information collected by our various web services.

Content Delivery Network (CDN)

General

To ensure optimal response times and performance, all of our customers’ scripts and all of the changes to be made are stored on a multi-CDN infrastructure featuring Smart Routing.

The traffic is routed to the dedicated geographic area and to the fastest/nearest server. We operate with two separate networks: CloudFront and CloudFlare as a potential backup. Our CDN mesh represents a robust, high-availability infrastructure at every strategic node off the planet. Having multiple providers also helps us manage the dramatic yet possible scenario of one CDN going down.

Download Time

Measures made by an external audit show a load time of around 70 ms for the first download, then less than 10 ms thanks to the script’s caching mechanisms.

Availability Rate

All of the technologies and procedures have allowed us to reach a > 99.99% availability rate since their implementation (indicator measured by an external audit).

Monitoring

We constantly monitor our script delivery on various points of the globe and with a “user-like” methodology to gather relevant and accurate measures of the actual performance for each customer.

“Panic Button”

In case of emergencies, we provide you with a “panic button” that acts like a kill switch. After pressing this button and within a few seconds, your script will be completely emptied. To revert the process, simply manually force the update of your script, which will compile a new version of your script, going back to its previous state. In the event of a suspected or actual security issue, you should press this Panic Button immediately to mitigate any damages. 

Handling security breach risks

To prevent any risk of rogue attacks in attempts to purposely modify your script to inject malicious JS code, several measures have been put into place to make sure that each script hosted in our CDN has been generated by a trusted source and frequent checks are automatically carried out. 

All of our CDN third-party we are working with provide us with a set of security certificates that are validated before being put into production. 

When a new script is compiled in the AB Tasty back-office, in the event of new modifications or the passing of its expiration date, a lambda runs and notifies the CDN of this new version.

The CDN can only download the original script from the unique trusted source, our storage server, and the transaction can only occur once an exchange of private keys has been validated. 

Also, the cache invalidation procedure doesn’t allow a script to remain hosted for too long before being erased by a fresher one.

We also have several probes alerting us in case of intrusion. In this scenario, we have the option to automatically kill every hosted script in order to prevent any damage to our customers’ websites.

Cookies & localStorage

Cookies

AB Tasty is creating several 1st party cookies on your visitor’s browser and for your domain:

Name	Information	Time To Live
Mandatory
ABTasty	Campaigns information (AB Tasty Visitor ID, campaigns ID, variations ID, timestamps)	13 months
ABTastySession	Contains unique session ID	1 session
Optional
ABTastyNPS	NPS ID. Not created if no NPS	1 session
	Third-party cookie created on .abtasty.com if Cross-Domain Tracking is configured.	?

Note: if long-term tracking cookies are an issue, you can use localStorage instead of a 13-month cookie. This is available via a parameter in your AB Tasty account.

However, be aware that localStorage doesn’t share between sub-domains. This means that a visitor coming to a specific subdomain won’t be recognized as a unique visitor on another sub-domain, even if the main domain is the same.

We do not create nor support  cookie-based features, such as Cross-Domain Tracking.

In addition to cookies, we also store various information in localStorage and sessionStorage.

localStorage

To keep track of your  visitor activity, we store the following information:

• Viewed URL + occurrence + timestamp
• Custom Variable / Ecommerce Variable + value + timestamp
• Action Tracking + value + timestamp
• Transaction (full content) + timestamp
  
  

sessionStorage

We store the full formatted answer of dcinfos.abtasty.com (web service). It contains geolocation (maximum at city level) and other technical information about the browser.

Single Page Application / Web Apps

We run on a native Vanilla JS framework. 

Starting with version 2.3, our framework is compatible with many modern JS frameworks, including React, AngularJS, Vue, Meteor and Ember. The framework is unique for all environments and doesn’t require any additional implementation.

All variations created in our visual editor using one of the WYSIWYG features will generate an ES5 compatible script that will be executed on the client side. With the “Variation JavaScript'' feature, the user can inject their own JavaScript code, however, the code won’t be transcompiled into another language. For example, an ES7 script might not work on older browsers. It is thus your responsibility to manage the compatibility of their code with their own environment when adding custom JavaScript.

The generated modifications are stored in a JS object that will be read and executed once the script is triggered on the client side.

When a modification targets an existing HTML element, the original isn’t modified. It is cloned, and this clone is modified then displayed by AB Tasty. Each time the URL changes, the framework reloads its targeting and checks whether its modifications still need to be applied. If this isn’t the case, it performs a rollback, and the original content is displayed.

For simple CSS add-ons, we inject a custom CSS at the top of the webpage, using the “!important” tag.

In addition to this, our framework creates a Mutation Observer on the whole DOM. Each time a relevant DOM modification is detected, the framework quickly re-applies its changes. A relevant DOM modification is a change in an element regarding its style or structure.

We use the window.requestAnimationFrame() feature in the browser in order to interleave our modifications between two paintings. With a high refresh rate of 60 times per second, the changes are generated before the human eye can see it, thus avoiding any flickering effect.

Data collection on front-end

Once the AB Tasty tag is implemented on your website, it will start collecting information about your visitors.

We have around 150x250 dimensions and metrics that are collected automatically.

These dimensions and metrics include:

• Technical details on the user (device info, browser, HTTP headers, etc.)
• Geolocation (collected from the AB Tasty sessionStorage, maximum city level)
• Viewed URL
• Click positions for the heatmap
• Seen tests and variations
• Timestamp
• Custom variables, transaction variables and trackings

The data collection service is referred to as “ariane.abtasty.com” in the network tab of your browser.

Additional web services

AB Tasty only requires one additional web service labelled as dcinfos.abtasty.com.

It is an asynchronous call designed to get Geolocation and Weather (via the IP address) of the current visitor. The answer will be stored in the session storage.

The answer will also generate a sessionStorage entry to store the information throughout the Session.

Note: Although we are using the IP address to achieve geolocation, it is not sent to our AB Tasty datastore. The information remains in the SessionStorage and is permanently deleted once the visitor session ends.

The reason why is it an asynchronous call is to avoid performance issue. However, a campaign targeted on the first page and with a dcinfos criteria might generate a slight flickering effect.

Visual Editor

General

We provide a visual editor which enables you to make modifications on your website. You can either use our WYSIWYG features to edit Text, Style and Layout without any technical knowledge, or you can manually inject CSS, JavaScript and access the most advanced settings.

This editor will inject your website in an iframe and will be displayed over the main frame.

In case the iframe mode fails, the editor will try to launch itself in cURL mode.

Note: To make the editor work, you need to make sure you are allowing *.abtasty.com to load your website in an iframe.

If the AB Tasty tag isn't implemented in the webpage, you can still launch the editor if you are using the AB Tasty Chrome extension. You can know wether the editor has been launched through the script or the extension by looking at the URL. If the AB Tasty parameter ("?abtasty_editor=id") is present, it means that the tag launched it.

Apply source code

By default, the visual editor will capture an instant and fresh copy of your DOM to give you a template to manipulate.

If you need to load dynamic content (cart page with products for example) you will need to copy and paste the whole DOM through the dedicated option before loading the editor.

Generating modifications

When using the visual editor, your modifications will generate a script that will be executed by your visitors’ browser. This script will be read and executed by the Modifications Engine: an embedded and advanced tool that will apply (or remove) your modifications depending on the state of the webpage and your targeting, regardless of the JavaScript framework you are using.

You can inject your custom JavaScript by selecting the “Variation JavaScript” in the variation settings.

You can also click on an element directly and select the “Element JavaScript” option: this will create a jQuery selector for this element.

Note: you need to have jQuery on your website or use AB Tasty’s own jQuery to use jQuery selector.

The “Add CSS” feature will allow you to inject a new style as a new Style Sheet.

Account JavaScript

As described in the previous section, you can inject JavaScript within the Variation perimeter. However, you can also run a custom script for the entire experiment. This can be useful to add custom tracking or inject any kind of script that will be used in each variation, including the original.

Simply click on the “Account JavaScript” option in the option bar on the right and write or copy and paste your script.

Lastly, you can run a custom script at the Account level. This is helpful to add global tracking, inject Programmatic Tags or Transaction Tags or to create any kind of segmentation that needs to run throughout all of your experiments.

In your AB Tasty Account Settings, go to Account JavaScript. The selected JavaScript will be executed on each page your AB Tasty tag is implemented on and as soon as there is at least one running campaign.

Troubleshooting

AB Tasty will run on your website, which means that you might experience specific issues if you have restrictive security policies.

iframes restrictions

AB Tasty requires putting your website in an iframe for the editor to run. You might have blocked this possibility for security purposes.

You need to whitelist *.abtasty.com in your iframe security policy to be able to launch the editor.

Content Security Policies (CSP)

If you’re using a bottom-up approach for your Content Security Policies (CSP) rules, you might see that both the AB Tasty script and the AB Tasty editor are blocked on your website.

Script

Since our script is a third-party script that is going to execute scripts labelled as “unsafe”, you need to open the following CSP rules:

script-src 'self' 'unsafe-eval' *.abtasty.com*

Visual editor

Our visual editor uses several tools and technologies in order to work and display all its features. Thankfully, the editor will only be accessed once you’ve logged into AB Tasty. Moreover, it will only launch with a specific URL parameter: “?abtasty_editor=testID”.

Therefore, you need to open the following CSP rules:

Content-Security-Policy=
default-src 'none'
    frame-src 'self'
    script-src 'self' 'unsafe-eval' 'unsafe-inline' blob: *.abtasty.com *.googleapis.com
    connect-src 'self' *.abtasty.com
    img-src 'self' blob: data: *.abtasty.com *.amazonaws.com *.cloudfront.net
    style-src 'self' 'unsafe-inline' *.gstatic.com  *.abtasty.com *.googleapis.com
    font-src 'self' blob: data: *.googleapis.com *.gstatic.com  *.abtasty.com"

• frame-src is used to put your website in an iframe
• script-src: ‘unsafe-inline’ is used to execute inline script within the editor
• img-src: amazonaws and cloudfront host some of our images
• style-src: Google is used for some styles
• font-src: Google is used for most fonts
• connect-src is used to send the tracking data to our infrastructure

Using AB Tasty

Workflow and user rights

We have 4 levels of rights in the solution:

• Administrator: all rights
• User: all rights but Settings/User Rights 
• Creator: can only create a campaign
• Viewer: can only access the tool in read-only mode

The customer has full control on who accesses what. With the Administrator rights, one user can grant and remove access to a specific AB Tasty account.

The highest level of rights can only be the one approving any changes or new campaigns before sending them to production with a simple yet efficient workflow.

That way, you can control who is allowed to push modifications into production.

Switching between different environments

With AB Tasty, you can have as many environments as you need. Each environment has its own tag ID.

You can separate different brands or countries or have several accounts for staging and production. It also helps you build your workflow since each account has its own user rights, meaning that you can have full control over user access for each of your environments.

The most common organization among our customers is the following:

One account per brand/country: each brand/country has its own team, and one user oversees the conversion strategy for its perimeter.

Each account has its equivalent for staging to safely test and run campaigns in real conditions.

One (or several) administrators in the HQ has/have access to all accounts and manage(s) the users.

Sometimes, the IT department is the only user to have the rights to launch a campaign into production to keep track of what is being pushed on their websites.

How to check the good behavior of a campaign

There are several ways of checking the proper operation of a campaign before launching it into production:

Use your preprod environment

If you have a staging environment that is strictly identical to your production environment, then you can easily and safely test your campaigns on this secure website. 

Once your campaigns have been tested, you can easily duplicate them in your AB Tasty production Account.

Note: Make sure to match your new targeting criteria, especially URL targeting before launching the campaign.

Preview Mode

In the editor and for each variation, you can access the Preview Mode directly from the variation option. It will display a popin with a unique URL you can use to view the variation on any device and browser as well as a QR code allowing you to quickly generate a preview on any mobile device.

QA Assistant

The QA Assistant is an application (based on an iframe) that enables you to QA your campaign without having to open your browser console. It displays the campaigns that are live on the active page, those that are active on the website (other than the page you are viewing) as well as information related to the events configured in the campaign.

IP Targeting

Similar to the Preprod Mode, this is however a manual targeting you need to apply. Targeting your campaign by IP is an easy way to allow your whole office to check the campaign and approve multiple devices and parameters.

Additional configuration

How to avoid using cookies

If you can’t use cookies on your website, you can set AB Tasty to use localStorage instead. Simply use the relevant option in the AB Tasty Account Settings.

How to configure specific tracking consent

If you need to wait for a specific tracking consent (cookie consent), you can restrict the cookie deposit to an action or a specific cookie.

Troubleshooting

Flickering

What is the flickering effect?

The flickering effect is a well-known UX syndrome that can be a consequence on an AB Test or a Customization.

Depending on several factors, a website can render its original version and then apply the variation long enough afterwards to be noticed by the visitor. This flipping is the flickering effect.

Causes

The flickering effect can be generated on 3 points:

• CDN response time
• Timing of CDN call
• Execution

We are taking care of the first and the third causes. First, by using a top-rated CDN infrastructure and then by optimizing our framework everyday.

The timing of CDN call is directly related to the implementation method, and this is something we cannot control.

As a customer, you are required to implement the AB Tasty tag following our best practices to avoid experiencing the flickering effect. The lower the tag is in the DOM, the longer it will take to execute.