An A/B testing workflow is the sequence of steps between noticing a problem and trusting the answer.
There are five stages, and each one produces the input for the next. You form a hypothesis from behavioral data. You size the test so it can actually detect the effect you expect. You pre-register the segments you will analyze. You measure the downstream result, not just the click. You write down what you learned so the next hypothesis starts further along. Skip a stage and the test still runs, it just stops meaning anything: an unsized test produces noise, an unregistered segment produces a result you found by looking, and an undocumented outcome gets re-tested by somebody else next quarter.
This guide walks each stage in order, including the arithmetic for sizing, and ends with how the testing tool, the analytics platform, and the warehouse fit together.
The newsletter
Join our KISS newsletter
One short read a week on what actually moves revenue, in a free email. Read by 10,000+ operators and founders.
No spam. Unsubscribe in one click.
The Five Stages of an A/B Testing Workflow
Most teams treat A/B testing as an event: build a variant, ship it, read the number. The workflow framing treats it as a loop with dependencies. Stage 1 decides what is worth testing. Stage 2 decides whether the test is feasible with the traffic you have. Stage 3 decides what counts as a legitimate finding. Stage 4 decides whether the finding is worth shipping. Stage 5 decides what you test next.
The A/B Testing Workflow
Build the Hypothesis
Use funnel drop-off, cohort differences, and path data to name a specific problem, a specific cause, and a predicted outcome.
Size the Test
Calculate the visitors per variation needed for your baseline rate and minimum detectable effect. Decide feasibility before anyone writes code.
Pre-Register Segments
Write down the segments and the primary metric before results exist, so a later split is analysis rather than fishing.
Measure Downstream
Read revenue per visitor, retention by variant, and guardrails, not only the immediate conversion.
Document and Reload
Record hypothesis, result, interpretation, and next question. Wins, losses, and nulls all get written up.
“The goal of A/B testing is not to get more winners. It is to learn faster. A well-designed test that produces a null result teaches you something. A poorly designed test that produces a winner teaches you nothing you can trust.”
- Experimentation mindset
Stage 1: Build the Hypothesis from Behavioral Data
A strong hypothesis is specific, falsifiable, and grounded in something you observed. It names a problem, proposes a cause, and predicts an outcome. Behavioral data supplies all three. Opinion supplies none of them, which is why the green-button test rarely goes anywhere: a colour change cannot fix a value proposition nobody understood.
Find Problems Worth Solving
Start with size of opportunity. Read your conversion funnel for the steps with the steepest drop-off. If two in five people who add to cart never finish checkout, that step is worth a quarter of engineering time. If trial users who skip onboarding in the first three days almost never convert, onboarding is the target. Funnel analysis puts a number on each opportunity so you can rank them instead of debating them.
Then split the number. An overall 40% cart abandonment rate might be 25% on desktop and 65% on mobile, which turns a vague checkout problem into a specific mobile checkout problem. Split by source and organic might convert at several times the rate of paid social, which says the paid audience arrives with different expectations than the page answers. Each split narrows the hypothesis and raises its hit rate.
The Part That Used To Take a Week
The traditional version of this stage is slow for reasons that have nothing to do with thinking. You need an event that was never defined, so you file a ticket. You need a report nobody has built, so you build it, or you ask an analyst who has a queue. KISSmetrics removes both. It auto-configures by scanning your site and autocaptures interactions you never declared, so the behavioral history is already there. Then you ask the AI chat the question in plain language, such as where mobile visitors drop out of checkout compared with desktop, and it builds the metric or report. Because the events came from KISSmetrics in the first place, the chat is resolving your real event and property names instead of guessing at a schema someone pasted in. The result is saved, so you re-run the same definition after the test rather than rebuilding it from memory.
Write It Down in One Sentence
Use the standard structure: we believe that [change] will cause [outcome] for [audience] because [what the data shows]. For example: adding a progress indicator to mobile checkout will reduce abandonment for mobile users, because 45% of mobile abandoners leave at step 2 of 4, which suggests they cannot tell how much is left. That sentence is testable. “Let us try a different checkout layout” is not.
Stage 2: Size the Test Before You Build It
Sample size is not a statistics formality, it is a go or no-go decision. The calculation takes three inputs: the baseline conversion rate of the control, the minimum effect you care about detecting, and the power you want (conventionally 80%, at 95% confidence).
Run that example forward. Roughly 50,000 visitors per variation means about 100,000 in total. If the page sees 5,000 visitors a month, the test needs about 20 months, which means it is not a test, it is a plan to never find out. The correct response is to test a bigger change, move the test to a higher-traffic page, or pick a metric closer to the change. Our sample size calculator guide walks the arithmetic step by step, and statistical significance explained covers what the confidence number actually claims.
How long a test runs at 5,000 visitors a month (3% baseline, 80% power)
Metrics viewThe Errors That Undo the Sizing
Peeking is the common one. Checking daily and stopping at the first significant reading is not a 95% confidence test, it is closer to a coin flip with extra steps, and the problem compounds when you are watching several metrics at once (see multiple comparisons). If you need to watch a test while it runs, use a sequential method, Bayesian or alpha spending, that is built for repeated looks. Otherwise commit to the duration.
Novelty is the other one. People react to a new thing because it is new. Run for at least two full business cycles, typically two weeks, so weekday and weekend behavior are both represented and the novelty has worn off.
| Feature | Good Practice | Common Mistake |
|---|---|---|
| Sample size | Calculated before launch | Run until it looks significant |
| Duration | At least 2 full business cycles | Stopped after first positive signal |
| Peeking | Sequential methods or no peeking | Check daily, stop when significant |
| Segments | Pre-registered before results | Sliced afterwards until a winner appears |
| Multiple metrics | Primary metric plus guardrails | Pick whichever metric won |
| Learning | Documented regardless of outcome | Only winners get shared |
Stage 3: Pre-Register the Behavioral Segments
An average hides variation. A variant that lifts conversion 20% for new visitors and drops it 10% for returning visitors can show a small positive average, and shipping it on that average quietly damages your best audience. Segment-level reading fixes that, but only if you decide the segments before you see the numbers.
Which Segments to Register
A workable default list: visitor type (new against returning), traffic source, device, lifecycle stage (anonymous, free, trial, paying), and engagement level. Write them into the test plan before launch. Pre-registered segments are analysis. Segments found after the fact by slicing until something is significant are a way of guaranteeing a false positive.
Add one more that most test plans still miss: people who arrived from an AI assistant. The LLM Acquisition report measures humans arriving from ChatGPT, Claude, Gemini, and Perplexity as their own source. They usually land with the problem already framed by a conversation you did not see, so they read pages differently from search traffic and often respond differently to the same variant. Background on the distinction is in tracking AI assistant traffic and AI crawlers versus AI referrals.
Or Target the Segment Directly
If the hypothesis is about mobile users, run the test on mobile traffic only. You need less traffic because you are not diluting the effect with people the change cannot affect, the result is cleaner, and you iterate faster. Segment-targeted tests make particular sense when analytics has already shown one segment performing much worse than the rest. Fix it where it hurts, then check whether the fix travels.
Interaction Effects
Mature programs look for interactions: the redesigned product page that works for search arrivals with high intent and fails for casual social arrivals. That finding is not a failed test, it is a personalization rule. Define the groups as Populations so the same behavioral definition drives the analysis and, later, the targeting. Populations update themselves as people qualify, which beats the older approach of exporting a list and re-uploading it every week.
Stage 4: Measure Downstream, Not Just the Click
This is the stage most workflows truncate. The variant produced more signups, so it wins. But conversion rate is a local measure, and changes tend to move value around rather than create it.
Revenue Per Visitor Beats Conversion Rate
A pricing page test can lift conversion from 2.5% to 3.1% while shifting the plan mix from mostly premium to mostly basic. Conversion improved and revenue per visitor fell. Revenue per visitor captures conversion rate and order value in one number, which makes it the better primary metric for anything touching a purchase decision. The Revenue report gives it to you per variant once assignment is recorded as a property.
Retention and Lifetime Value by Variant
Some effects only appear weeks later. A lower-friction signup flow can raise signups and attract people who never intended to stay, so the 30-day conversion looks better while 90-day retention gets worse. Track 7, 30, and 60 day retention per variant with the Cohorts report, plus lifetime value and adoption depth. These take longer to mature, and they are the difference between a lift and a transfer.
Guardrail Metrics
Guardrails stop you winning the primary metric while losing something you care about more. Define them before launch. For a test aimed at trial signups, reasonable guardrails are trial-to-paid conversion, support tickets per trial user, and page load time. A primary win that trips a guardrail goes back for investigation rather than straight to ship.
What Metrics Should You Track Beyond Conversion Rate in A/B Tests?
Revenue per visitor, which captures conversion and order value together. Retention at 7, 30, and 60 days by variant, which catches changes that attract people who leave. Customer lifetime value by variant, which is the long-run version of the same question. And guardrails such as support volume and error rates. The most expensive testing mistake is shipping a conversion lift that erodes revenue or retention two months later, when nobody is looking at that test anymore.
Stage 5: Document and Feed the Next Hypothesis
Every test should end in a written record, whatever the outcome. Wins validate a belief. Losses kill one. Nulls tell you the problem is somewhere else. All three make the next hypothesis better, and none of them survive in anyone’s head past the next sprint.
What the Record Contains
The hypothesis and the data behind it. The design: what changed, who saw it, how long it ran, and the sample size target. The results: primary metric, pre-registered segment breakdowns, guardrails, downstream metrics. The interpretation: what you believe this means. The implication: what it says to test next. Keep these somewhere searchable and read the archive before designing anything in the same area. Saving the underlying reports in KISSmetrics keeps the analysis re-runnable, so a claim from March can be re-checked in August against the same definition rather than a reconstruction of it.
Building on Results
A win should spawn a test that pushes the same idea further. If the progress indicator cut abandonment, try adding estimated time, or showing stages instead of steps. A loss should spawn an adjacent hypothesis. If simplifying the pricing page did nothing, the problem may not be complexity but credibility, so test proof: named customers, case studies, a comparison. Each result removes part of the possibility space.
Measure the Team on Learning, Not Wins
Scoring an experimentation team on win rate pushes them toward safe cosmetic tests that nudge a number and teach nothing, and away from the ambitious redesign that would have settled a real question. Count validated or invalidated hypotheses per quarter instead. Share losses and nulls in the same review as the wins, with the same amount of discussion. That is what makes people willing to test the thing that might not work.
Where the Workflow Breaks
The failure modes map onto the stages, which is useful because it tells you where to look when a testing program stops producing anything.
Stage 1 Failure: Testing Opinions
Someone prefers a shorter headline. A competitor has a different layout. These ideas are not wrong, they are unsupported, and they have no mechanism behind them, so a null result teaches you nothing because there was no belief to disprove. If the hypothesis sentence cannot name what the data showed, it is not ready.
Stage 2 Failure: Underpowered Tests
A test that shows a 12% lift after 500 conversions may show 2%, or a decline, after 5,000. Early readings are mostly noise, so stopping early means shipping noise. The underpowered test is worse than no test because it costs the same engineering time and produces a false belief the team then builds on.
Stage 4 Failure: The Wrong Metric
A change that raises trial signups while attracting people who churn faster destroys value while reporting a win. A checkout tweak that lifts completion and raises returns nets to zero. If the primary metric does not capture the whole effect of the change, the conclusion is wrong no matter how clean the statistics were.
Wiring the Workflow
Three systems carry the workflow. The experimentation platform assigns people to variants and renders them. The analytics platform supplies the behavioral data for stage 1 and the downstream measurement for stage 4. The warehouse holds the history that makes stage 5 searchable.
Testing Tool to Analytics
The connection that matters most: when someone is assigned to a variant, record that assignment as a person property in KISSmetrics. Every other report can then be read per variant. The A/B Test report gives you the head-to-head result, and because assignment is just a property, you can also ask what variant B users did differently: which pages they visited, which features they touched, whether they came back. That turns a win or lose readout into an explanation.
Analytics Back to Hypotheses
The return path is the one teams forget. Funnels, Cohorts, Path, Product Usage, and Activity are where the next hypothesis comes from. Product Usage shows which features are underused. Cohorts show when people leave. Path shows the routes nobody designed. Ask the AI chat for any of these in plain language and the report is built and saved, which is the practical difference between a program that generates hypotheses continuously and one that generates them in a workshop twice a year.
The Experimentation Data Layer
Store assignments, primary results, guardrails, downstream metrics, and written interpretation in a structured place, usually the warehouse. That structure enables the meta-analysis: across every pricing test you have run, which kinds of change produced the largest lifts? Which segments respond to experimentation at all? Those answers are worth more than any single test and only exist if the records are consistent.
The stages are not expensive, they are just easy to skip when the pressure is to ship. Start with KISSmetrics for free at 100,000 events a month, or see pricing for Growth at $99 for 500,000 events and Silver at $299 for 2 million.
One analytics idea a week
Short, specific, written by the team building the product. No digest, no roundup.
Continue Reading
Optimizing Onboarding Workflows With Real-Time Analytics Feedback Loops
Most onboarding flows are designed once and forgotten. The best ones adapt in real time based on what each user actually does. Here is how to build analytics-driven onboarding workflows.
Read articleMulti-Touch Attribution Setup Across Your Stack
Multi-touch attribution setup is five jobs done in order: capture every touch, resolve them to one person, join revenue, apply a credit model, then reconcile against what the ad platforms claim.
Read articleA/B Testing Statistical Significance: When to Call a Winner
Calling a test winner too early is the most common A/B testing mistake. This guide explains statistical significance in plain language and shows you exactly when it is safe to make a decision.
Read article