Why are my facet and hit counts not accurate?

Algolia returns the total number of hits and facet values with every set of results. Sometimes these values are not exact, since calculating these values impacts performance and therefore impacts the as-you-type experience.

We refer to this problem as non-exhaustivity. For the most part, non-exhaustivity is a non-critical problem, because when hit and facet counts reach such a large amount that this becomes a problem, users are not looking for exact numbers. However, we realize that this can be surprising behavior.

The problem

Non-exhaustivity is a performance optimization issue, shared by all search engines.

First, let’s look at a quick explanation of what’s going on when you get approximate hit and facet counts. When you type a query into Algolia, we compute a list of results that you will be able to paginate. Then based on this list of all possible results, we start computing hit and facet value counts one by one. Usually we try to compute everything in advance but this is not always doable, like when the count is completely dependant on the query of the user. Since this is an expensive operation in terms of performance, at some point the Algolia engine stops counting, and returns approximations. This is done so that the performance of the engine is good (you get results in a timely manner).

In some cases this is totally fine for our customers. Some of them will choose to display the approximations like ~200 (round the count) or just hide the count all together. We understand this is not ideal for every use case.

Solutions

There’s currently no magical way to solve the problem. But ultimately working on the performance of your index is the way to go. Here a few suggestions to improve query performance and therefore limit the cases with approximations:

• Reduce the index size as much as possible .
• Purge unnecessary records and remove attributes not necessary for the search experience.
• Keep the list of searchable attributes as low as possible. If not yet manually defined, define a list of searchable attributes, otherwise we consider every attribute searchable. See the related discussion. Especially consider lengthy attributes like description to be very costly.
• Ensure that all facet attributes which are needed only for filtering are wrapped in a filterOnly() tag (i.e. not showing the facet itself but only filtering on it). See here.
• Ensure hitsPerPage is set to a reasonable number.
• Reduce the number of attributes for faceting. We advise keeping this parameter as low as possible to only the strict minimum for your UI.

Also consider:

• Use the search parameters exhaustiveNbHits and exhaustiveFacetsCount to manage this on the front end, indicating to the user that the values are approximations.
• Reduce the number of filters or pre-compute some filters when possible in your data.
• Reduce the usage of CPU-intensive features (facets, many filters, geo, distinct, or optionalFilters) to the strict minimum for your use case.
• Explicitly set attributesToRetrieve, attributesToHighlight, and attributesToSnippet (if applicable). Some of them can even be set at query time.
• Consider removing attributes with large content (like descriptions) entirely from attributesToHighlight and attributesToSnippet.