All testsAli Demirbaş - Lab

Category & Listing

How Many Products Per Page? A/B Test Example

Showing more products per page makes a wider selection available at once, but can increase page load. The goal is to help visitors find products without harming performance; use product-detail visits as the primary outcome.

A/B test scenario. This page is a test plan, not the result of a real experiment.

  • Category listing
  • Product detail page visit rate

Option A vs Option B

How many are shown is the variable, not what they look like.

Changed
Quantity
Page
Category listing
Difference
changed

Hypothesis

With more products per page, shoppers may scan a wider selection on one screen and find something that interests them more easily, but the page may get heavier. A page with fewer products stays lighter, and the balance between those two effects may decide which count leads on product detail page visit rate.

Test plan

When to run this test

Visitors leaving the listing without moving to the next page, session recordings of people paging back and forth, or a crowded listing that loads slowly on mobile are clues that the number of products per page does not suit your shoppers. If the product count shapes discovery, shoppers browse more of the range and open the detail page of one of the products. If the listing is already slow, fix load time first; otherwise you cannot separate the effect of the product count from the effect of speed.

How to measure success

Product detail page visit rate

Compare eligible visitors who reach a product detail page after viewing the listing.

Also track

  • Purchase conversion rate (CR)Compare purchases among all eligible assigned visitors over the same follow-up window.
  • Page load timeMeasure listing load performance on the same devices and network conditions.
  • Listing exit rateCompare visitors who leave the listing experience.
  • Products actually seenCount products that entered the viewport; loaded products are not necessarily seen.

How to set it up

  • Products per pageCompare 12 products per category page with 24.
  • Keep constantKeep product order, card design and loading behavior unchanged.
  • DiscoveryReview product clicks together with the number of products actually seen.
  • PerformanceTrack page load performance alongside discovery and purchase.
  • DeviceReview mobile and desktop separately.

What to watch when reading the result

  1. 1If product detail page visits rise while page load time gets worse, do not accept the result on its own; reading a click or conversion gap from a slower listing is misleading. Check purchase conversion rate, listing exit rate and products actually seen too, because a loaded product is not necessarily a seen one.
  2. 2Split results by device, and do not carry a desktop winner straight to mobile, where screen size and connection differ; validate it there. The finding is specific to these category pages and the two counts you tested.
  3. 3Before reading the gap in product detail page visits, get the sample per variant from the sample size calculator and divide it by the eligible visitors each arm gets per day to set the planned run. Do not decide before that run ends; if the gap is still unclear then, record that this test did not separate the two counts.

Frequently Asked Questions

Why use product-detail visits as the primary outcome?

This scenario tests product discovery. Use reaching a product page as the primary outcome. Purchasing and actually viewed items are supporting measures, not interchangeable success criteria.

How should slower loading affect interpretation?

Check the predefined performance guardrail before accepting a discovery improvement. More items may increase page weight and abandonment, so report that implementation cost.

Can the desktop item count be used on mobile?

Not without validation. Screen constraints and browsing behavior differ. Review the device-specific comparisons before extending the selected count.