Make the filter count describe the choices the result list actually groups

Name the counted object at each stage

Algolia’s facetingAfterDistinct reference, checked 7 November 2026, distinguishes facet counting before and after distinct grouping. It warns that after-distinct counting can be inconsistent when records within a group have different facet values. This documented condition matters more than a desire to force every visible number to match.

Create a synthetic catalog with several records representing fewer customer-facing product groups. Record the indexed record identifier and the grouping identifier separately. Write what the interface intends a result card and a facet count to represent. A count of matching records is not necessarily a count of distinct choices, and neither automatically describes the quantity available for purchase.

Build a group-membership ledger

List every fixture record, its group and its facet values. Choose one group whose members agree on the facet and another whose members differ. Calculate the record-level and group-level answers by hand for a small query. Keep the calculation simple enough that a reviewer can inspect all members without trusting the search response.

For each displayed group, record the representative selected by the engine and the facts shown on its card. A representative can be useful for presentation while failing to express every value in the group. Do not copy the representative’s attributes onto the whole family in the expected-answer ledger. That would hide the difference the test is meant to expose.

Compare counts before and after a refinement

Run the same synthetic query in the intended grouping configuration and record hits, displayed groups and facet counts as separate observations. Then apply one facet value and inspect both membership and the new representatives. A different representative can make the filtered result look inconsistent with the earlier unfiltered summary even when the engine is following its configured rules.

Ask the search owner to explain which stage produced each count, including any approximation or implementation limitation reported by the actual response. Do not infer exact arithmetic from a rounded display or promise that every pre-click facet number equals the later number of cards. If the chosen grouping model cannot produce an honest count for a facet, document the limitation instead of switching a global setting without reviewing all groups.

Choose an explainable presentation contract

Decide whether the interface should count records, groups satisfying a condition, or another clearly supported unit. Align the label and acceptance fixture with that choice. If a family can contain several qualifying variants, the customer-facing presentation must not imply a single exact configuration without evidence. Keep inventory quantities and purchasability in their separate systems of record.

The acceptance artifact is the group ledger plus a stage-by-stage count explanation. Retest it after changes to grouping keys or record granularity. A repaired number should remain correct for the disagreement fixture, not only for groups with identical attributes. This exercise authorizes no index changes; it gives the technical and merchandising owners enough evidence to choose a counting model that reflects the actual search experience.

Make the reasoning concrete.

A fictional store indexes three finishes of one desk as separate records but displays one family card. A finish facet shows several matches, and the team proposes applying after-group counting everywhere without checking whether group members share finish values.

The search owner keeps record count, grouped choices and inventory quantity distinct. The fixture must explain the count transition after a finish refinement rather than merely matching the first screen’s card count.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Unit

   What does a card represent and what should the facet number count?

2. Groups

   Which records belong to each distinct group?

3. Variation

   Which facet values agree or differ within a group?

4. Transition

   How do membership and representatives change after filtering?

5. Contract

   Which counting stage and limitations must the interface disclose?

Watch for the wrong conclusion.

• Calling a variant-record count a count of product families.
• Assuming every member shares its representative’s facet values.
• Changing grouping solely to make two displayed numbers match.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic acceptance only; no external changes, messages, index operations or permissions are performed.

• facetingAfterDistinct →Primary platform documentation · Supports: Supports the documented count-stage distinction and within-group facet-value condition. The ledger and interpretation workflow are original.