Do Not Average Conversion Rates Without Their Denominators

One channel converts at 50%, another at 10%. An average of 30% looks plausible until you discover that the first channel had ten eligible attempts and the second had ninety. The percentages alone have hidden the size of the populations they describe.

For disjoint groups measured under the same contract, a pooled conversion rate is the sum of conversion counts divided by the sum of eligible counts. A simple average answers a different question: the average of the group rates when each group receives equal weight.

1. Keep counts beside every percentage

Consider a fully synthetic example, not a customer result:

• Group A has 5 conversions from 10 eligible attempts: 50%.
• Group B has 9 conversions from 90 eligible attempts: 10%.
• The pooled rate is 14 conversions from 100 attempts: 14%.
• The equal-weight average of the two rates is 30%.

Neither number is a mysterious software error. They use different weights. If the question is how the combined eligible population performed, 14% is the appropriate result under this example's assumptions.

Google's AVERAGE documentation defines the arithmetic mean as the sum of values divided by the number of values. Averaging two percentages therefore gives each percentage one vote, not each eligible attempt one vote.

Preserve the numerator and denominator at the point where a report produces the rate. Reconstructing counts later from rounded percentages can introduce additional error.

2. Weight by the population, not by the outcome

For compatible, non-overlapping groups, weighting each group's exact rate by its eligible count produces the same result as pooling counts. Weighting by conversions instead would give the outcome extra influence and answer a different question.

Google's AVERAGE.WEIGHTED documentation describes values with their corresponding weights. Its SUMPRODUCT documentation describes summing corresponding products. These are useful mathematical building blocks, but neither function checks whether your groups share a valid measurement contract.

This tutorial does not provide an untested spreadsheet template. The numerical example is simple enough to inspect directly: five plus nine is fourteen, and ten plus ninety is one hundred.

3. A correct weighted average can still describe the wrong thing

Before combining rows, check what the denominator represents. Eligible sessions, accounts, attempts and orders are different units. A numerator must use a compatible unit and success definition.

Google Analytics' user metrics documentation distinguishes total, active, new and returning users. The names are not interchangeable denominators, and another analytics system may implement its own definitions.

Identity is also part of the contract. Google's User explorer documentation explains that the selected reporting identity affects how users are represented. A report that counts devices cannot be silently combined with a report that counts signed-in accounts.

For a pooled distinct-user rate, groups must partition the relevant users or be recomputed from the underlying union. If one account appears in two channels, adding the two user denominators can count that account twice. Weighting the duplicated counts does not repair the overlap.

4. Separate pooling from fair comparison

The observed overall rate describes the actual mix of eligible traffic. If that mix changes, the overall rate may move even when individual group rates do not.

A fixed-weight comparison can be useful for a different question: what would the summary look like if both periods used the same group mix? Label that as a standardized comparison, document the chosen weights, and do not present it as the actual observed overall conversion rate.

Also keep observation windows compatible. A completed seven-day outcome window and an unfinished window are not two interchangeable rates. More precise arithmetic cannot make incomplete outcomes comparable.

5. Use a small acceptance checklist

Before publishing a combined conversion rate:

1. Write the unit, eligibility rule and success rule in plain language.
2. Check that each conversion belongs to the corresponding eligible population.
3. Preserve exact counts and only round the displayed final rate.
4. Verify whether groups overlap; if they do, recompute the intended population rather than adding distinct counts.
5. Treat zero-denominator and missing-data rows explicitly. Neither automatically means a measured 0% conversion rate.
6. Keep group results beside the overall result so a change in traffic mix remains visible.

These are acceptance conditions, not a claim of statistical significance or causal impact. A pooled rate, an equal-weight group average and a fixed-mix comparison can all be useful, but only when their labels tell the reader which question they answer.

Disclosure: this article is from the SensorFlow project maintainer, with AI-assisted drafting and source verification. When evaluating a self-hosted event pipeline such as SensorFlow, check the measurement contract separately from the transport. The synthetic demo requires no license; ingestion of real SDK payloads requires a commercial license. The acceptance method above is not a claim that the product automatically deduplicates every identity or selects conversion denominators for you.