AdSense Ad Requests vs Impressions Basics

Ad requests and impressions are two of the first AdSense columns small-blog owners compare—and one of the easiest pairs to misread. Google counts an ad request every time your ad code asks for an ad, even when nothing comes back. An impression counts only when at least one ad from that request begins downloading on the reader’s device. Understanding that gap keeps you from treating “requests” as “ads people saw.”

Metric neighbors: AdSense coverage report basics for small blogs (fill rate when requests exceed matched ads), AdSense CPM vs RPM for small blogs (Page RPM vs Ad RPM vs CPM language), and reading Page RPM in AdSense reports (pageview-scaled rates). Settlement stays on estimated earnings vs final payments—these counts are not cash in your bank.

Ad request = ask sent. Impression = ad began downloading per Google Help. Compare them to diagnose fill—not to forecast income from one row.

Disclosure: Educational AdSense reporting only. We do not publish niche benchmarks, guarantee earnings, or invent sample balances. Help examples illustrate mechanics—not your forecast.

Table of contents

1. Official definitions side by side
2. What happens between a request and an impression
3. Why requests often exceed impressions
4. Matched requests and unmatched rows
5. How this connects to coverage
6. Ad requests, impressions, and pageviews on one page
7. Opening these metrics in Reports
8. A calm weekly read habit
9. Mistakes that waste the comparison
10. FAQ
11. Use both metrics, not one alone

Official definitions side by side

Google’s glossary entries are short—read them directly:

Ad request (Help: Ad request): counted whenever your site requests ads to be displayed. It is the number of ad units that requested ads (for content ads) or search queries (for search ads). AdSense reports an ad request each time a request was sent, even if no ads were returned.

Impressions (Help: Impressions): counted for each ad request where at least one ad has begun to download to the user’s device. It is the number of ad units (for content ads) or search queries (for search ads) that loaded ads.

Help also notes that AdSense’s impression metric follows the industry downloaded impression standard—counting when the ad starts loading on the device—not merely when an ad server sends a creative that never reaches the browser.

If you remember one line: requests measure asks; impressions measure successful starts to load among those asks.

What happens between a request and an impression

Think in order:

1. A reader loads a page with AdSense code.
2. Each ad unit on that page sends an ad request to Google.
3. Google’s systems decide whether to return an ad for that unit—subject to policy, blocking, demand, format, and account status.
4. When at least one ad begins downloading for that unit, AdSense counts an impression.

Steps three and four are where beginners assume “request = ad shown.” They are not the same event. A matched response still might not become an impression if the creative never begins downloading—network issues, client blockers, or the reader leaving quickly can interrupt the chain.

That is why troubleshooting starts with naming which step broke: fewer requests than expected (code not executing), requests without matches (coverage), or matches without impressions (delivery or measurement edge cases). Jumping straight to “my niche is banned” rarely matches the metric story.

Why requests often exceed impressions

A healthy account commonly shows more ad requests than impressions because not every request returns an ad Google can serve on that unit at that moment.

Help on unmatched ad requests explains: unless coverage is 100%, you will have more ad requests than matched requests, producing unmatched rows in some reports.

Typical drivers (confirm against your account—not forum myths):

Google’s troubleshoot ad coverage issues article walks practical checks—ads.txt configuration, policy center warnings, blocking review, responsive vs fixed units—when coverage drops enough to hurt earnings.

If I were reviewing a small blog’s reports for the first time, I would compare requests, impressions, and coverage over a month, not one afternoon when traffic was thin. Single-day gaps exaggerate noise.

Matched requests and unmatched rows

Between total ad requests and impressions sits matched ad requests—requests that returned at least one ad (AdSense Management API metrics documentation lists MATCHED_AD_REQUESTS alongside AD_REQUESTS and IMPRESSIONS).

When coverage is below 100%, some reports show (Unmatched ad requests) as its own row—Targeting types, Ad types, Bid types, Ad unit, and Ad size among them per Help. Unmatched requests still count as ad requests but have no targeting type because no ad displayed.

Example from Help: a page with three ad units sends three requests; Google returns ads for two units and nothing for the third. Targeting-type reporting might show contextual and placement rows plus one unmatched ad request. That is normal arithmetic, not necessarily a bug—unless unmatched share spikes suddenly.

Do not merge unmatched rows into contextual analysis as if they were failed contextual ads. Help explicitly says to keep them separate when you read targeting performance.

How this connects to coverage

Coverage (Help: Coverage) is the percentage of ad requests that returned at least one ad:

Coverage = (Ad requests that returned ads / total ad requests) × 100

Help’s illustration: three units on a page, two display ads, one shows none → coverage about 66.67%. High coverage near 100% means Google could provide ads to most requests; lower coverage signals periods when Google returned no suitable ad.

This page owns definitions and the request→impression chain. When you need fill-rate reading habits, blocking triage, and report navigation for coverage specifically, use AdSense coverage report basics for small blogs. When you need rate columns built from impressions, use CPM vs RPM and Page RPM reading.

Ad requests, impressions, and pageviews on one page

Beginners often stack three different “counts” on one URL:

One pageview with two in-article units and one sidebar unit can produce three ad requests and up to three impressions from a single reader visit. That is why reports not matching your analytics is a documented topic—your server logs, GA4, and AdSense count different events under different rules.

Page RPM divides estimated earnings by pageviews. Ad RPM divides by ad impressions. Comparing Page RPM to Ad RPM without remembering the denominators creates fake mysteries—see CPM vs RPM before you redesign ad layout because one rate moved.

Multiple ad units per page are allowed when policy-safe—ad density policy basics—but more units mean more requests, which can increase unmatched opportunities if demand is thin.

Opening these metrics in Reports

Google’s UI moves, but the metric names remain documented in Help. Both ad requests and coverage sit under the Advanced metric family in Help’s wording—use the column picker in Reports rather than assuming every default dashboard shows them.

Practical approach:

1. Sign in to AdSense → Reports.
2. Choose a date range with enough traffic to dampen noise—often 7–28 days for small blogs.
3. Add Ad requests and Impressions columns from the metric picker (Advanced family when needed).
4. Optionally add Coverage or view the coverage report slice—hand off to coverage basics for fill-focused reading.
5. Segment by Ad unit when one placement drives unmatched rows.

If ads never serve at all, stop here and use ads not showing what to check—metric literacy does not replace serving triage on a blank site.

A calm weekly read habit

A lightweight routine beats daily panic scrolling:

1. Confirm ads serve on a real device (not only logged-in admin previews)—see preview vs live serving.
2. Note ad requests and impressions for the week; compute rough impression rate (impressions ÷ ad requests) only as a sanity check, not a invented KPI Google published.
3. If unmatched share jumps, open coverage troubleshooting and Policy center—before you rewrite content strategy.
4. If rates move but fill is stable, switch to Page RPM and CPM vs RPM—not request counts alone.
5. Bank questions stay on estimated vs final payments—requests are not dollars.

Small samples lie. Forty pageviews and twelve ad requests can produce percentages that look catastrophic until Tuesday’s traffic arrives.

Mistakes that waste the comparison

1. Treating ad requests as “ads shown” and expecting them to equal impressions.
2. Panicking at any gap instead of reading coverage trend and Policy center.
3. Comparing AdSense to server logs 1:1 without reading Help on execution and invalid traffic removal.
4. Adding units until requests explode without checking unmatched rows per unit.
5. Confusing impressions with pageviews when interpreting Page RPM.
6. Diagnosing earnings on one hour of data after a plugin change.
7. Skipping the coverage owner and guessing blocking from a screenshot in a forum.

FAQ

See frontmatter for schema pairs. Short answers above in the YAML; body sections expand context.

Use both metrics, not one alone

Ad requests tell you how often your layout asked for monetization. Impressions tell you how often an ad started loading after those asks. Coverage explains how many asks received a creative at all. Rate columns built on impressions—CPM vs RPM, Page RPM—tell you how estimated earnings scaled after fill.

Read definitions from Ad request and Impressions Help, then use coverage basics when fill is the question. Keep payout math on estimated earnings vs final payments. Requests and impressions are diagnostic vocabulary—not a promise about tomorrow’s deposit.