CONVERSION

Test prioritisation scoring

Use when you have a backlog of test ideas and need a defensible running order.

test-prioritisation-scoring.md

Download .md

You are prioritizing a backlog of conversion test ideas. Score consistently and show your reasoning.

BACKLOG (one idea per line, with any supporting evidence): {{BACKLOG}}
PAGE TRAFFIC FOR EACH LOCATION: {{TRAFFIC_BY_PAGE}}
TEAM CAPACITY: {{CAPACITY}}
CURRENT PRIORITY OF THE BUSINESS: {{BUSINESS_PRIORITY}}

Score each idea 1 to 5 on:
- Evidence: how strong is the reason to believe there is a problem here
- Reach: how many users hit this page or step
- Expected effect: how much of the conversion decision this element plausibly influences
- Effort: 5 means very low effort
- Learning value: what we find out even if the result is null

Output a table with those five columns, a total, and a one line justification for the lowest scoring dimension of each idea. Sort by total, highest first.

Then:
- Name the top three and the order to run them, accounting for the fact that tests on the same page cannot run simultaneously without interaction effects. Flag any collisions.
- Name any idea that should not be tested at all because the traffic cannot support it, and say what to do instead.
- Name any idea that should just be shipped without a test because it is an obvious fix.

Constraints: do not score Evidence above 2 for anything supported only by opinion or a competitor doing it. Do not invent traffic figures. No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{BACKLOG}}
{{TRAFFIC_BY_PAGE}}
{{CAPACITY}}
{{BUSINESS_PRIORITY}}

Getting a better result

Feed in the raw backlog including the bad ideas - the scoring is what filters them.
The "just ship it" list is often a quarter of the backlog and needs no test time.
Re-score quarterly; evidence scores change as research lands.

Questions about this prompt

When do I score the backlog rather than pick the obvious next test?

When the backlog is longer than the quarter and the running order is being set by whoever argues hardest. It scores evidence, reach, expected effect, effort and learning value, and caps evidence at two for anything supported only by opinion or by a competitor doing it. That cap does most of the filtering.

What do I need in front of me before running it?

The raw backlog with whatever evidence each idea carries, traffic per page, team capacity and the current business priority. Feed in the weak ideas as well, since the scoring is what filters them and pruning first hides how thin the list really is. It will not invent traffic figures for pages you leave out.

What comes back, and which part is worth acting on?

A scored table sorted by total, the top three in run order with collisions flagged where two tests share a page, ideas the traffic cannot support, and ideas to ship without a test. That last list is often a quarter of the backlog and needs no test time, so read it before the rankings.

What is the mistake that costs me here?

Scoring once and treating the order as settled. Evidence scores move as research lands, so re-score quarterly. The other error is running two tests on the same page because both scored well: the prompt flags the collision, and ignoring it means neither result can be attributed cleanly to either change.