AI Business Reports: Say When a Unique Count Is an Estimate

An AI-generated report presents a precise-looking number of unique customers. The number has no decimal places, sits neatly beside last month’s result and appears ready for a decision. Yet the underlying query may have estimated how many distinct identifiers were present rather than counted them exactly.

That can be a legitimate analytical choice. The business problem begins when the report drops the distinction. A fast estimate for understanding a large audience and an exact count for checking a specific list answer different needs. The reader should know which kind of evidence is on the page.

A whole number can still be an estimate

Google’s BigQuery reference for approximate aggregate functions describes APPROX_COUNT_DISTINCT as returning a statistical estimate of the distinct count. The returned type is an integer. Its whole-number appearance therefore does not establish exactness.

The documentation explains the trade-off: approximate aggregation can use fewer resources than exact aggregation and suit very large inputs, while introducing statistical uncertainty. The appropriate question is whether that trade-off fits the decision, rather than whether the result looks sufficiently tidy.

For an owner reviewing AI-written analysis, ask to see the function or metric definition behind the headline. A sentence such as “there were exactly…” needs evidence consistent with that wording. The assistant’s polished summary cannot change the method used to produce the number.

Define what is distinct before choosing how to count

Consider a fictional workshop business with these five attendance records: A17, A17, B24, C31 and C31. There are five records and three distinct identifiers. That small example is countable directly; no approximation is needed to establish those totals.

The result still depends on what the identifiers mean. If they represent bookings, the three distinct values count bookings. If one person can have several bookings, calling them three people would add an assumption. Exact arithmetic does not repair the wrong definition of the unit.

Before asking AI for a unique-customer count, specify the identifier, eligible records and period. Decide how test records, cancellations and missing identifiers will be treated. These are proposed reporting decisions for the example, not facts about a particular business or platform.

Recognise where approximation already appears

Google’s October 2022 technical explanation of unique-count approximation in Google Analytics describes the use of HyperLogLog++, or HLL++, for metrics including Active Users and Sessions. It contrasts exact distinct counting in BigQuery with approximate approaches designed to improve performance on large datasets.

The same explanation notes that precision settings involve a trade-off between memory and accuracy. It also discusses other conditions that need aligning when comparing exported data with Analytics reports, including reporting identity and time zone. A mismatch should not be attributed automatically to one cause.

This is a method explanation from a dated primary source, checked again for this article. It is not an inspection of your Analytics property. Ask which metric and calculation your particular report uses before applying the explanation to it.

Choose the method according to the action

For a broad planning discussion, a clearly labelled estimate may be adequate. A team could be asking whether an audience is generally expanding and where further investigation would be worthwhile. The decision should tolerate the uncertainty of the chosen method.

Now change the task. The workshop business needs to verify a list of people who completed an agreed set of sessions. An estimated count cannot identify the actual members of that list. The owner needs the underlying eligible records and the rule used to include each person.

An exact distinct count can help reconcile that list, but the count alone still cannot prove that the right people are on it. Two lists can contain the same number of identifiers while containing different identifiers. Compare membership when membership is what the decision requires.

Be careful near a threshold

Suppose a fictional internal rule says a programme review is triggered when the count reaches 1,000 eligible participants. An approximate result close to that boundary should prompt a question about the method’s suitability before the team treats the trigger as settled.

Do not invent a margin of error because the report needs one. Ask whether the tool supplies an applicable uncertainty description and what it means. If the decision requires an exact threshold determination, use an appropriate exact check on the agreed population.

The same discipline applies to small reported changes. Before describing a movement as meaningful growth, establish whether the figures use the same method and definitions, and whether the available evidence supports that interpretation. A difference between two displayed integers is not, by itself, an explanation of what changed.

Ask AI to preserve the method in its narrative

A proposed reporting instruction is: “For every distinct-count metric, state the entity, identifier, period and filters. Identify whether the calculation is exact or approximate. Preserve that distinction in the summary and flag any decision that needs a record-level check.”

The owner can inspect the answer against the query and source documentation. If the assistant cannot identify the method, label it unresolved and obtain that information. Rewriting the explanation with greater confidence would leave the evidence gap intact.

• Unit: what entity does each distinct identifier represent?
• Population: which records, dates and exclusions are included?
• Method: is the count exact or estimated?
• Decision: does this use tolerate approximation?
• Verification: is a total sufficient, or must the underlying membership be checked?

Reconcile definitions before chasing differences

If a dashboard and a downloaded list disagree, first align their populations and cut-off times. Compare their definitions and calculation methods. Only then investigate the remaining difference. This proposed sequence makes the disagreement easier to explain without assuming either source is automatically wrong.

MaryChuks.com’s guide to separating users, sessions and views addresses the earlier part of that problem: deciding which activity a website metric represents. Approximation adds another question about how the chosen quantity was calculated.

Retain the method note with the report. If a later revision replaces an estimate with an exact calculation, state that change so the reader can judge comparisons appropriately. A changed number may reflect a changed method as well as changed activity.

Useful AI business reporting makes the calculation understandable enough to support the next action. Label the estimate when an estimate fits; obtain an exact check when the decision requires one; inspect the actual list when the identity of its members matters.

Sources

• Google Cloud: BigQuery approximate aggregate functions.
• Google Analytics: Unique count approximation in Google Analytics. Technical explanation, October 2022.

Sources checked on 5 November 2026. The workshop records, threshold and reporting workflow are illustrative; no customer dataset or Analytics property was inspected.