A higher RPM is not evidence of higher earnings until you check what the denominator counts. One publisher can report $12 per thousand sessions and another $8 per thousand pageviews while describing exactly the same revenue and traffic.
This matters when comparing an AdSense screenshot with a Mediavine or Journey report. The label matters as much as the number. A dashboard may also filter out traffic that could not earn from ads, creating a third denominator.
One revenue amount, two honest RPMs
The following example inputs demonstrate the calculation. They are not a publisher case study or a forecast.
| Input or result | Same reporting period |
|---|---|
| Advertising revenue | $600 |
| Sessions | 50,000 |
| Pageviews | 75,000 |
| Pageviews per session | 1.5 |
| Session RPM | $12 |
| Page RPM | $8 |
Session RPM = $600 / 50,000 × 1,000 = $12
Page RPM = $600 / 75,000 × 1,000 = $8The session-based rate is 50% higher. The publisher has not earned an extra cent. More pages were counted than sessions, so dividing by pageviews produces a smaller rate.
Google's RPM explanation identifies the traffic unit as part of the calculation. Mediavine's dashboard explanation also distinguishes revenue and traffic metrics. Check the exact field in the report you are using rather than assuming every number called RPM means page RPM.
Convert only with your own matched traffic counts
If both counts cover the same site, dates and traffic population, the relationship is:
Session RPM = Page RPM × (pageviews / sessions)
Page RPM = Session RPM / (pageviews / sessions)In this example, $12 divided by 1.5 is $8. Using a generic 1.5 conversion for another website would be a mistake: it is an input chosen for this example, not an industry average.
Do not divide a network's filtered sessions into GA4's unrestricted pageviews and call the result a conversion factor. Differences in consent, bot filtering, time zones and reporting scope can make the counts incompatible. If you cannot align them, report the two rates separately with their definitions.
A practical comparison sheet before changing networks
- Export earnings for one complete period, noting whether the amount is estimated or finalized and what fees it includes.
- Record the exact denominator label and whether the dashboard is showing all or monetized traffic.
- Record pageviews and sessions from a consistent reporting source for that period.
- Recalculate a common rate only where the populations match. Keep total revenue beside it.
- Repeat for the second period, noting changes in country mix, season and ad setup.
Even a correctly normalized increase does not prove that switching networks caused it. The visitors, month or inventory may have changed too.
Use the right benchmark
Our broker-checked RPM dataset uses pageviews. Compare it with page RPM, not session RPM. The sample contains businesses selected for sale and is not a Mediavine-only benchmark.
You can enter your pageviews and revenue in the RPM calculator to check the division. For the separate question of admission, read the Journey and Mediavine eligibility comparison. An earnings rate is not an application requirement.
If the dashboard says mRPM, read why monetized RPM can rise without additional revenue before comparing it with either rate here.
To compare two complete periods, the revenue-change comparison accepts either pageviews or sessions for both periods. It normalizes revenue per day and separates traffic and RPM components. Keep the same denominator, timezone and revenue definition; session results are not compared with our pageview benchmark.
Evidence grade: A. The arithmetic is reproducible; this is an instructional example supported by provider definitions, not an independently observed comparison of ad networks.
Check the network’s own metric name
Raptive’s guide to RPM and Page RPM gives separate formulas for visits and pages. Mediavine’s glossary also defines session RPM. Use the definition from your actual report; neither source establishes a typical rate for your site.
A session is a reporting rule, not a person
A user can create several sessions. A session can include several pageviews. The count depends on the analytics system and its configuration, not only on how many people know the site.
Google's session documentation describes a period of interaction and a default inactivity timeout. That makes sessions useful for analyzing visits, but it does not make them interchangeable with unique people or pages. A change in measurement configuration can change the count without creating the equivalent change in reading.
If two sources disagree on sessions, check how each observes visits. Compare the date range, timezone, filtering, consent behavior and site scope. Do not choose the smaller count merely because it produces a larger RPM. The correct denominator is the one that matches the defined reporting question.
Keep measurement changes in a dated log. Otherwise an apparent jump in session RPM after a release may reflect fewer recorded sessions rather than better earnings. Total revenue beside the rate helps reveal that possibility.
More pages per visit can raise one rate while another stays flat
Take a separate chosen example with fifty thousand sessions and one pageview per session. At an $8 page RPM, fifty thousand pageviews produce $400. Session RPM is also $8 because the counts happen to match.
Now hold sessions at fifty thousand and page RPM at $8, but assume visitors view one and a half pages per session. Pageviews become seventy-five thousand and revenue becomes $600. Session RPM rises to $12 while page RPM stays $8.
Swipe or scroll the table horizontally to see every column.
| Chosen scenario | Sessions | Pageviews | Revenue | Page RPM | Session RPM |
|---|---|---|---|---|---|
| One page per session | 50,000 | 50,000 | $400 | $8 | $8 |
| One and a half pages per session | 50,000 | 75,000 | $600 | $8 | $12 |
The second row adds revenue because it assumes more pageviews earning at the same rate. It does not establish that adding an internal link will cause that behavior or that every additional pageview earns the same amount. It shows how the measures relate under named conditions.
That distinction matters when evaluating navigation changes. A session rate can reflect both page-level earnings and reading depth. A page rate focuses on revenue relative to pages. Keep both and total revenue visible instead of decide that one is the only honest metric.
The same page RPM can hide different total outcomes
A rate has no scale without its count. A site with ten thousand pageviews at $8 page RPM earns $80. A site with one hundred thousand pageviews at that same rate earns $800. The identical RPM does not mean the businesses make the same amount.
The reverse is also true. Two sites can earn the same revenue with different pageview counts and therefore different rates. A rate comparison needs the task: are you trying to understand revenue efficiency, total income, reader behavior or the economics of a change?
For a financial decision, add the relevant costs. Neither session RPM nor page RPM subtracts hosting, writers, software, implementation work or owner pay automatically. A higher revenue rate can coexist with lower contribution if the extra revenue costs more to produce.
That is why the network-switching planner asks about costs and a comparison period. The denominator check comes first, then the economic comparison. A bigger rate alone cannot complete the decision.
Monetized sessions add a separate coverage question
Mediavine's current mRPM definition counts sessions with at least one served ad. That narrower count can be useful for examining monetized traffic, but it answers a different question from revenue per all sessions.
Use a chosen scenario with $600 revenue, fifty thousand total sessions and forty thousand monetized sessions. All-session RPM is $12. Monetized-session RPM is $15. Both use the same earnings. The monetized share is eighty percent under these matched counts.
The identity is all-session RPM equals monetized-session RPM multiplied by the monetized-session share. Here, $15 multiplied by 0.80 gives $12. This is a reporting identity, not proof that excluding sessions increased the money earned.
Do not label the remaining twenty percent as ad blockers without more evidence. Unmonetized sessions can reflect several conditions. A count difference alone cannot separate privacy choices, unsupported inventory, demand, invalid traffic or other implementation details. Use the provider's breakdowns and actual setup to investigate.
Also avoid combining monetized-session counts with pageviews from a different population. The earlier pageviews-per-session identity needs matched scope. A filtered denominator is not repaired by dividing it into an unrestricted count from another report.
Weight each rate by its matching count
Suppose one complete month has ten thousand sessions and $100 revenue, giving $10 session RPM. Another has ninety thousand sessions and $450, giving $5 session RPM. The simple average of the two rates is $7.50.
Across both months, revenue is $550 and sessions are one hundred thousand. The combined session RPM is $5.50. The higher-traffic month carries more weight in the pooled calculation.
An equal-month average can describe a particular summary of months, but it is not the pooled rate across sessions. The same weighting issue applies to page RPM across pages, devices, countries or periods. Use total matching revenue divided by total matching count for the pooled measure.
When presenting a benchmark, say whether it summarizes businesses, months or traffic units. Our historical business median does not give every pageview the same weight. That difference can explain why a pooled rate and a median business rate are far apart without either being an arithmetic error.
Compare periods after aligning complete days
A longer period can produce more revenue with a lower daily rate of activity. If one export covers fifteen days and the other covers thirty, compare complete-day totals and rates carefully before deciding the business improved.
For a chosen example, fifteen complete days produce $150 from twenty thousand pageviews. Thirty complete days produce $240 from forty thousand. Total revenue rises sixty percent, but revenue per day falls from $10 to $8. Page RPM falls from $7.50 to $6.
The purpose is not to declare daily revenue the only metric. It is to keep period length from becoming an invisible explanation. A growing monthly total can hide a weaker average day, and a shorter month can have a lower total while the underlying daily pace is stronger.
Check timezone boundaries too. A partial first or last day in one report can disrupt a small comparison. Keep the original exports and their stated timezones rather than align them by filenames alone.
A practical diagnosis when the rates look impossible
Start by reproducing one rate from its own report's earnings and count. If the arithmetic fails, check whether the displayed total, filters or period differ from the underlying export. A rounded rate can produce a small difference; a large one needs explanation.
Next, inspect the relationship between pageviews and sessions within the same source. If the implied ratio surprises you, verify that you did not select users, engaged sessions or monetized sessions instead. A familiar-looking label can conceal a different field.
Then compare revenue scope. Estimated earnings, finalized earnings and payments are not automatically the same amount. A bank deposit may cover a different period or include adjustments. It cannot simply replace the month's earned-revenue numerator.
Finally, check whether the report changed its default view. A switch from all traffic to monetized traffic can raise the headline rate while leaving revenue unchanged. Preserve both views and the date of the change so you can interpret history consistently.
What to ask before accepting a performance claim
Ask for the complete rate name, traffic count, revenue amount, date range and included fees. Ask whether the result covers the same site and audience as the comparison. Ask whether it is an observed period, a forecast, an introductory guarantee or a selected illustration.
A screenshot without those details is incomplete evidence, even if the number is genuine. A source link to a metric definition can explain the formula; it cannot prove that the screenshot used compatible data.
You can still use a limited result to ask a useful next question. Recalculate a shared unit where the evidence supports it. Leave incompatible rates separate where it does not. A clearly unresolved comparison is better than an exact percentage improvement assembled from unlike denominators.
The outcome should be simple: one earnings amount, clearly named counts and a comparison whose scope another person can reproduce. That is the foundation for deciding whether a change improved the business rather than merely made its headline number larger.
Keep an undefined rate unavailable
Zero sessions cannot support a session RPM calculation, and zero pageviews cannot support a page RPM calculation. A zero revenue amount with positive traffic produces a zero rate, which is a different state. A missing traffic count is not the same as a measured zero.
If positive revenue appears beside zero reported traffic, investigate scope and timing before interpreting it. The money may belong to another period, the count may be unavailable or the reporting source may differ. The right response is a reconciliation question, not an infinite RPM badge.
Negative values also deserve explicit treatment. An adjustment can make a net revenue field negative under some reporting definitions, but that does not mean a visitor literally generated a negative number of pages. Keep adjustments and traffic counts labeled and avoid mixing a payment adjustment into an ordinary earnings comparison without explanation.
For manual checking, start with small values: ten dollars from one thousand pages gives ten-dollar page RPM. Doubling traffic at fixed revenue halves the rate. Doubling both leaves the rate unchanged. Those identities are useful regression checks, though correct arithmetic still cannot establish that the source data describes your actual business accurately.
What is page RPM when a network reports session RPM?
Page RPM means revenue per thousand pageviews. Session RPM uses sessions instead. You need the matching count to translate between them. If an example period has $300 in revenue, 30,000 pageviews and 20,000 sessions, page RPM is $10 and session RPM is $15. Neither number is a pay rise or a loss: both describe the same $300.
The ratio is pageviews divided by sessions. In that example it is 1.5, so session RPM is page RPM multiplied by 1.5. Do not use that example ratio for your own site unless your matching report actually shows it. Provider-specific session definitions and filters can also differ. Keep the definition alongside the exported totals.
When moving between a network report and your analytics, compare both date boundaries and counting rules. If you only have sessions, a page RPM comparison remains incomplete until you have pageviews. Leave the missing count unknown rather than borrowing another site's average.