Aglet

Triage facet count mismatches before changing the filter UI

A facet count may describe all matching products while the page shows one slice, or it may use a different filter boundary entirely. Triage the counting promise first. Capture the query, selected filters, result total, bucket values, and page context before calling the numbers inconsistent.

Establish what is happening

  1. Capture one count set

    Record the full query, active filters, total hits, visible rows, bucket counts, sort, page, and index timestamp. Repeat after selecting one facet. Keep the count source and rendered label together so a screenshot does not hide the counting scope.

  2. Compare counting boundaries

    Ask whether each number counts the filtered universe, the current page, variants, or parent products. Compare a broad query with a narrowed query and inspect selected values. A different but intentional universe needs explanation, not arithmetic repair.

  3. Set the trust issue

    State whether the mismatch is calculation, stale data, unclear copy, or an expected distinction. Link one control case where counts reconcile. Preserve the smallest failing query so the next investigation can reproduce the exact boundary.

What to carry forward

The triage record should name each count’s universe and the first query where the promise breaks. Stop when a reviewer can reproduce the numbers. If the counts are intentional but unexplained, route the labeling and scope question separately from a backend calculation issue.

Technical background: Adobe developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow