Use case

A/B and A/B/n testing

Rank options against each other instead of scoring them one at a time.

The problem

Why this is hard today.

A real experiment needs traffic, instrumentation and weeks. Most decisions do not get one, so options get compared by argument. And a live test tells you which option won without ever telling you why.

How userken does it

Four steps.

  1. Pick the audience, and decide whether you care about the whole audience or one segment.
  2. Enter two to six options.
  3. Run an A/B/n test. Every persona sees the options and is sampled several times, so you get a distribution rather than a single opinion.
  4. Read the weighted winner, the per segment winner (they often differ), and the reasons.
run_ab_test

Two to six options, weighted winner, per segment split.

ask_audience

Open ended follow up on the option that lost.

A/B/n template

In-app template with verbatims per option.

Tool names are the MCP tools and in-app templates. The same engines power both.

Illustration

What a run looks like.

Illustrative example, not a result we are reporting

Illustration: a browser picks a default new tab layout

  • Audience: the browsers category, reviews that mention tabs or the home screen.
  • Options: a blank page, a page of shortcuts, and a reading feed.
  • What you would read: the overall ranking, and the fact that a power user segment and a casual segment may want opposite defaults.
Related

Next door to this.

Run a a/b and a/b/n testing on your category.

Accounts are provisioned by hand during early access. Tell us the question and the category and we will set you up.