---
title: "A Growth Team's Guide to SRM and mSPRT"
description: "The two checks that separate a defensible A/B test result from one that gets challenged in the next engineering review — explained without the statistics degree."
canonical: https://landtest.dev/blog/growth-teams-guide-srm-msprt
last-updated: 2026-10-30
---

# A Growth Team's Guide to SRM and mSPRT

> The two checks that separate a defensible A/B test result from one that gets challenged in the next engineering review — explained without the statistics degree.

SRM (sample ratio mismatch) and mSPRT (mixture sequential probability ratio test) are the two checks that determine whether an A/B test result is trustworthy: SRM verifies the traffic split actually happened the way you intended, and mSPRT lets you check results at any point during the test without inflating your false-positive rate. Skipping either is the most common reason a growth team reports a result that doesn't survive scrutiny.

## Sample ratio mismatch (SRM), plainly

If you set up a 50/50 split, SRM checks whether the actual traffic that arrived was close enough to 50/50 to be explained by chance. If it wasn't — say you got 58/42 — something in your assignment logic is broken: a redirect affecting one variant differently, a caching issue serving one variant to bot traffic disproportionately, or an implementation bug in the split itself. The critical point: when SRM fails, the conversion rate comparison between variants is not trustworthy, regardless of how statistically significant it looks, because the populations being compared aren't the ones you intended to compare. A result from a test with unchecked SRM should be treated as unverified until the cause of the mismatch is found and fixed.

## mSPRT, plainly

A traditional significance test (a z-test) requires you to pre-commit to a sample size and only look once, at the end. In practice, almost nobody does this — teams check daily, and stop as soon as the result crosses a significance threshold. That habit, known as the peeking problem, inflates the real false-positive rate well above the nominal 5%, because checking repeatedly gives the test many chances to look significant by noise alone.

mSPRT is a sequential testing method designed specifically to be checked at any time without that inflation. It doesn't require you to guess a sample size in advance, and a result it calls significant remains valid regardless of how many times you looked along the way. This is what lets a team report "we're confident in this result" honestly at whatever point they actually are confident, instead of either waiting out an artificial fixed sample or fooling themselves by peeking.

## Why both matter together

SRM and mSPRT catch different failure modes. SRM catches a broken experiment setup before you draw any conclusion from it. mSPRT prevents you from fooling yourself about when a real conclusion is warranted, assuming the setup was sound. A tool or process that does one without the other still leaves a real gap — a clean split checked with a fixed-sample test that gets peeked anyway, or a sequential test running on top of a silently broken split.

## What to actually do with this

Before reporting any A/B test result: confirm the traffic split matches what was intended (SRM check), and confirm the significance call came from a method designed to be checked at any time (sequential testing), not a fixed-sample test that got checked daily until it crossed threshold. If your current tooling doesn't surface both of these automatically, that's worth flagging before the next test, not after a result gets challenged.

## FAQ

**What causes sample ratio mismatch?**
Usually a bug in the assignment or routing logic — a redirect, a caching issue, or bot traffic affecting one variant disproportionately. It's a setup problem, not a statistics problem, and needs to be fixed before trusting any result from that test.

**Why is checking a test daily a problem?**
Because a fixed-sample significance test is only valid if you look once, at a pre-committed sample size. Checking repeatedly and stopping at the first significant-looking result (the peeking problem) inflates the real false-positive rate well above 5%.

**Does mSPRT replace the need to check SRM?**
No — they solve different problems. mSPRT makes repeated checking statistically valid; it doesn't verify the underlying traffic split was correct in the first place.

---

Related: [A/B testing for growth teams that need engineering to trust the results](/blog/ab-testing-for-growth-teams) · [A/B testing for technical product managers](/blog/ab-testing-for-product-managers) · [Landtest for A/B testing](/ab-testing)