# A/B Test: Comparison Table Showing Only Differences

Page: https://alidemirbas.com.tr/en/lab/ab-test-library/tests/ab-test-comparison-table-showing-only-differences

## Hypothesis

If the comparison table opens with only the features that differ, shoppers may see what sets the products apart without scanning identical rows. An easier choice could in turn raise the order completion rate.

## When to run this test

Visitors scrolling up and down a long table in session recordings, heatmaps showing attention spent on rows that are identical across products, or exits from the comparison without a purchase suggest that the table wears shoppers out. If showing differences first helps, shoppers pick a product sooner and that choice turns into an order. If the problem is missing or conflicting feature data, fix the data first, and decide up front which shared features are critical so the variant never hides them completely.

## Primary metric

**Order completion rate**: Compare purchases among visitors assigned to the comparison-table experience.

## Other metrics

- **Time to decision**: Define the selection event in advance and measure time from the same start event in both arms.
- **Comparison interaction**: Track switching between the full-feature view and the differences-only view.
- **Return rate**: Track returns linked to an incorrect choice.
- **Exit rate**: Track exits from the comparison page.

## What to check before and during the test

- **Default view**: In the variant, show only differences in the comparison table by default.
- **Keep constant**: Keep products, feature data, table design and CTAs unchanged.
- **Decision**: Read time to decision alongside the target action.
- **Access**: Keep all product features available to visitors.
- **Separate tests**: Test the toggle's design, color or placement separately.

## What to watch when reading the result

- A shorter time to decision is not a win by itself; the order completion rate is the measure to judge. If orders rise while returns linked to a wrong choice or exits from the comparison page also climb, the simpler view may be hiding information shoppers need.
- Look at switches between the two views and confirm the view-switching control is easy to find: if many shoppers go back to the full table, a critical shared feature may be hidden. What you find is specific to this comparison table; read each device apart and check that the table stays readable on mobile. Returns from a wrong choice arrive late, so keep tracking the return rate for a while after the test closes.
- Work out the required sample before launch with the [sample size calculator](https://alidemirbas.com.tr/en/calculators/sample-size-calculator), and fix your stopping rule around it. Do not end the test at the first result that looks significant; if the difference is still small when the planned run ends, record it as an effect this test could not measure.

## Frequently Asked Questions

### How should shared features remain accessible in a differences-only view?

Keep a clear way to see all features. Do not remove shared information essential to the decision. Preserve products, underlying feature data and purchase actions.

### Does a shorter decision time make the variant a winner?

Use order completion as the primary outcome. Define identical timing events and monitor returns. Faster choices can still be unsuitable choices.

### What do switches between comparison views reveal?

They may indicate a need for hidden information. Interpret switching with exits and returns, and confirm that the table remains usable on mobile.