How to use A/B Testing a Branched Cart Flow Against a Single-Track Flow in Klaviyo
A test-design walkthrough for splitting traffic 50/50 between a branched and a single-track Klaviyo cart flow — what to measure, how long to run, and how to read the result.
A/B Testing a Branched Cart Flow Against a Single-Track Flow in Klaviyo
A flow-level Klaviyo experiment that randomises abandoners 50/50 into a branched architecture vs a single-track flow to measure whether the branching is worth the setup and maintenance.
This is a flow-architecture test, not a content test. You split incoming abandoned-cart triggers 50/50 using a Klaviyo conditional split at the top of the flow: half of shoppers experience the branched flow (typically discount-eligible vs full-price paths), and half get a single unified sequence. Both arms run in parallel for two to four weeks, share the same trigger and exit criteria, and are compared on revenue per recipient and contribution margin per recipient.
The question the test resolves is narrow and specific: does the branching produce enough incremental profit to justify the ongoing maintenance cost of running two paths? Anything less and you consolidate.
Most teams build a branched cart flow because it feels obviously right — discount-eligible shoppers need a nudge, full-price shoppers just need a reminder. But the branch adds real cost: two subject-line sets to maintain, two discount-code pools, two sets of edge cases when you change positioning. You need to know the uplift is real before you commit to the maintenance.
This guide walks the full test design end to end: how to split traffic at the trigger, which primary metric to use, how long to run at your abandoner volume, and how to read out when the branched arm wins revenue but loses margin. It assumes you already have a branched flow built and want to validate it against the single-track version you shipped last quarter.
Splitting traffic at the flow trigger
The split has to happen at the flow trigger, not at the individual email send. Splitting at the send only randomises which email creative someone receives — it can't test two different flow structures. A trigger-level split uses a Klaviyo conditional split on a random-number property (or a segment-based 50/50 split) as the very first action in the flow.
Once a profile enters an arm, it stays there for the entire flow duration. That means the branched arm's own internal branching (discount vs full-price paths) happens after the 50/50 test split — the test measures architecture A vs architecture B, and lets each architecture do its job on its half of the traffic.
Exclude repeat buyers from the trigger conditions on both arms. Existing customers behave differently — they open at higher rates and convert without needing incentives — and if they're distributed unevenly across the split (they will be, in small samples) they'll swamp the signal you actually care about.
Don't split at the email send
A send-level A/B test in Klaviyo can only test creative within a single flow. You cannot use it to compare two different flow architectures — the profiles in the branched arm need to experience the branching logic, which is a flow-level structural difference. Use a conditional split at the very first step of a single wrapper flow, or a random-property segment gate on two parallel flows.
Picking the primary metric
Placed-order rate is the intuitive choice, but it's the wrong primary metric for this test. A branched flow that offers discounts to hesitant shoppers will almost always beat single-track on placed-order rate — that's not news, and it doesn't tell you whether the extra orders are actually worth having.
Revenue per recipient is the right primary metric. It combines conversion rate and average order value into a single number that reflects the top-line impact of the architecture. Contribution margin per recipient is the tiebreaker: when the branched arm wins on revenue but the discount arm is doing the heavy lifting, margin per recipient tells you whether the additional revenue survives the discount cost.
How the three metrics can disagree on the same test
The pattern above is common on stores that branch by discount eligibility: orders go up, revenue goes up more modestly because AOV drops in the discount arm, and margin per recipient goes negative because the discount cost exceeds the incremental gross profit. Reading only placed-order rate would ship the wrong flow.
Sample size and runtime
At the flow level, your unit of analysis is a triggered profile, not an email send. To detect a 10% relative lift in revenue per recipient with 80% power at 95% confidence, you typically need 4,000-6,000 profiles per arm — meaning 8,000-12,000 total cart abandoners across the test window. Below that, the test either runs too long to be useful or never reaches significance.
Match your runtime to weekly abandoner volume, and always run in whole weeks to average over day-of-week seasonality. If you're under 500 weekly abandoners, consider a Bayesian readout — you may never hit frequentist significance, and a posterior probability of >90% that branched beats single-track is a defensible ship criterion for a decision this operational.
Runtime to reach ~10% MDE on revenue per recipient, by weekly cart-abandoner volume
| Weekly abandoners | Profiles per arm needed | Expected runtime | Readout approach |
|---|---|---|---|
| Under 500 | ~5,000 | 10-14 weeks | Bayesian (frequentist unreliable) |
| 500-1,500 | ~5,000 | 5-8 weeks | Frequentist, run whole weeks |
| 1,500-4,000 | ~5,000 | 3-4 weeks | Frequentist, standard |
| 4,000-10,000 | ~5,000 | 2 weeks | Frequentist, watch for promo overlap |
| 10,000+ | ~5,000 | 1-2 weeks | Frequentist; segment by discount eligibility |
Avoid running through a major promo window. A Black Friday week inflates the discount arm's performance artificially and contaminates the readout — the branched flow will look like a hero, but only because everyone would have bought anyway. If a promo is unavoidable, either pause the test or exclude promo-window triggers from the analysis.
Reading out and rolling out the winner
Call the test on the pre-declared primary metric — revenue per recipient — with margin per recipient as the tiebreaker. If revenue per recipient is significant and margin per recipient is flat or positive, ship the branched flow. If revenue per recipient wins but margin per recipient is negative by more than 3-5%, you have a discount-dependency problem, not a branching win, and the honest call is to keep single-track and revisit the discount logic separately.
When you roll out the winning architecture, don't re-trigger existing subscribers who are already mid-flow. Set the new flow to trigger only on new abandonment events created after the switchover time, and let in-flight profiles finish the arm they entered. This avoids double-sending and keeps your unsubscribe rate clean during the transition.
One decision the test doesn't answer
Even a clean 8-10% revenue-per-recipient win doesn't automatically justify keeping the branched flow forever. Branched architectures cost time to maintain — creative refreshes, discount-code hygiene, edge-case handling — and that ongoing cost has to be weighed against the annualised incremental profit. Treat 'ship the winner' and 'is the maintenance cost worth it' as two separate decisions.
Frequently asked questions
No. Klaviyo's built-in A/B test operates at the email-send level within a single flow — it randomises subject lines, content, or send times, not flow architecture. To test branched vs single-track you need a conditional split at the very first step of a wrapper flow, or two parallel flows gated by a random-property segment.
A trigger-level split assigns each profile to an arm at the moment they enter the flow, and they experience that entire architecture. A send-level split only randomises which creative version they receive from a single email step. Only trigger-level splits can test structurally different flows.
Placed-order rate ignores AOV, and branched flows that offer discounts almost always inflate order count while lowering AOV. Revenue per recipient captures both effects in a single number, which is what you actually care about when comparing architectures. Placed-order rate is fine as a secondary diagnostic.
Exclude them from the flow trigger on both arms, or at minimum exclude them from the analysis. Repeat buyers convert at very different rates from first-time abandoners, and any imbalance between arms will contaminate the readout. Keeping the denominator to first-time and lapsed buyers gives a cleaner signal.
Two to four weeks is typical for stores with 1,500-4,000 weekly cart abandoners. Below that, plan for 6-12 weeks. Always run in whole weeks to average over day-of-week effects, and avoid running through a major promotional window.
That's a discount-dependency signal, not a branching win. The branched arm's revenue lift is being funded by discount depth rather than by better segmentation. Keep single-track and revisit the discount logic — you can usually claw back most of the placed-order lift with a smaller discount or a tighter eligibility rule.
For a shipping decision at 95% confidence, yes. But if you're under 500 weekly abandoners you may never reach frequentist significance in a reasonable window — a Bayesian readout with a >90% posterior probability that branched beats single-track is a defensible alternative for an operational decision.
Configure the winning flow to trigger only on cart-abandonment events created after the switchover timestamp, and let profiles already in-flight complete their current arm. This avoids double-sending, keeps unsubscribe rates stable, and gives you a clean transition.
Test the structure first. Once you've confirmed the branched architecture is worth having, you can iterate on the branch condition (discount eligibility threshold, cart-value cutoff, product category) as a follow-up test inside the winning arm.
Not cleanly. Any concurrent test that changes creative, send timing, or discount depth inside either arm will contaminate the architecture readout. Freeze the flows for the duration of the test, and queue other experiments to run sequentially once you've called this one.
Test ideas before you ship them
Run unlimited A/B tests, attach hypotheses to outcomes, and build a searchable archive of what works — and what doesn't.