PDP optimization: How to find and fix where shoppers stall

A product detail page (PDP) has one job: get a shopper who's interested in a product to add it to the cart. When a page doesn't do that, the reason is usually specific and findable. Maybe the size chart doesn't say whether the shoe runs narrow, or the page shows "ships in 3–5 days" when the shopper wants to know if it'll arrive by Saturday. Maybe the return policy sits three clicks away from the price. PDP optimization is the work of finding those gaps, fixing the ones that cost you the most, and checking that the fix worked.

This guide covers the product pages on your own store, where you control the copy, the layout, and what happens when a shopper has a question.

The process below runs in the order you'd work through it: check who's arriving, find where they stall, fix the biggest gaps, answer the questions the page can't, decide how you'll measure, and test one change at a time.

Check who's landing on the page first

A PDP can't convert a shopper who arrived wanting something else, so rule out a traffic problem before you rewrite copy or reshoot photos. Split the page's traffic by source and by device, and compare engagement for each slice.

You're looking for a mismatch between the promise that brought someone in and what the page shows. A paid search keyword might be sending people who want a cheaper model. A social ad might feature a color you've since sold out of, or an email might promise a discount the page doesn't mention. In each case, the page looks broken in your reports when the real fix belongs in the ad, the keyword list, or the email.

If one source engages far worse than the others on the same page, start there. If mobile engages far worse than desktop, look at the mobile layout before the copy. If every source and device looks equally weak, the problem is the page, and the rest of this guide applies.

Find where shoppers stall

Start with the numbers to find which pages lose shoppers, then look closer at those pages to see where and why it happens.

Compare views, carts, and purchases for each product

You don't need a new tool to find your weakest product pages. GA4's Ecommerce purchases report lists items viewed, items added to cart, and items purchased for every product you sell, side by side.

Sort by items viewed, then look for products with lots of views and few add-to-cart events. Those pages get attention and lose it, which makes them your best candidates. A product with a healthy add-to-cart rate but few purchases has a different problem, and it often sits after the PDP, in the cart or at checkout when shipping costs appear.

Low-traffic products need a little care. One slow week can make a page that sells five units a month look like it collapsed. Group those products by category or price band and read the group's numbers instead, so you're reacting to a pattern.

Walk the page in the order a shopper does

Once you know which pages underperform, find where on the page shoppers give up. Most stalls happen at a handful of points, and each one leaves its own signal in your data:

• The first screen. If shoppers leave without scrolling or clicking, the first screen didn't confirm they're in the right place. Watch for a low engagement rate and short engagement time on the page.

• The variant selector. Shoppers pick a size or color, change it a few times, and leave. If you track variant changes as an event, compare those events with adds to cart. If you don't track them yet, set up a custom event, because this stall is invisible without one.

• Delivery and returns details. Use scroll depth (GA4's built-in scroll event only fires at 90%, so you'll need custom scroll tracking or a heatmap tool like Microsoft Clarity) and session recordings to see whether shoppers reach these sections, linger, open a shipping link, and then exit.

• The price. Recordings that show a shopper scrolling to the price and leaving right after point to a value problem: the page hasn't yet made the case for what it costs.

Read what shoppers ask before they buy

Analytics show where shoppers stall, and their questions tell you why. Every pre-purchase conversation in chat, email, or messaging is a shopper telling you exactly what the page didn't answer.

Pull a month of those conversations and tag each one with two labels: the product it's about and the topic of the question. Most questions fall into a few topics, like fit, materials, delivery, compatibility, and returns. Then rank the topics for each PDP. The top questions on a page are the gaps in its copy.

Here's a hypothetical example. Say your best-selling waterproof hiking boot drew 60 pre-purchase conversations last month, and tagging them produced this:

• Fit (26 conversations). "Do these run narrow?" and "I wear a 9 in my trail runners, what size here?" The size chart lists lengths and says nothing about width.

• Waterproofing (14). "Are these fully waterproof or just water-resistant?" The answer is on the page, in a materials tab most shoppers never open.

• Delivery (12). "Will these get here before my trip on Saturday?" The page shows a shipping speed but no arrival date.

• Returns (8). "Can I return them if I've worn them on a short walk?" The returns policy doesn't say what counts as worn.

Each topic points to a specific fix, and the counts tell you which one to make first.

Fix the biggest gaps first

Once you know where shoppers stall and why, decide which fixes come first and where each one goes on the page.

Rank fixes by traffic and evidence

By now you'll have more possible fixes than time. Score each one on two things: how many views the page gets, and how strong the evidence is. A stall you can see in the data that also shows up as a repeated question is strong evidence. One or the other is moderate. A hunch with neither is weak, and it goes to the bottom of the list however good the idea sounds.

High-traffic pages with strong evidence go first. Keep the scoring this simple until you have a reason to make it more complicated.

Put the answer where the question comes up

A fix only works if the shopper finds it at the moment they have the question. Put sizing guidance next to the size selector, an arrival date near the add-to-cart button, and a one-line returns summary near the price. In the hiking boot example, a width note beside the size options and an arrival date by the button would cover 38 of the 60 questions without the shopper scrolling or opening a tab.

Answer the questions the page can't

Some questions don't belong in the copy, because the answer depends on who's asking. Will this boot fit like the pair they bought from you last year? Can they exchange an earlier order for this one? Static copy can't answer those for every shopper, so the page needs a way to answer them live.

It's tempting to save live help for shoppers who look most likely to buy, like those with a full cart or a long session. The trouble is that a shopper with one item and a sizing question leaves just as fast as one with five items if nobody answers. Answering pre-purchase questions pays off: Rothy's reports that more than 20% of customers who connect with a team member go on to buy.

Customer experience AI makes that practical at full volume. Gladly Agentic Commerce handles the sizing and fit questions that hold up a purchase, and it can step in with help when a shopper lingers on the page or seems about to leave. Shoppers who are ready to buy can check out inside the conversation without being sent to another page.

What the AI needs to answer well

An AI can only answer what it can see. It needs your product catalog for specs and availability, and your policies for shipping, returns, and exchanges. It also needs the shopper's order history, because that's where questions like "will this fit like my last pair" and "can I exchange my earlier order" get answered. An AI that sees only the catalog can recommend a product, but it can't confirm an exchange on a past order. Gladly recommends from each customer's full history, including their sizes and everything they've bought before, so the same AI that suggests a size can see the last pair they bought.

Send the answers back to the page

The questions your AI fields every day are your next round of copy fixes. Tag them the same way you tagged last month's conversations, by product and topic, and rank them again. When a topic drops off a page's list after you change the copy, the page is answering it now, and the conversations can move on to the questions that need a live answer.

Measure PDP performance

Before you test a change, settle on the numbers you'll judge it by.

How to calculate PDP conversion rate

PDP conversion rate is the share of a product's views that end in a purchase of that product:

PDP conversion rate = purchases of an item ÷ views of that item

Both numbers sit in the same Ecommerce purchases report: items purchased and items viewed. If a product had 4,000 views last month and 120 purchases, its PDP conversion rate was 3%. Items purchased counts units, so for products people often buy in multiples, keep that in mind before you compare them.

Some sources fold add-to-cart into the definition and count a shopper who adds the item to the cart as converted. That mixes two different metrics. Pick one definition, use it consistently, and say which one you used whenever you report the number.

Add-to-cart rate and revenue per visitor

Add-to-cart rate is items added to cart divided by items viewed. It tells you whether the page persuades, which makes it the most direct read on PDP changes, since it isn't affected by what happens later in the cart and checkout.

Revenue per visitor tells you whether that persuasion pays. A change can raise add-to-cart rate by nudging shoppers toward a cheaper variant and still lower revenue. Track both, and treat revenue per visitor as the deciding number when they disagree.

What bounce rate tells you on a product page

GA4 changed how bounce rate works. In GA4, bounce rate is the percentage of sessions that weren't engaged, and a session counts as engaged if it lasts longer than 10 seconds (the default, which you can adjust), has a key event, or has two or more page views. So bounce rate is 100% minus engagement rate. Many older guides still describe the Universal Analytics version, which measured single-page sessions, so check which definition a source uses before comparing numbers.

On a product page, read bounce rate by traffic source. A high rate from one source usually points back to a traffic mismatch, the first thing this guide covered. A bounce isn't always a failure, either: a shopper who arrived by mistake can read the page, decide it's not for them, and leave, which is the right outcome.

Why PDP conversion benchmarks mislead

You'll find plenty of tables of "PDP conversion rate benchmarks" by industry. Before you use one, check the formula. If it divides orders by all sessions on a store, it's a site-wide conversion rate, and comparing it with a single product's purchases-to-views rate tells you very little.

Compare your products against each other instead, grouped by category or price band, and track each page against its own history. A product that converts at half the rate of similar products in its category is a better lead than any industry average.

Test one change at a time

Every test should start from something you found above: a stall in the data or a question topic from your conversations. That way each hypothesis comes from evidence, and you'll know what to look for in the results. "Adding a width note next to the size selector will raise add-to-cart rate on the hiking boot" is a test you can learn from, and "a new layout might do better" is one you can't.

Change one thing per page at a time, so you know what caused the result, and wait for enough traffic before calling a winner. Low-traffic products rarely get enough visitors for a clean test. Test the change across a group of similar products instead, like adding width notes to every boot, or do a before-and-after read and note that promotions and seasonality can move the numbers on their own.

For how to sequence tests across your site and report the results in revenue, see our ecommerce CRO framework.