Case study
Mobile pricing table case study: a slider that raised mobile revenue per visitor 36%
This mobile pricing table case study comes from a supplement store that sells a single product in several packages. On mobile, the packages were stacked one below the other, so comparing them meant a lot of scrolling. Turning the table into a slider raised the mobile rate of order completion 43.9% and revenue per visitor 36%, at a 98% confidence level.
Mobile pricing table case study at a glance
| Client | An eCommerce store in the supplement niche selling a single product (not named in the original case study) |
|---|---|
| Vertical | eCommerce |
| Page tested | The package table on the mobile product page |
| Change tested | A stacked table of packages turned into a swipeable slider |
| Test | A/B test on mobile; test length not published |
| Metrics | Rate of order completion, revenue per visitor and each funnel step |
| Rate of order completion | +43.9% |
|---|---|
| Revenue per visitor | +36% |
| Funnel steps | Increases at every step |
Source: the original Convertica case study. The test length is not published, so these figures carry no timeframe.
What was wrong with the mobile pricing table?
The store's mobile pricing table stacked every package one below the other. Each package was a tall card with its name, an image, a list of benefits, the price and a button, so seeing all of the options, and comparing them, meant a lot of scrolling. By the time a shopper reached the last package, the first was far off the screen.
For a store that sells one product in several packages, this table is where the buying decision happens. If comparing the packages is hard work, some shoppers put the decision off.
What was the hypothesis?
The hypothesis was that turning the mobile pricing table into a slider would make it easier and faster for shoppers to see the different packages on mobile, and that an easier comparison would lead more mobile visitors to complete an order. The change was made for mobile only, where the stacked layout caused the scrolling.
What changed in the mobile pricing table?
The variation replaced the stacked cards with a slider showing one package at a time. Arrows on each side and a row of dots below told shoppers there were more packages to see, and a swipe moved between them without leaving that part of the page.
The mockups show two further differences in the slider card: the price and button sit above the list of benefits instead of below it, and the card carries a small label tab. The original write-up describes the change as the move to a slider, so the test cannot separate the effect of these details from the slider itself.
How was the slider tested?
The slider was A/B tested on mobile against the original stacked table. The team measured the rate of order completion and revenue per visitor, and also recorded performance at each step of the funnel: visitors moving on to the checkout page and visitors completing their purchase. The original case study does not state how long the test ran or how many visitors took part.
| Metric | Change vs the stacked table | Confidence reported |
|---|---|---|
| Rate of order completion | +43.9% | 98% |
| Revenue per visitor | +36% | 98% (mobile results) |
| Visitors proceeding to checkout | Increased (figure not published) | Not stated |
| Visitors completing a purchase | Increased (figure not published) | Not stated |
What were the results?
On mobile, the slider raised the rate of order completion by 43.9%, and this translated into a 36% increase in revenue per visitor. The mobile results reached statistical significance at a 98% confidence level, and the funnel data agreed with them: the share of mobile visitors moving forward rose at every step, from the checkout page to the completed purchase.
The original case study reports these figures without a test length or a visitor count, so read them as one well-supported test on one store rather than a figure to expect elsewhere.
Why did revenue per visitor rise less than orders?
Revenue per visitor is the conversion rate multiplied by the average revenue per order. Order completion rose 43.9% and revenue per visitor 36%, so the average order in the variation was a little smaller (1.36 divided by 1.439 is about 0.95). One possibility is that, with one package in view at a time, a few more shoppers chose a smaller package. The original case study does not report which packages sold, so this is a question to check in your own data, not a finding.
Why did the slider work on mobile?
The slider most likely worked because it shortened the page and kept the comparison in one place. Shoppers could see each package, its price and its button without scrolling a long way down, and swiping back and forth is quicker than scrolling up and down to compare. Moving the price and button above the benefits may also have helped, since the decision point came sooner.
How to design a mobile pricing table that converts
If your product page offers packages, bundles or plans, look at the table on a phone first. Make every option reachable without a long scroll, show the price and the button early, and test the new layout on mobile only, measuring orders and revenue per visitor rather than swipes.
- Scroll your own table on a phone. If seeing every option takes several screens, comparing them is harder than it needs to be.
- Keep the options in one place. A slider or a compact layout lets shoppers compare without losing their place.
- Show that more options exist. Arrows, dots or a partly visible next card tell shoppers to swipe.
- Put the price and button near the top of each option. Shoppers should not have to read every benefit to find out how to buy.
- Mark the option you recommend. A label on one package helps shoppers decide faster.
- Watch order value as well as orders. A layout that shows one option at a time can change which package people pick.
- Test on mobile only. The problem here was specific to mobile, and so was the fix.
The A/B test sample size calculator shows how much mobile traffic a test needs, and the statistical significance calculator checks the result. For other mobile-only wins, read the sticky CTA case study; for a test on how shoppers choose between product options, read the variant selector case study; and for another supplement store, read the JustThrive case study.
Can AI shopping agents read a pricing slider?
They can if every package is in the page's HTML as text. A slider that loads packages only when a shopper swipes, or that shows prices only inside images, can leave an AI agent with one option instead of three. Keep every package name, quantity and price in the HTML, even when only one is visible on screen. Agent readiness is one of the eight checks in Convertica's free CRO audit.
Mobile pricing table case study FAQ
What did the mobile pricing table case study test?
It tested the package table on a supplement store's mobile product page. The original stacked each package one below the other, which meant a lot of scrolling to see every option. The variation turned the table into a slider, so shoppers could swipe between packages in one place. It was tested on mobile against the original.
How much did the slider increase revenue per visitor on mobile?
Revenue per visitor on mobile rose 36%, and the mobile rate of order completion rose 43.9%, at a 98% confidence level. The share of mobile visitors moving to checkout and completing a purchase also rose at every step. The original case study does not state how long the test ran.
Is a slider better than a stacked pricing table on mobile?
It was in this test, for a store with a small number of packages of one product. A slider keeps every package in the same place on the screen, so shoppers compare by swiping instead of scrolling. It is not a rule: with many options, or options that need side by side comparison, a slider can hide choices. Test it on your own page.
Why did revenue per visitor rise less than the order completion rate?
Revenue per visitor is the conversion rate multiplied by the average revenue per order. Order completion rose 43.9% and revenue per visitor 36%, which implies the average order in the variation was a little smaller. The original case study does not report order value or which packages were bought, so the reason is unknown.
How long did the mobile pricing table test run?
The original case study does not state the test length. It reports a 98% confidence level for the mobile results. Because the duration is not published, this page shows the figures without a timeframe and treats them as one test on one store.
How should I design a pricing table for mobile?
Keep every package easy to reach without long scrolling, show the price and the buy button near the top of each package, mark the option you recommend, and give a clear signal that more packages exist, such as arrows and dots on a slider. Then test it against your current table, on mobile only.
Can Convertica run this kind of test on my store?
Convertica starts with the free CRO audit, an app that checks your page for people and for AI agents while you watch. After it, CRO advisory, led personally by founder Kurt Philip with Convertica's CRO team, then gives you ongoing direction on what to fix and what to test while your team builds the changes. Or, with full implementation, Convertica's team builds the fixes from your audit. Both are priced after your audit.