Magento conversion rate: find the lost step

One conversion rate cannot say where a shopper gave up. The same low number can come from a product page with no visible size selector, a bag that drops the chosen item, or a shipping estimate that never loads for the shopper's country. Magento stores often add layers that behave differently for each visitor: a page cache, a guest checkout setting, and shipping and tax rules that depend on the address. A delivery method that appears only after a full address can look missing to someone who stopped at the postcode. Each of these lowers the same number, so the rate alone does not point to the fix.

• Compare the share of product views that reach the bag with the share of bags that start checkout in your analytics.
• Open the bag as a guest in a private window and confirm the item, size, price and quantity match the product page.
• On the shipping step, check that delivery methods appear for each country you ship to, not only your own.
• Check the bag and checkout responses for a cache header that reads HIT, which means a stored copy was served.
• Place a test order on a phone up to payment and note any field that stops you or hides an error.

Start at the product page the way a shopper does. They arrive from an ad, read the title and price, pick a size, and press Add to bag. Then they open the bag. A shopper reads the bag as a promise: the item they chose and the price they saw. If the bag shows another price, a missing size or an empty line, most shoppers will not work out which part broke. The next step is checkout, where the form asks for a name, an email address, a delivery address and a delivery method.

Most store owners check this path once, while logged in as an admin or as their own customer. That view skips the cache a shopper sees, the session a new visitor starts with, and the postcode a stranger types. Walk the path again as a guest, in a private window, on a phone. The first screen where the item, price or total changes without a reason is the one to note.

A bag that drops the item, or shows an old price, can come from a cache or a session that does not hold. Open the bag in a private window and add one item. If the item is there, the cart works for a new visitor, and the break is in what returning shoppers see. If the item is missing, look at the response headers of the bag page. A cache header that reads HIT means the shopper got a stored copy, and that copy can be older than the add.

Shipping faults look different. The total changes, or the delivery options disappear, once a shopper types a postcode. That points to shipping rules rather than the bag. Test the same bag with a postcode from each region you ship to. A rule that works for your own address can return no methods for a nearby country, and a shopper there sees a store that does not deliver to them.

A simulated test gives you the step where each visitor stopped, a screenshot of that step, and the script errors and failed requests the browser recorded there. The visitor works in a real browser on your public store, so a broken shipping estimate shows as the stop. A guest in a private window arrives with no login and no saved cart, the state most owners never test from. The run cannot give you your real rate, and it cannot see your analytics, your orders or your shipping settings. Take the step with the largest loss from your analytics, then run the path and watch what a guest meets there.

A store changes after launch. A deploy misses the page cache, a new shipping zone hides the methods for one country, or a discount breaks the bag total. Each change can lower the rate without an alarm. Run the same shopper path after every deploy and every rule change, from a private window, through to the payment step. You see the step that moved before the next campaign sends traffic to it.