Traffic up, ad revenue down? Find the RPM drop before changing networks
By Plain Reckoner · 1,308 words · about 6 min · Updated
More traffic can still earn less: in a worked example, 100,000 pageviews earning $1,000 become 120,000 earning $720. Page RPM falls from $10 to $6. Matched reporting periods separate the arithmetic traffic and RPM changes; dashboard breakdowns are needed to investigate their causes.
- How it was measured
- Reproducible hypothetical arithmetic, checked against Google’s RPM definition and its earnings troubleshooting sequence on 2026-10-20. Downloadable daily examples are synthetic. No private publisher earnings, network-wide decline, expected RPM or causal diagnosis is asserted.
- Last checked
A traffic record is not necessarily an earnings record. If the additional pageviews earn less per thousand, total ad revenue can fall even while the audience grows. Before switching providers, changing layouts or blaming a search update, establish which part of that arithmetic changed.
This guide provides a reproducible example, a reporting checklist and a free comparison tool. You can type totals or preview daily CSV files locally. No account connection or earnings upload is needed. The tool separates traffic and RPM components; it cannot determine why either changed.
First, prove the apparent contradiction
Imagine two complete 30-day periods. The earlier period has 100,000 pageviews and $1,000 in ad revenue. The later period has 120,000 pageviews and $720. These are hypothetical figures, not a report about a particular network.
Swipe or scroll the table horizontally to see every column.
| Measurement | Earlier | Later | Change |
|---|---|---|---|
| Pageviews | 100,000 | 120,000 | +20% |
| Revenue | $1,000 | $720 | −28% |
| Page RPM | $10 | $6 | −40% |
| Revenue per day | $33.33 | $24.00 | −$9.33 |
Google defines RPM as estimated earnings divided by the relevant volume, multiplied by 1,000. Here, the denominator is pageviews. Revenue is traffic × RPM ÷ 1,000, so the revenue multiplier is 1.20 × 0.60 = 0.72. A 20% gain and a 40% loss do not cancel each other.
Download the synthetic earlier daily CSV and later daily CSV. In the tool, select pageviews, open each period’s CSV importer, choose the corresponding file, review the preview and select “Use these totals.” It should reproduce the table. This is also a quick way to understand the importer before using your own figures.
Make both periods mean the same thing
A mismatch can create a problem that the underlying business does not have. Record these details before drawing conclusions:
- Complete dates and time zone. Do not compare 30 complete days with a partial current month. If periods differ in length, inspect traffic and revenue per day. Similar daily averages can still hide different weekday or seasonal mixes.
- Same property and revenue scope. One report may cover all domains while another covers one site. Compare display-ad revenue with display-ad revenue, keeping affiliate and sponsorship income separate.
- Same currency and reporting state. Use USD in this tool. Convert externally on a documented basis if needed. Google explains that estimated and finalized earnings can differ; adjustments are not automatically an ad-rate change.
- Same traffic unit. Sessions, pageviews and monetized sessions are different counts. Read session versus page RPM and monetized RPM before comparing dashboard labels.
If you just launched Journey, start with the reporting-window explanation. Its default range can include onboarding and ramp-up. That is a specific documentation point, not a guarantee that any later decline will recover.
Use the arithmetic to choose the next investigation
The comparison normalizes both periods per day and splits the change symmetrically. It uses the average RPM for the traffic component and average daily traffic for the RPM component. This avoids making the result depend on which factor you change first.
In our synthetic example, extra traffic contributes about +$5.33 per day to this arithmetic split, while lower RPM contributes about −$14.67 per day. Together, the unrounded values give the −$9.33 daily revenue change. Displayed cents can differ slightly when added because of rounding. The downloaded comparison CSV retains calculation precision.
These components are descriptive. “RPM component” is not the amount a network caused you to lose. Country mix, content mix, consent, ad delivery, reporting changes and advertiser demand can all affect an aggregate. The same total can arise from different underlying problems.
Check ad delivery before assuming lower prices
Google’s earnings troubleshooting guide recommends checking pageviews, coverage, then impressions, starting at site level and using breakdowns to narrow the issue. Those metric definitions apply to AdSense; other networks may name or define their reports differently.
| What your matched reports show | Next check |
|---|---|
| Revenue and pageviews fall | Acquisition sources, landing pages, reporting dates and site availability |
| Pageviews hold, but coverage falls | Policy notices, serving limits, ads.txt status and crawler errors in the provider dashboard |
| Pageviews and coverage hold, but impressions fall | Ad implementation, formats, placements and whether ads render on affected pages |
| Delivery holds, but revenue per unit falls | Comparable country, device, source and page groups; revenue definitions and provider reporting |
These are investigation routes, not automatic diagnoses. An ads.txt warning and a revenue decline occurring together do not by themselves establish causality. Preserve dates and evidence, fix confirmed errors and ask the provider about the affected property and period.
Avoid repeatedly changing several settings at once. If you alter placement, consent and lazy loading together, a later recovery will be hard to interpret. Document the change and monitor comparable complete reporting days.
Look for a mix change hidden in the average
Suppose your existing pages continue earning the same amount per thousand views, but new traffic mostly lands on pages with fewer delivered ads. The site-wide RPM can fall even if no individual page becomes less valuable. Country, device and acquisition shifts can have the same averaging effect.
Compare the largest meaningful groups using both traffic and revenue, with the same denominator. Prioritize groups large enough to explain the site-wide difference. A dramatic percentage change on a handful of views is less useful than a modest change across most of the site. Do not assume every provider exposes every breakdown, and do not join reports that measure incompatible traffic.
Check suspicious traffic separately. More browser events are not proof of more real readers. A bot surge or your own verification visits may increase one analytics count without creating matching monetizable traffic. Cloudflare browser analytics, edge requests, GA4 sessions and network pageviews are different measurements; reconcile their definitions rather than expecting equal totals.
Import your own daily figures safely
The comparison tool accepts the three-column template: date,traffic,revenue_usd. Each period needs one row per complete calendar day. Use ISO dates such as 2026-09-01, whole traffic counts and plain nonnegative USD amounts. Select whether both files contain pageviews or sessions.
This is a template importer, not an automatic converter for raw AdSense, GA4 or Journey exports. Map and reconcile those reports first. The importer rejects duplicate dates, missing days, malformed numbers, oversized files and positive revenue on a zero-traffic day. It supports up to 366 days and 100 KB per file. Negative adjustments need reconciliation before import; they are not silently dropped.
Previewing a file does not overwrite the inputs. Apply its totals explicitly. Files are read locally in your browser; this feature does not upload them. The tool exports a calculation CSV you can keep with your investigation notes. It does not store a history of your entered periods.
Send support a useful question
Give the provider the domain, date range, time zone, revenue definition and denominator. Include matched totals and the particular breakdown that changed. State any confirmed implementation or policy warning, with the date you first observed it. Use the provider’s private support channel for sensitive account details.
A useful question is: “Across these complete dates, pageviews rose 20%, revenue fell 28% and coverage changed as shown. Which reporting or delivery issue should I check next?” That is easier to investigate than a screenshot of one low RPM.
Use the tool to establish the discrepancy, the documentation to choose checks and your private reports to investigate cause. If you later consider switching networks, treat application requirements and earnings evaluation as separate decisions.
Evidence: primary provider definitions and troubleshooting guidance, plus explicitly synthetic, reproducible arithmetic. No network winner, expected earnings or recovery date is claimed.
Tracked as RPM-UNIT-COMPARISON. If a number here looks wrong, tell us and we will check it against the source.