choice

A choice question picks the best option for each case. Like Jev's Choice, it names one option and gives a number for every option. The numbers mean something different. Jev's probabilities split one belief across the options and sum to 1, and its pick is the most probable. Datagoat scores the case once per option: each option's p is the chance of the outcome for cases like this one with that option, so the chances don't sum to 1. The pick is the option most likely to lead to an outcome you want, or least likely to lead to one you avoid.

When to use

Use choice when you control something about the case and want to know which setting works best here: which contract keeps this customer, which team resolves this ticket on first touch, which channel gets this lead to reply. To predict a category you don't control, choice is the wrong type: ask a yesno about each category instead.

choice is the only type that needs outcome_is_desirable. "Best" means nothing without it. Without it, the contract most likely to lead to churn could be named the best contract.

Request

Try each value of a column you control:

"contract": {"type": "choice", "option_column": "contract",
             "options": ["month-to-month", "one_year", "two_year"],
             "outcome_column": "churned", "outcome_is_desirable": false}

Or pick between outcomes, one learned outcome per option:

"reach": {"type": "choice",
          "option_outcomes": {"email": "replied_to_email", "call": "answered_call"},
          "outcome_is_desirable": true}
Field
type "choice"
outcome_is_desirable required
option_column, options, outcome_column the first form: 2 to 255 values of a column in the record
option_outcomes the second form: {option: outcome_column}, 2 to 32 options

Answer

"contract": {
  "type": "choice", "state": "answered",
  "cases": [{
    "entity_id": "acct_0001",
    "choice": "one_year", "most_likely": "month-to-month", "least_likely": "one_year",
    "p": {"month-to-month": 0.701, "one_year": 0.091, "two_year": 0.198},
    "reasons": [
      {"feature_label": "contract",     "value": "one_year", "likelihood_direction": "lower",  "strength": "strong"},
      {"feature_label": "tech_support", "value": "no",       "likelihood_direction": "higher", "strength": "strong"}
    ]
  }]
}
  • choice is the pick: least_likely here, because churn is to be avoided. For a wanted outcome it is most_likely.
  • most_likely and least_likely are always both there, whichever way outcome_is_desirable points.
  • p maps each option to its own chance of the outcome. With option_column, one model scores every option, so the chances are directly comparable. With option_outcomes, each option is its own outcome and its own fit.
  • reasons explain the chosen option's chance.
  • A case bills one decision, however many options it has.
  • A choice answer carries no quality or polarity. Its state is the gate.

When the option makes no difference

If the record shows the option column doesn't change the outcome, the answer is refused with option_not_in_pattern. Datagoat won't present a tie-break as a finding. Ask about another column, or a different outcome.

With option_outcomes, an option whose outcome can't be answered is left out and listed in options_unavailable, with the reason. If none can be answered, the answer is refused with no_option_answerable.

Writing choice questions

  • List every option you could actually use. An option the record never saw has no evidence behind it.
  • Keep choice for things you control. The chances say which cases like this did better with each option. They are associations, not a promise that switching will work. Check with reported outcomes.
  • Read all the chances, not only the pick. A pick at 0.09 against 0.10 is a close call. Your code can weigh the gap against what each option costs.