Experimentation allows you to serve different website experiences to your clients. Typically, it is used for A/B testing, canary releases, trunk-based development, dark releases, feature releases, and segmented releases.
Sample Use Cases:
Send 5% of your traffic to a new version of your website, while the rest of your clients continue to use the existing version of your website.
Send 20% of your traffic to a different homepage.
Split traffic between three calls to actions to compare effectiveness.
Set up your experiments through the following steps:
Identify the environment (e.g., production) that will be configured.
Define one or more experiment(s) for that environment.
For each experiment, you must define two or more variants. Each variant identifies the percentage of traffic to which a set of actions will be applied.
Apply your experiment(s) to that environment by deploying your changes.
Once you have deployed at least one experiment, then each client will be assigned a random value from 0 - 99 through the x-edg-experiments cookie. This value will persist until the client clears their cookies. This random value is critical for determining the variant(s) that will be assigned to the client. An experiment must contain two or more variants and each variant identifies the set of actions that will be applied to a request.
A client is eligible to participate in an experiment if the request satisfies the experiment’s criteria. Edgecast processes the request with the set of actions associated with each variant assigned to the client.
Edgecast checks an experiment’s criteria after it has processed the request through Rules.
Edgecast adds experimentation metadata to each experiment-eligible request. Specifically, it adds a header to the request sent from Edgecast to the origin and it adds metadata to the response sent from Edgecast to the client. This allows you to use variant information within your application(s).
You may define criteria that identifies the set of traffic to which an experiment will be applied. If you do not define any criteria, then the experiment is applicable to all requests.
For example, you may identify requests by HTTP method, path, or request headers.
Defining how a request will be compared against a value or state. In some cases, this involves selecting a comparison operator and defining the value that will be compared against the request.
A variant identifies the percentage of traffic to which a set of actions (aka features) will be applied. The available actions are categorized as follows:
You may create, enable, disable, and delete experiments. You may also adjust the distribution of traffic between variants.
Key information:
An experiment is read-only once it has been deployed. However, you may enable, disable, or delete it at anytime.
Apply your changes to the current environment by clicking Deploy Changes.
To create an experiment
Load the Experimentation page.
From the Edgecast Console, select the desired private space or organization.
Select the desired property.
From the left-hand pane, select the desired environment from under the Environments section.
From the left-hand pane, select Experimentation.
Click + Add Experiment. A blank experiment configuration will appear.
From the Name option, assign a name to the experiment.
Edgecast populates the x-edg-experiments-info upstream request header with this name.
Optional. Restrict this experiment to a subset of your website traffic by defining one or more criterion.
Click + Add Criteria.
From the Variable option, select the desired variable.
For example, you may identify requests by HTTP method, path, or request headers.
Define how a request will be compared against a value or state. In some cases, this involves selecting a comparison operator and defining the value that will be compared against the request.
Click Add Condition.
Optional. Add another match criterion by repeating steps 4.i - 4.iv. Repeat this step as needed.
Define two or more variants.
From the Name option, assign a name to this variant.
Edgecast populates the x-edg-experiments-info upstream request header with this name.
Set the Percentage option to the percentage of this experiment’s traffic to which this variant will be applied.
The traffic percentage defined for all variants defined within a specific experiment must add up to 100%. For example, if you have 3 variants and you have assigned 33% to 2 of them, then the third variant must be assigned 34% (33% + 33% + 34% = 100).
Define the set of actions that will be applied to traffic assigned to this variant.
This cookie assigns a value from 0 - 99 to a client. Once a client has been assigned a number, it will persist until the client clears their cookies. This ensures a consistent experience across multiple browsing sessions.
The x-edg-experiments-info request header tracks the variants assigned to a client. Edgecast adds this header to requests proxied through our network to the origin or the Edgecast cloud.
Edgecast does not currently add this header to requests processed by Edge Functions. However, we plan on adding this header to requests forwarded to Edge Functions in the future.
It contains the following syntax for each variant that has been assigned to a client:
The server-timing response header tracks the variants assigned to a client. It contains the following syntax for each variant that has been assigned to a client: