Skip to main content
menu_icon.png

Everything you need to switch from Optimizely Classic to X in one place: See the Optimizely X Web Transition Guide.

x
Optimizely Knowledge Base

Optimizely X Full Stack Overview

RELEVANT PRODUCTS:
  • Optimizely X Full Stack

THIS ARTICLE WILL HELP YOU:
  • Understand the different features of Optimizely X Full Stack
  • Find documentation for Optimizely's SDKs

Optimizely X Full Stack applies the experiment everywhere approach to software product development.

Product teams can use Full Stack to iterate through experimentation, reduce the risk of negatively impacting the customer experience, and measure the impact of product changes on areas like: search results relevance, sorting algorithms, redesigns, page load speed, pricing and packaging, activation and retention across the customer lifecycle, recommended content, new feature rollouts, database migrations, ratings systems, and more.

Full Stack allows product teams to:

  • Demonstrate impact: Full Stack provides key metrics for measuring and reporting on each feature’s impact.

  • Reduce risk: An iterative approach to product development helps ensure that launches and rollouts don’t have unintended consequences.

  • Improve efficiency: Full Stack’s data and reporting capabilities provide product managers with the information they need to make better decisions in less time.

  • Iterate faster: Full Stack helps reduce time-to-market by gathering data on smaller features and reducing risk in launches.

SDK

If you have used Optimizely for web experimentation, you are probably used to creating and managing your experiments from completely within Optimizely’s Visual Editor. While you will still have to use the Optimizely interface to create your Full Stack projects, most of the actual work in creating experiments in Full Stack occurs in the SDK. In fact, SDK-based projects do not involve the Visual Editor at all.

Currently, Optimizely supports several SDKs available for running experiments in different applications:

For more detailed information on working with SDKs, check out these articles in our Knowledge Base and our Developer Docs:

The datafile

The datafile is a JSON file that represents your Optimizely SDK project. It contains all the instructions needed to activate experiments and track events in your code without requiring any blocking network requests. In most cases, you will not need need to interact directly with the datafile yourself; instead, that’s done through the SDK.

For more detailed information on the datafile and how it works, see these articles in our Developer Docs and Knowledge Base:

Webhooks

A webhook is an HTTP callback that notifies your server application when your Optimizely datafile is updated. It is designed to alert you every time your datafile changes, so you can be sure your server application has the most up-to-date version.

With webhooks, security is provided through the use of a secret token to verify that requests originate with Optimizely.

For more detailed information on webhooks, see these articles in our Developer Docs and Knowledge Base:

Forced bucketing

Forced bucketing is a process similar to whitelisting, but easier to use. Instead of having to specify whitelist rules in Optimizely's UI, forced bucketing allows developers to specify variation assignments in-line.

Forced variations supersede all other bucketing rules. This means that a forced variation will take precedence over whitelisted variations, variations saved in the User Profile Service (if one exists), and the normal variation assignment algorithm. Once set, a forced variation is temporarily persisted in local storage; activate and track will respect a forced variation for the duration of a user's session.

For more information on forced bucketing, see this article in our Developer Docs:

Per Theodore Roddy: This content is hidden until feature flags and rollouts are available. We may add it back into the article, but it should not be displayed for now.

-Hillary Fraley, 1-26-18

Feature flags and rollouts

A feature flag is a rule to enable, disable, hide, or roll out a product feature at runtime. They allow developers to configure the behavior of a product on the fly, without deploying any new code. This enables a company to enable a new feature for a small group of their users and hide it for everyone else.

Once you’ve created a feature flag, you can then create a feature rollout by gradually changing the percentage of users who will have access to that feature. It’s a useful way to ramp up access to any feature or experience in a controlled manner, so that you can monitor key engineering metrics (like performance or bugs) or key performance indicators of the user experience impact.