# How to improve ecommerce conversion rate without fooling yourself

> By Lawrence Dauchy, Founder, DFYe. Published 2026-07-02. 10 min read. Guides.
> Source: https://dfye.com/blog/how-to-improve-ecommerce-conversion-rate/
> Language: en

The hard part is not finding changes to make. It is knowing which of them did anything, at a volume where most differences are noise.

**TL;DR.** Improving ecommerce conversion rate is mostly removing uncertainty before checkout: the delivery date, the total cost including shipping, the returns window, and whether the size is in stock. Baymard's aggregate of dozens of studies puts average cart abandonment near 70%, and most of the reasons are information the shopper could not find. The measurement is harder than the change: at a typical rate, telling a 10% improvement from noise takes tens of thousands of sessions per variant.

To improve an ecommerce conversion rate you mostly remove uncertainty before checkout,
and then you avoid fooling yourself about whether it worked, which is the harder of the
two.
[Baymard's aggregate of dozens of studies](https://baymard.com/lists/cart-abandonment-rate)
puts average cart abandonment near **70%**, and most of the stated reasons are
information a shopper could not find: what the total cost would be, when it would
arrive, whether it could be sent back. None of that needs a redesign. All of it needs
somebody to decide what the answer is and put it where the question is asked.

The second half is where most of the wasted effort goes. At the traffic a normal shop
has, most differences you can see are noise, most comparisons are structured so that
noise wins, and the number that results is acted on anyway because it came from a
dashboard.

## What actually moves the number?

Answers, placed where the doubt happens. Every item below is the same move: take a
question the shopper is silently asking and answer it before they have to look.

| Change | What uncertainty it removes | Where to put it |
|---|---|---|
| Delivery date, not "3 to 5 days" | When will this actually arrive | Product page, above the button |
| Total cost with shipping | Am I about to be surprised at checkout | Product page and cart, not step three |
| Returns window in one sentence | What happens if it is wrong | Product page, near the price |
| Stock for the size they picked | Can I even buy this one | On the variant selector |
| Sizing or compatibility guidance | Will this fit or work with mine | Product page, not a linked PDF |

Row two is the one most shops get wrong, and it is the single most cited reason for
abandonment across those studies. A shipping cost that appears at step three of
checkout does not fail because it is high. It fails because it arrives after somebody
committed, and that reads as a trick whether or not it was meant as one.

Row one is worth more than it looks. A date is a different promise from a range, and a
date that turns out to be right is the cheapest trust you will ever buy.

## Where do carts actually get abandoned?

At the point where a question goes unanswered, which is usually earlier than the
checkout analytics suggest.

Checkout abandonment gets the attention because it is measurable: a funnel report will
show you exactly which step lost people. But a large share of the loss happens before
the cart, on a product page where somebody could not work out whether the thing was
right for them and left without generating an event worth naming.

The practical way to find those is not a dashboard. It is your own support inbox. Every
pre-purchase question somebody took the trouble to email you represents a much larger
number of people who had the same question and simply left. Read a month of them and
group them. The top three are your product page's missing sections, and writing those
is a better use of a week than any test you could run.

Speed belongs here too, but narrowly. A slow
[largest contentful paint](https://web.dev/articles/lcp) or a sluggish
[interaction to next paint](https://web.dev/articles/inp) costs you people who never
saw the page properly, and
[lazy loading](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading)
images below the fold is close to free. Past that, speed work has diminishing returns
against answering the question.

## What should you check on a phone?

Everything, and on mobile data rather than office wifi, because most of your sessions
are there and almost all of your design decisions were made on a large screen plugged
into power.

Buy something from your own shop, on your own phone, with one thumb. That single
exercise finds more than a month of analytics, and the things it finds are embarrassing
rather than subtle.

Four specifics are worth checking deliberately.

**The keyboard that appears.** A card number field should bring up digits and a postcode
field should not bring up a full alphabet keyboard on a numeric postcode. Input types
cost nothing and are frequently left at the default, and every wrong keyboard is a
small tax paid by everybody.

**Autofill.** Correct autocomplete attributes let a browser fill an entire address in
one tap. Without them your customer is typing a street name with their thumbs, which is
where a surprising share of checkouts quietly end.

**Labels that survive typing.** A placeholder used as a label disappears the moment
somebody starts typing, so anybody interrupted has to delete the field to remember what
it wanted. [WCAG asks for labels or instructions](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html)
for exactly this reason, and the accessible version is also the one that converts.

**The bottom hundred pixels.** On a phone that strip is contested by the cookie banner,
the chat launcher, the sticky add-to-cart bar and sometimes a promotional ribbon. Each
was added by somebody solving one problem. Together they cover the button. Nobody owns
this stacking and it is worth one person checking it after every release.

None of the four is a redesign. All four are an afternoon, and unlike most conversion
work they do not need a test to justify them: a customer who cannot type their address
is not a hypothesis.

## Why do most conversion experiments prove nothing?

Because the difference being measured is smaller than the noise, and because most
comparisons are before-and-after rather than side-by-side.

| What you measured | What it might also be | How to rule it out |
|---|---|---|
| A lift the week you changed the button | Payday, a campaign, the weather | Run both versions at once, not in sequence |
| A drop after a redesign | A seasonal dip you see every year | Compare against the same weeks last year |
| A winner after four days | Random variation that has not settled | Fix the sample size before you start |
| A big lift on a small segment | The segment you happened to look at | Decide the segment before looking |

The third row is the most common way a test lies. Watching a result accumulate and
stopping when it looks good is not a test; it is a search for a moment when the noise
points your way, and at low volumes that moment always arrives.

Decide three things in writing before you launch anything: what change you are making,
what number you expect to move, and how many sessions you will collect before you look.
A sample-size calculator will tell you the third, and at typical ecommerce rates the
answer is tens of thousands of sessions per variant for a change worth detecting. If
that is more traffic than you have, you have learned something useful: this change is
not testable at your size, so make it because you believe it is right for the shopper,
and stop pretending the number will tell you.

## How does answering questions before checkout fit in?

Directly, and it is the most underrated conversion work available to a small shop.

A shopper with an unanswered question converts worse than one without. That is the
whole mechanism, and it does not care how the answer is delivered. Putting the answer
on the product page is better than making somebody ask for it, because it reaches the
people who would never have asked, and they are the majority.

Which leaves the questions too specific to anticipate: does this work with my model,
will it fit through a door this wide, is the fabric heavy enough for a Scottish
November. Those are the ones worth answering interactively, and they are where a chat
window earns its place. Ours is on [the demo](/demo/), and what it does with a question
it cannot support is on [the features page](/features/).

Two cautions. A window that opens by itself over the thing somebody was reading costs
you more than it collects. And an answer given confidently and wrongly at the moment of
purchase is worse than no answer, because it converts somebody into a return and a
complaint rather than a customer. That is why refusal behaviour is a conversion
question and not only a quality one, as covered in
[what an AI chatbot for a website actually is](/blog/ai-chatbot-website/).

## When should you not run an experiment?

Three situations, and in all three the honest move is to change the thing and skip the
measurement.

When the change is obviously right, do it. A missing returns policy, a shipping cost
hidden until checkout, a product page with no delivery date: these do not need
validation, they need writing. Testing whether customers prefer to know the price is
not a use of a fortnight.

When you do not have the traffic, accept it. A shop doing a few hundred sessions a week
cannot detect anything smaller than an enormous effect, and running a test anyway
produces a number with the appearance of evidence, which is worse than no number
because people act on it.

And when the change is about trust rather than mechanics, do not let a short-term
number decide. Urgency timers, fake stock counters and pressure tactics frequently win
a two-week test and lose the customer who noticed. The test measures this fortnight's
orders. It does not measure whether anybody comes back.

Set against that, the ordinary work holds up well. Answer the four questions, put the
answers where they are asked, and keep reading your own support inbox. The related
engineering habit of measuring before optimising is in
[why we dropped GSAP](/blog/we-dropped-gsap/).

## Quick answers

### How do I improve my ecommerce conversion rate?

Remove the uncertainty that stops somebody buying, in the order they meet it: the total
cost including shipping, when it will arrive, whether it can be returned and how, and
whether the size they want is actually in stock. Those four cover most abandonment.
Everything else, including button colours and urgency banners, is downstream of a
shopper who already knows what they are buying.

### What is a good ecommerce conversion rate?

The honest answer is that a benchmark is close to useless for deciding anything, because
the range within a single category is wider than the range between categories. Traffic
source matters more than industry: a rate built on branded search looks nothing like one
built on cold advertising. Compare yourself to yourself last month, on the same traffic
mix, and ignore the league table.

### Why did my conversion rate change after I updated my site?

It might not have. Week-on-week conversion moves for reasons that have nothing to do
with your change: a payday, a campaign, a competitor's promotion, weather. A
before-and-after comparison cannot separate those from your edit. If you need to know,
run the change as a split where both versions are live at once, so the outside world
affects both arms equally.

### How long should I run a conversion test?

Long enough to reach the sample size, which at typical ecommerce rates is tens of
thousands of sessions per variant for a change worth detecting, and never fewer than two
full weeks regardless of traffic. Two weeks is not statistical, it is practical: it
covers both weekends and a full payday cycle, and stopping early because the number
looks good is how most tests produce a result that does not survive.

### Does live chat improve conversion rate?

Answering a pre-purchase question does, and a chat window is one way to deliver it. The
lift comes from the answer, not from the window, which is why publishing the same answer
on the product page usually beats making people ask for it. Chat earns its place for the
questions too specific to anticipate, and loses it the moment it opens by itself over
the thing somebody was reading.

### Should I add urgency timers and stock counters?

Only if they are true. A countdown that resets when you reload, or a stock counter that
says three left on everything, is read as a lie by exactly the shoppers who were closest
to buying. Real scarcity is worth stating plainly and needs no animation. Manufactured
scarcity buys a short-term lift and spends trust you will want later.

## Sources

- [Baymard Institute: cart abandonment rate, aggregated studies](https://baymard.com/lists/cart-abandonment-rate)
- [web.dev: largest contentful paint](https://web.dev/articles/lcp)
- [web.dev: interaction to next paint](https://web.dev/articles/inp)
- [WCAG 2.2: labels or instructions](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html)
- [MDN: lazy loading](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*