Choosing a check

Which check should I use?

Four kinds of impact check, one question: is the change already live for everyone?

In Needlr: New check, step 1
0:00 / 1:05

Four kinds of impact check tell you if the needle moved. Picking the right one comes down to a single question: has everyone already got it?

Needlr has four kinds of impact check. One question picks the right one: is the change already live for everyone?

Think of a new cookie recipe

You baked a new kind of cookie for your class. How do you find out if it's better?

Before you hand them out: give half the class the old cookie and half the new one, by coin flip. Count who asks for seconds. That's a split test. It's the fair way, because both halves ate on the same day.

Already handed them out to everyone: compare this week with last week. Maybe more kids asked for seconds. But maybe it was just a hungrier week. That's before vs after: a good hint, not proof.

You just want to know if kids even tried the new flavor: count how many did, and check it against your goal. That's adoption.

Split test
Not live yet. Proof.
Before vs after
Live for everyone. Likely.
Adoption
Live. Is it used?
Split test (developer)
Not live yet. In code.
The four cards in step 1 of a new impact check.

Decide in one question

  1. 1Is the change live for everyone yet? If not, use a split test. It's the only kind that gives proof.
  2. 2Can you change it on the page yourself (words, buttons, colors, hiding or moving something)? Pick Split test. You change your page in the visual editor. Or send visitors to another page instead.
  3. 3Does it need code (new logic, a new checkout, a whole new flow)? Pick Split test (developer). Your developer adds one line of code that Needlr shows.
  4. 4Already live for everyone, and you want to know if a KPI moved? Pick Before vs after.
  5. 5Already live, and you want to know if people use the new thing? Pick Adoption.

Split test

Part of your visitors see your change, the rest see your site as it is, at the same time. Needlr compares the two groups. Because a coin flip decided who saw what, a difference is caused by your change (more).

Both split tests work the same way. The only difference is how the new version gets to visitors: you change the page in Needlr, or your developer puts it in the code.

Before vs after

For a change already released to everyone. You give the Release date. Needlr compares up to 4 weeks before that date with up to 4 weeks after it (more).

The answer is “likely, not proof”: other things happen in the same weeks, like a sale, a holiday or a new ad. Needlr warns you when the KPI was already rising or falling before the release.

It needs numbers from before the release. Either a KPI Needlr has been counting since before then, or Google Analytics. The release date can also be in the future: Needlr then collects the “before” until that day.

Adoption

For a new feature that's live for everyone. You set a Target: what share of active people should use it, and within how many days. For example 20% within 30 days. Needlr tells you if you reached it (more).

“Active people” are everyone who visits your site, unless you change it. You can limit them to people who did up to 3 things, like “logged in”.

Common mistakes

  • Shipping to everyone first, then asking. You lose the chance of proof. If you can wait, run a split test first.
  • Treating before vs after as proof. It's a strong hint. A big sale in the same month can fake a win.
  • Using adoption to judge if a feature made money. Adoption tells you if people use it, not if it moved your KPI.
TipReady to set one up? The new check in 3 steps walks through every option.

What the video says

Four kinds of impact check tell you if the needle moved. Picking the right one comes down to a single question: has everyone already got it?

If not, run a split test. Part of your visitors get the change, the rest don't, at the same time. That gives you proof, not a hunch.

Changing words, buttons or layout? Use Split test and edit your live page visually. Changing logic, a checkout or a whole flow? Use the developer version: one line of code.

Already released to everyone? Use before versus after. Needlr compares four weeks before the release date with four weeks after. Likely, not proof, because other things change too.

Shipped a feature and want to know if people use it? Use adoption. Set a target, say 20% of active people within 30 days, and Needlr tells you if you hit it.

So, one question decides it. Not live yet: split test, for proof. Live for everyone: before versus after for a KPI, adoption for usage. When you can, test before you ship.