For the request-based calculation in our tool, filled requests must be part of total requests. A result above 100% means the supplied counts do not fit that relationship. Check the data definitions before deciding that ad delivery itself is broken.
Start with a valid pair
A fictional report with 7,500 filled requests and 10,000 total requests gives 75%. The remaining count is 2,500 unfilled requests in that same defined scope. It does not establish the price that any unfilled request would have earned.
Now suppose someone enters 12,000 ad impressions as “filled requests” alongside 10,000 requests. That substitution may describe a different reporting relationship. The fill rate calculator rejects it for the supported request-count definition.
A four-part reconciliation
- Copy the complete metric names from the original report.
- Match dates, time zone and inventory filters.
- Check whether the numerator really counts filled requests rather than rendered ads, pods or another event.
- Compare with the platform’s documented metric, not only a familiar label.
The Google metric reference shows why full names matter: fill-related metrics can use different definitions in different reporting contexts.
Do not turn an unfilled count into a revenue claim
Multiplying every unfilled request by the observed average CPM assumes demand and price that were never observed. Treat that as an explicit hypothetical scenario if you model it, not measured lost revenue.
Should I change targeting to make the calculator accept the count?
No. First reconcile the counts. A validation guardrail is not a recommendation to change production settings. Use the monetization health report to organize the remaining evidence and questions.
Official references
References checked: 26 October 2026. Examples identified as fictional are teaching inputs, not performance benchmarks.