Multi-Faceted Decisions

When there is more than one decision to make in your site or app

In the Quick Guide, you saw how to get a simple decision from a Conductrics Agent:

GET http://api.conductrics.com/acme/agent-1/decision

You can use that simple form whenever you only need your agent to make one "decision" -- that is, when you have one set of options, and you want your agent to learn which one works best.

If what you're trying to do is a bit more complex -- when there is more than one set of options that you want it to learn over -- then the calls you make to our service will change slightly, so that we correctly understand the problem you're asking us to solve.

Ways to Work with Multiple Decisions

Let's assume you have a multi-faceted learning problem that you want to throw at our service. You've got a few different options:

Option 1

Use multiple agents

Simply use a new agent code per set of options that you want to learn over (you'll make a separate HTTP request for each).

Internally, each agent is basically doing simple A/B testing for you, favoring the 'winner' most of the time.

We won't learn anything about how the options may affect each other, but it keeps things nice and simple.
Option 2

Use multiple decisions

You can set up a single agent to make multiple decisions at the same time. You give us one list of options for one decision (let's say a list of colors) and another list for some other decision (perhaps a list of sizes).

Whenver you ask us for a decision, we'll pick one option from each list, and send them back to you in one answer.

So, we're basically doing multivariate testing ("MVT") for you, tracking the success of combinations of options rather than each option individually.
Option 3

Use multiple "decision points"

You can set up a single agent to make decisions at different "points" in your application.

For instance, you might have one set of options on a Home page, and another set of options on an About page. Some visitors may arrive at Home first, others may arrive at About first, and still others may only encounter one or the other.

The same basic idea applies to multiple screens or moments in a mobile app.

You can combine Options 2 and 3. You can have multiple decision points, and each can have 1 or several decisions.
Option 1

Using Multiple Agents

This is the simplest way to accomodate a site or app that has more than one set of options for our service to test and learn about.

Consider a scenario where you have a site or app that has:

  • Three 'hero' images to show on on a home page or home screen.

    Let's call these Image 1, Image 2, and Image 3.

  • Two 'stylesheets' that control look and feel in some way.

    For fun, let's call these the "Simple Stylesheet" and the "Fancy Stylesheet".

All you'd do is get two separate decisions from our service, using a different agent code for each.

So, selection of the hero image (select one from a set of three options) would look something like this:

GET http://api.conductrics.com/undefined/hero/decision/3

And the selection of the stylesheet might look like this:

GET http://api.conductrics.com/undefined/style/decision/simple,fancy

Because two agents are being used, our service considers them to be two different optimization 'problems' to solve. There really isn't else to consider specific to the multiple-ness of it all. Just make decisions, send goal events, and look at reports as you would 'normally'.

By setting things up this way, you are basically telling our service that it shouldn't be concerned with any 'interaction effects' between the two problems. This means that it will never attempt to pick up on whether people that get the 'Fancy' stylesheet respond better to Image 2 versus Image 1 and so on. That said, it may be simpler to think about them separately, especially if they roll out to the public at different times.
Option 2

Using Multiple Decisions

When you have more than one decision (again, that's when you have more than one list of options and want one to be picked from each list) that should be made at the same time, then you'll use our service to make both decisions at the same time and get back both 'picks' at the same time.

Rather than making two separate HTTP requests, you'll make one request that looks like this:

GET http://api.conductrics.com/undefined/home-agent/decisions/3/simple,fancy

The reply from our server looks like this (formatted here for clarity):

{
  session: "vKqPrmvMjLllAPBE",
  decisions: {
    decision-1: {
      code: "2"
    },
    decision-2: {
      code: "simple"
    }
  },
  point: "point-1",
  segment: "(none)"
}

As you can see, our reply now contains an object called decisions, which contains values for decision-1 and decision-2, with the selected option for each in a value called code.

Note Please notice that we're now using the plural "decisions" after the agent code in the URL, rather than "decision". This tells our service that our reply should be in the slightly more verbose form that includes multiple decisions. As you can see, this reply also has a few additional pieces of information that may be of interest. See the reference portion of our documentation for details on the other values.

Optionally, you can name the decisions, which makes our reply more self-documenting and its meaning more obvious:

GET http://api.conductrics.com/undefined/home-agent/decisions/hero:3/style:simple,fancy

Now our reply looks like this, with your names used in the decisions part of the reply:

{
  session: "vKqPrmvMjLllAPBE",
  decisions: {
    hero: {
      code: "2"
    },
    style: {
      code: "simple"
    }
  },
  point: "point-1",
  segment: "(none)"
}

This means that you can refer to decisions.style.code in your site or app to include the appropriate stylesheet, for instance.

When you look at reports, you'll find that most of the reporting is now at the combination-of-selections level, rather than at the individual selection level. In other words, rather than learning about the effectiveness of Hero 1 or Stylesheet B on their own, our service is now learning about the effectiveness of using 'Hero 1 and Stylesheet A' as a combination, versus 'Hero 1 and Stylesheet B' and so on. Without having to do much of anything differently, you are now using an agent that does MVT-style testing internally, and learns the value of each combination of options in real time. Pretty cool.

Option 3

Using Multiple Decision Points

You may have a few decisions that you want our service to try out and learn about, but which are at different conceptual 'places' or 'moments' in your site or app.

We call these decision points.

For example

As a simple example (building on the example scenarios for the first two approaches above), perhaps the 'hero' decision (Hero 1 or Hero 2 or Hero 3) happens on your "Home" page, and the stylesheet decision (Stylesheet A or Stylesheet B) is something that you're experimenting with on your "About" page.

So, that would be two decision points (you might call them 'home' and 'about' when talking to our service).

Another example

Or, in a mobile app, you might have one decision to make when a game launches for the first time (on a 'splash' screen), another decision just before play begins, such as how hard the level should be in the trial version of a game, and another decision later, perhaps whether to give the user some hints if they lose the game really fast.

So, that would be three decision points, each for the conceptual 'place' or 'moment' where you want to make a decision. So you might call the points 'splash', 'play-start', and 'play-end'.

What's the Point? :)

So what's the real advantage to using multiple decision points, over just using separate agents as discussed above?

When a goal occurs, our system uses a smart attribution model to map the goal back to the decisions that were made before the goal. In the background, a statistical model ends up being built that takes the structure of the decision points into account. This all happens automatically just by using different decision point codes when you make your decisions.

You can use as many decision points as you like within your site or app.

To use decision points in your agent, just add a URL parameter called point.

So, instead of looking like this:

http://api.conductrics.com/undefined/my-agent/decision/simple,fancy

Your decision call might look like this, to specify that the decision is at a conceptual point you want to call 'about-page':

http://api.conductrics.com/undefined/my-agent/decision/simple,fancy?point=about-page

You can have multiple decisions (made at the same time as discussed in preceding section) at any given decision point:

http://api.conductrics.com/acme/my-agent/decisions/hero:3/style:simple,fancy?point=about-page