How it works
One experiment, from the ad click to the last offer
A split-testing app stops counting at the order. An upsell app starts counting there. This runs one experiment across the whole span, so the same visitor carries the same version from the landing page through the checkout and every offer after it.
Landing page
Checkout
After the payment
Split-testing apps count this much
Upsell apps count this much
cbsplit counts all of it, as one experiment
The worked example behind the claim
Version B converts 2.9% worse and earns 7.0% more per visitor, because its buyers took the post-purchase offer at nearly twice the rate. Every figure below comes from 14,200 visitors per version, an average order of $92 USD and a single $50 USD offer.
Split testing
- You edit the real page, not a copy of it. The visual editor opens your live storefront with an editing layer over it. Your theme, your width, your actual page, with everything on it running.
- Nothing is written to your theme. A change is stored as an instruction against an element and applied only for the visitors in that version. Stop the test and every change is gone at once, with no cleanup and no leftover files.
- Three ways to deliver a version. Element changes applied at runtime, an alternate Liquid or JSON template you already built, or headless for pages you host yourself.
- Assignment is sticky, deliberately. A visitor keeps their first version on every return visit. Someone who saw both pages belongs to neither group, so we never move them.
- Buy it now and Shop Pay still attribute. Accelerated checkout builds a checkout straight from the product form and never touches the cart, so the attribution token also rides a hidden field on the form. Without that, your fastest-converting buyers attribute to nothing.
One-click upsells and downsells
- One click, no card re-entry. The offer appears after the card is charged and before the thank-you page. Accepted items are added to the order just placed, so there is no second order to reconcile and no second checkout to lose them in.
- A no costs you nothing. The original order completes exactly as it would have. This is the only point in your funnel where asking has no downside, which is precisely why the aggressive offer belongs here and not in the cart.
- Funnels branch on the answer. Every step splits on accept or decline, so a yes leads to a bigger offer and a no leads to a downsell. You draw the whole chain in the funnel builder and it shows you every path a buyer can take through it.
- A step can sell four different ways. One product. Several products bundled together and taken as one. A choose-one, where the buyer picks a single option. Or a choose-several, where they pick as many as they like. Each item charges its own Shopify price, so a discounted bundle is a bundle product priced in Shopify rather than a discount engine you have to trust.
- Targeting is a hierarchy, not a pile of rules. The first rung with a match wins outright and the rest are never evaluated, so a broad rule can never steal traffic from a specific one. The order is fixed: split test, then product, then collection, then order subtotal, then global.
Deciding who sees which offer
Rules are checked from the most specific to the least, and the first level with a match wins outright.
- Split test, this version
- Split test, whole test
- Product or variant
- Collection
- Order subtotal
- Every order
Testing the funnels themselves
- It costs nothing extra to run. The sample-size rule, the refusal to name a winner early, revenue per visitor, the split between initial and upsell revenue: all of it applies to a funnel test unchanged, because as far as the machinery is concerned it IS a page test. Nothing had to be reimplemented for offers, so nothing about it can be weaker than the page version.
- Nobody else can attach that rigour to an offer test. An upsell app comparing two offers is comparing them with its own counting, inside its own half of the funnel, against a total that stops at the order it started from. Applying real testing discipline to an offer needs one tool that owns both halves.
- Run it backwards and you get a control condition. Bind ONE funnel to the whole test instead, and every buyer meets the same offer whichever page version they saw. A difference between the versions then cannot have been caused by them being shown different upsells. On any store that sells post-purchase, that is what a clean page test looks like.
What the report shows
- Revenue per visitor, per version. With the initial order and the upsell revenue shown apart, so you can see which half of the ladder actually moved rather than inferring it from one merged total.
- Take rate for every step, upsells and downsells counted separately. Per version, against the buyers who actually reached that step. It is the number an upsell operator optimises week to week, and here it sits in the same report as the page test that produced those buyers. No other app can show you both.
- Order value including everything the offers added. Average order value is the whole order as it finally stood, not the part of it that existed before the buyer was asked.
- Refund and chargeback rates, down to the step. A step whose chargeback rate runs well above the funnel average is flagged. Post-purchase regret shows up there first, and it is invisible to anything measuring the order as a single lump.
- Probability of being best, per version. The question people think a p-value answers. 60% is not a winner, it is a coin with a slight lean, and the report says so rather than rounding it up into a recommendation.
If your pages are not on Shopify
- Pages on your own infrastructure. A published API for stores whose landing pages live on their own stack or CMS. Hydrogen, a custom storefront, a marketing page on your own domain. It is documented end to end, and it expects a developer.
- Keep the testing tool you already use. If your site already splits its own traffic, tell us which version it served and we supply the part it cannot see: what that order was actually worth after refunds, shipping, tax and cost of goods. A tool watching your front end only knows that a button was clicked.
The other half of the reading is what this app will not do, which is worth knowing before you install rather than in week three.
What it refuses to do