The availability of features may depend on your plan type. Contact your Customer Success Manager if you have any questions.

Dev guideRecipesAPI Reference
Dev guideAPI ReferenceUser GuideLegal TermsGitHubDev CommunityOptimizely AcademySubmit a ticketLog In
Dev guide

Edge Mode flag variable configuration

Explains the configuration settings of the cdnVariationSettings for the Optimizely Edge Agent.

👍

Beta

Optimizely Edge Agent is in beta. Apply on the Optimizely beta signup page or contact your Customer Success Manager.

The cdnVariationSettings is a powerful and essential Feature Experimentation flag variable that lets you fine-tune the behavior of Optimizely Edge Agent when operating in Edge Mode. This configuration object is designed to handle GET requests, permitting granular control over content fetching, caching, and delivery on a per-variation basis.

By using the cdnVariationSettings, you can optimize your edge-based experimentation and personalization efforts, ensuring that the right content is delivered to the right users at the right time. This level of control is particularly beneficial for managing complex A/B tests, where each variation may have unique requirements for content sourcing, caching, and delivery.

Key benefits of cdnVariationSettings

  • Granular control – The cdnVariationSettings lets you precisely configure content handling for each variation within an experiment. This granularity ensures that each user receives the intended experience, maintaining the integrity of the A/B test results.
  • Improved performance – By specifying caching behavior and content sources, the cdnVariationSettings can significantly enhance the performance of edge-based experiments. Caching content at the edge reduces the need for repeated origin fetches, resulting in faster delivery and improved user experience.
  • Flexibility and scalability – The cdnVariationSettings enables you to adapt your experimentation strategies on the fly without needing worker redeployment. This flexibility lets you do rapid iteration and optimization based on real-time insights, ensuring that experiments can scale seamlessly as traffic and complexity grow.
  • Simplified management – With the cdnVariationSettings, managing edge-based experiments becomes more streamlined. You can control content handling, caching, and delivery directly through the configuration object, reducing the need for custom coding or complex setups.

Understand the cdnVariationSettings properties

The cdnVariationSettings is a JSON object that consists of several properties, each serving a specific purpose in controlling the behavior of Optimizely Edge Agent for GET requests.

cdnExperimentURL

The cdnExperimentURL property specifies the URL pattern that the edge worker should match against incoming GET requests to determine if they are part of a specific experiment. When a request URL matches the cdnExperimentURL, the edge worker triggers the decision-making process to determine which variation of content should be delivered to the user.

Example use case

If an experiment is designed to test different hero banner images on a website's homepage, the cdnExperimentURL could be set to https://www.example.com/home. Any GET request matching this URL is subjected to the experiment's decision-making process.

cdnResponseURL

The cdnResponseURL property specifies the URL from which the variant content should be fetched. When a request matches an experiment based on the cdnExperimentURL, the edge worker uses the cdnResponseURL to retrieve the appropriate variation content to be returned to the user.

One of the key benefits of this approach is that the visitor from the client browser will continue to see the URL for the original content they wanted to receive in the browser. However, behind the scenes in the CDN, the content corresponding to the defined responseURL is fetched and returned to the browser. This content is then displayed to the user under the original requested URL.

This technique effectively hides or abstracts the fact that the content being shown corresponds to a different URL. From the user's perspective, they are viewing the content under the original URL they requested, while in reality, the content is being served from a different URL defined by the responseURL.

This capability is particularly useful for testing complete page redesigns or conducting experiments where entire web pages are created for A/B tests. By utilizing the responseURL, you can create separate page variations and serve them to different user segments without modifying the original URL.

Moreover, this approach eliminates the need for redirect tests, resulting in improved performance and reduced latency. Instead of redirecting the user to a different URL, the content is seamlessly fetched from the defined responseURL and displayed under the original URL, providing a smooth and efficient user experience.

Example use case

In the hero banner experiment, the cdnResponseURL could be:

  • Variation A – https://www.example.com/home/heroExperiment_variationA.html
  • Variation B – https://www.example.com/home/heroExperiment_variationB.html.

The edge worker will fetch the corresponding banner HTML file based on the assigned variation and display it to the user under the original requested URL. The visitor continues to see the original URL in their browser, while the content served to them comes from the defined responseURL.

cacheKey

The cacheKey property determines how the response content is cached at the edge. If set to "VARIATION_KEY", the edge worker constructs a unique cache key by combining the experiment's flag key, variation key, and cdnExperimentURL. This ensures that each variation's content is cached separately, permitting for efficient retrieval on subsequent requests.

Example use case

For the hero banner experiment, setting cacheKey to "VARIATION_KEY" will result in cache keys like https://www.example.com/home/heroExperiment_variationA.html and https://www.example.com/home/heroExperiment_variationB.html, ensuring that each variation's banner is cached independently.

forwardRequestToOrigin

The forwardRequestToOrigin property is a Boolean that controls whether the request, along with its decision data (such as headers or cookies), should be forwarded to the origin server. When set to true, the edge worker acts as a smart proxy, making decisions at the edge and then passing the request and decision information to the origin for further processing.

Example use case

In an experiment that tests personalized product recommendations, the edge worker can make the decision based on user attributes and then forward the request to the origin, including the decided variation in the headers. The origin server can then generate personalized recommendations based on the provided variation.

cacheRequestToOrigin

The cacheRequestToOrigin property is a Boolean that determines whether the content fetched from the origin should be cached at the edge for future requests. When set to true, the edge worker will cache the origin's response, reducing the need for repeated origin fetches for subsequent requests that qualify for the same experiment and variation.

Example use case

For a content-heavy experiment, such as testing different article layouts, enabling cacheRequestToOrigin ensures that the article content is cached at the edge after the first request. Subsequent users who qualify for the same variation will receive the cached content, improving performance and reducing load on the origin server.

cacheTTL

The cacheTTL property specifies the Time-to-Live (TTL) value, in seconds, for the cached content. This determines how long the content remains valid in the edge cache before being considered stale and requiring a fresh fetch from the origin.

Example use case

For a rapidly changing experiment, such as testing different promotional offers, setting a shorter cacheTTL ensures that users receive the most up-to-date content. Conversely, for experiments with static content, a longer cacheTTL can be used to maximize caching benefits.

isControlVariation

The isControlVariation property is a Boolean that indicates whether the current variation settings represent the control group in an A/B test. This is crucial for distinguishing the baseline variation from the treatment variations and accurately measuring the impact of the experiment.

Example use case

In the hero banner experiment, the variation with the existing banner design would be marked as the control variation (isControlVariation: "true"). In contrast, the new banner designs would be the treatment variations (isControlVariation: "false"). This distinction lets you properly analyze and compare the variations' performance against the control.

By configuring these properties in the cdnVariationSettings, you can precisely control how Optimizely Edge Agent handles GET requests for each variation within an experiment. This level of control empowers businesses to create highly targeted, performant, and scalable edge-based experiments that deliver personalized experiences to users while optimizing resource utilization and minimizing operational complexity.