> ## Documentation Index > Fetch the complete documentation index at: https://docs.abtestly.com/llms.txt > Use this file to discover all available pages before exploring further. # Sample ratio mismatch > What an SRM warning on your experiment results means, what causes it, and what to do. If you've landed here from a warning on your experiment results, this page explains what's happening and what to do about it. ## What it means in plain terms When you set up an A/B test, you tell ABTestly how to split traffic between variants — usually 50/50, sometimes 70/30 or 80/20. **Sample ratio mismatch** means the *actual* split of visitors who entered the test no longer matches what you configured, by more than chance could explain. A normal 50/50 test won't land on exactly 50/50 — random variation means you might see 49.4/50.6 after a few thousand visitors, and that's fine. But if you see, say, 54/46 on a 50/50 test with tens of thousands of visitors, that's not random. Something in the way visitors are being counted, routed, or bucketed is producing a skewed split. ABTestly only fires the warning when the imbalance is *statistically* extreme — well beyond the level where chance is a plausible explanation. ## What you should do with the results **Don't trust the numbers on a test that's showing SRM.** The two variant groups aren't comparable anymore — one group has been filtered or shaped differently than the other, so any difference in conversion rate could be caused by that filtering instead of by the variant. We still show you the conversion-rate table when SRM fires (hiding it would be worse — you'd lose context). But we mark the results as potentially invalid, and the right move is almost always: 1. Find the cause. 2. Fix it. 3. Restart the test from a clean slate. ## Common causes SRM is almost always a bug somewhere in the data pipeline, not a real imbalance in how interesting the variants are. The usual culprits: * **A variant that breaks or crashes on certain pages, browsers, or devices.** Visitors in the broken variant bounce before being recorded, while visitors in the working variant aren't bounced, so the counted-variant ratio drifts. * **Redirects or routing that skip one variant.** A redirect rule, a CDN config, or a single-page-app navigation that doesn't pass through the bucketing step for one of the variants. * **A variant that's much slower than the other.** If one variant adds noticeable load time, more visitors bail mid-load before being recorded — counted exposures skew toward the faster variant. * **Targeting or bucketing setup that changed mid-run.** If you change variant weights, targeting rules, or paused/resumed traffic during a test, the historical split may not match the current expected split. * **Bot or crawler traffic hitting variants unevenly.** Less common, but possible if one variant has a different URL pattern. * **Cache or `localStorage` issues.** A cache hit that serves the wrong variant, or a `localStorage` write that fails on one variant, produces uneven counted exposures. ## How to investigate Work through the list above against your specific test: 1. **Open both variants** in a fresh incognito window and walk through the user flow. Look for JavaScript errors, broken layouts, redirects that drop you out of the test, or unusual load times. 2. **Check your targeting rules** — did anything change after the test started? URL conditions, audience filters, traffic allocation? 3. **Look at the per-variant counts** on the results page. Which variant is over- or under-represented? If one variant has way fewer exposures than expected, that variant is most likely the one with the bug. 4. **Check the variant code** itself — anything that throws an error, blocks the page, or replaces analytics/tracking can cause SRM. 5. **If you can't find the cause**, write us at [support@abtestly.com](mailto:support@abtestly.com) with the experiment URL — we'll help you investigate. ## What to do after you find it Once you've fixed the underlying cause, **restart the test** rather than continuing. The pre-fix data is contaminated by the imbalance — combining it with post-fix data won't give you a clean answer either. A fresh run on clean conditions is the only reliable path to a trustworthy result. You don't need to delete the old data — ABTestly's "Reset data" button on the experiment settings page keeps the experiment configuration but wipes the result counters, so you can restart cleanly without rebuilding the test from scratch. ## Why we surface this at all Most A/B-testing tools quietly publish whatever results come out of their data pipeline, including from tests where the underlying split was broken. We'd rather tell you "this test is showing a sample ratio mismatch — the result may not be trustworthy" than let you ship a change based on an invalid comparison. The warning is a guardrail protecting the validity of decisions you make from these tools — we'd rather be honest about a broken test than show you a confident-looking but misleading number. The bar for firing the warning is set very strictly — far stricter than what would catch normal random variation — so an SRM warning is a real signal worth taking seriously. *** ## Start testing The free tier covers 3,000 monthly tracked users and one active experiment, no credit card. Edge-served snippet, with sample size and confidence intervals shown on every result.