Cart drawer or cart page: the test nobody runs properly

There are two genuinely different jobs a cart can be doing, and stores that pick the wrong pattern have usually not asked which one applies to them.

In the first, the cart is a confirmation step. The customer has decided, there are one or two line items, there is nothing to adjust, and the only useful thing the page can do is get out of the way. A drawer is the better answer here, and it is better for a reason that has nothing to do with conversion rate: it keeps the customer in place. They can carry on browsing without a navigation, and the context they were building does not reset.

In the second, the cart is a working surface. Someone is ordering fourteen lines at varying quantities, or configuring a bundle, or adding a gift message, or checking whether the order clears a delivery threshold, or — on a trade account — assembling something they will come back to tomorrow. All of that wants room, and a 400-pixel panel sliding over the page is a worse place to do it. Give it a page.

Plenty of stores are both, depending on the customer. That is fine, and it is an argument for a drawer that has a clearly signposted route to a full cart page, rather than a drawer that replaces it. The pattern that fails is the drawer with no cart page at all on a store where a third of orders have ten lines in them.

This is the part that makes the existing evidence close to useless, including the evidence you might gather yourself next month.

A cart page is a page view. A drawer is not. So when a store switches from one to the other, the funnel it has been reporting on changes shape: the step called "cart" stops being a page and becomes an interaction, and "cart to checkout conversion" is now a ratio with a different denominator. It nearly always goes up, because the cart views that used to be in the denominator — including all the accidental ones, the back-button returns, the people who clicked the cart icon to check a price — have gone.

That is where the received wisdom about drawers comes from. Somebody switched, the cart-step conversion rate jumped, and it got written up. The same store’s orders per session may not have moved at all.

So compare at the top: checkout starts per session and orders per session, measured over the same weekday mix and the same traffic sources. Those are the two numbers whose definitions survive the change. Add-to-cart rate is also comparable and worth watching, because a drawer changes what happens *after* the add — which is the one place a drawer can genuinely help or hurt.

The second measurement problem is subtler. A drawer usually changes the add-to-cart interaction itself: the button goes from a form submit that navigates, to a fetch that opens a panel. That is a different piece of feedback, with different latency and a different failure mode, and if your drawer takes 800ms to open on a mid-range phone on 4G then you have not tested drawer versus page — you have tested fast feedback versus slow feedback, and lost.

The effect of a cart pattern on orders per session is small. Whatever it is on your store, it is smaller than the effect of your product page, your delivery proposition or your price.

Small effects need large samples, and the relationship is unkind: the sample size required scales with roughly the inverse square of the effect you want to detect. Halve the minimum detectable effect and you need four times the traffic. That is why so many of these tests get called after ten days on a result that would not survive another ten — the test was never powered to see what it claimed to have found.

Before running it, work out the minimum detectable effect your traffic supports over a period you are willing to wait. If that number comes back larger than the effect you believe a cart pattern has, the test cannot answer the question, and running it anyway produces a decision dressed as evidence. Spend the traffic on something with a bigger effect, and decide the cart on the design reasoning above.

We are aware this is an unusual thing for an agency to say about a test it could bill for. It is still the right advice. The stores where we have found real money in the cart found it in the details — a delivery threshold that was invisible, a discount field that failed silently, a quantity control that did not work on a phone — not in the container.

The mechanism behind a modern Shopify drawer is the Cart AJAX API, and a few documented details decide whether the implementation is solid or subtly broken.

Section rendering is the useful part. The add, change, clear and update endpoints accept a sections parameter — a list of theme sections to render — and return their HTML in the response, keyed by section ID. That is how a drawer updates its line items, its footer and the cart-count bubble in one round trip. The documented ceiling is five sections per request; a failed render comes back as null, so handle that rather than assuming HTML; and sections_url must begin with /. Rendering happens after the cart change completes, so the markup you get back reflects the new state.

Two footguns are worth naming. First, the documentation states that update.js does not validate quantity on variants already in the cart — so a quantity stepper wired straight to it can put more units in the cart than exist, and the customer discovers it at checkout. Validate, or use change.js with the line key. Second, line item keys are not stable: they change as the characteristics of the line item change, and the docs recommend using keys rather than variant IDs when the same variant can appear more than once with different properties, discounts or selling plans. A drawer that tracks lines by variant ID will eventually edit the wrong one.

And keep the route to a full cart page. Not a small text link under the total — a real, obvious one. It costs nothing and it is the difference between a drawer and a dead end.

• Shopify conversion rate optimization
• The product page audit: twenty things worth checking
• Shopify UX and checkout audit