Press "Enter" to skip to content

Online Controlled Experiments
Platform-as-a-Service

Variant is a ground-breaking instrumentation-first platform for creation and management of A/B tests and feature flags at scale. Variant is the only experimentation solution that enables complete decoupling of experience implementation from its instrumentation as an experiment or a feature flag. The implementation of new application code paths will always be the application programmer’s job. But the job of instrumenting these code paths as experiments or feature flags should not be.

Any competent entineer can instrument a handful of experiments or feature flags without the help of a generalized experimentation solution,—just like any competent engineer can save a handful of bytes to disk without the help of a generalized data management solution. But if you need more than a handful of co-existent interdependent experiments in a highly concurrent envieonment, Variant is for you. We make it a simple matter of a few lines of code to instrument a code path as an A/B experiments or a feature flags regardless of whether it’s your first or 1000th concurrent experiment.

Quick Example

Here’s a quick hypothetical example of a simple A/B test. Variant lets you create detailed descriptions of a set of interdependent experiments in a YAML document like this one:

name: example
description: 'Basic one-experiment variation schema'
states:
  - name: MyState
variations:
  - name: MyExperiment
    experiences:
      - name: existing
        isControl: true
      - name: treatment
    onStates:
      - state: MyState

You may have noticed that we don’t use the terms test, experiment or feature flag. Rather, we say code variation to refer to them collectively.

In your JVM application, create a Variant client. You only need one per your application. Then connect to the above variation schema on the server. When user navigates to the state of interest MyState (may be an HTML page, or a React view, or an IVR menu), target current session for that state and obtain the state request object, which contains the experience targeting information you need to decide on the code path.

// Create Variant client.
VariantClient client = VariantClient.build(
   builder -> builder.withSessionIdTracker(ServletSessionIdTracker.class) 
)
// Connect to the Example schema on the server
Connection connection = client.connectTo("http://myhost:5377/example");
// Create Variant session
Session session = connection.getOrCreateSession(myParameters);
// The schema we're connected to
Schema schema = session.getSchema();
// The variable state, e.g. an HTML page, we want to target the session for.
State state = schema.getState("MySate").get();
// Target the session for the state.
StateRequest request = session.targetForState(state);
// Find out what experience in the A/B test we got.
request.getLiveExperience("MyExperiment").ifExistsOrElse(
  liveExp -> switch (liveExperience) {
    case "existing" -> // The control code path
    case "treatment" -> // The treatment code path
    default -> {
      log.error("Didn't expect live experience " + liveExp.getName();
      request.fail();
    }
  },
  () -> {
    log.error("MyExperiment is not instrumented on state " + state.getName);
    request.fail();
  }
)

A real life schema document will be much more complex and contain hundreds or even thousands of inter-dependent code variations. Once a schema document is deployed to Variant server, it can handle all the onerous complexities of guiding a host application through all these concurrent experiments, unlike other experimentation products that leave the instrumentation out of their scope.

Run the Demo (Java)