Why did my RPM drop? Work through it in this order

Start with the shape of the decline, not the cause

The most common mistake in an RPM investigation is starting with a theory. The
useful first move costs nothing and eliminates half the possibilities: plot
RPM by day and look at the shape.

A cliff — normal, then noticeably lower from one specific date onward. This
is mechanical. Something changed on that day: a deployment, a plugin update, a
network switch, an ads.txt edit. The date is the most valuable piece of evidence
you have, because you can go and look at what else happened that day.

A slope — a gradual slide over weeks. This is almost never a single broken
thing. It is seasonality, a shift in where your traffic comes from, or a change
in which of your pages are getting the visits.

The two need different investigations, and treating a slope as though it were a
cliff means hunting for a broken thing that does not exist.

A note on why this needs to be daily: monthly totals hide step changes
completely. A cliff on the 18th shows up in the monthly number as "down 12%",
which looks like a slope.

The order, cheapest first

1. ads.txt. Thirty seconds, and one of the most common causes. Load
yourdomain.com/ads.txt and confirm it is plain text containing every line your
networks gave you. A missing line removes an exchange from the auction, which
means fewer bidders and a lower clearing price on every impression — a genuine
RPM decline with no error message anywhere in the chain.

2. Are the ads rendering? Open a page with your blocker off and look. Theme
updates change container widths; a unit that no longer fits does not render. A
lazy-loading script that stopped firing leaves the ad code in the HTML and the
impression unserved. The code being present proves nothing.

3. Impressions versus pageviews. This one split tells you which half of the
problem you have:

• Pageviews steady, impressions down → the problem is on the page
• Both down together → the problem is upstream, in traffic
• Impressions steady, revenue down → the problem is in the auction — go back
  to ads.txt, or look at what changed in advertiser demand

4. Traffic mix. A flat visitor count can hide a large change underneath it.
Traffic that shifted from desktop to mobile, or from a Tier-1 market to
elsewhere, earns materially differently at the same volume. Look at the
breakdown, not the total.

5. Policy notices. Rarest of the common causes, and worth checking when
nothing else explains it. Restricted ad serving reduces the demand competing for
your inventory without removing your ads, so the page looks entirely normal.

The measurement trap

Two numbers get called "RPM" and they answer different questions:

• Reported RPM — revenue ÷ impressions served × 1000
• Revenue per visitor — revenue ÷ everyone who arrived

The gap between them is the share of your audience who never produced an
impression, mostly through ad blocking. A rising block rate moves the second
number and leaves the first completely unchanged.

So a site can show flat reported RPM while earning less per visitor every month,
and every dashboard will insist nothing is wrong. If your earnings and your RPM
disagree, this is usually why — and it is why the technology and gaming niches
are so much harder to monetise than their traffic suggests.

Why the date matters more than anything else

Almost every mechanical cause has a timestamp: a deploy, an update, a network
switch, a policy action. If you know the day RPM changed, you can look at what
else happened that day and usually have your answer in minutes.

If you only know the month, you are guessing.

That is the entire argument for tracking RPM daily against a trailing median
rather than reading a monthly total — which is what the
RPM analyzer does, and why it flags days rather than
periods.