DEV Community

Cover image for AdSense to Journey: My First 12 Revenue Dates
keyboardTester.Click
keyboardTester.Click

Posted on Originally published at keyboardtester.click

AdSense to Journey: My First 12 Revenue Dates

This is an adapted snapshot of my living case study on KeyboardTester.click: I switched from AdSense to Journey—here are the real earnings so far. The source page will receive the 21-, 30-, 60-, and 90-day updates.

I made the final production switch from Google AdSense to Journey by Mediavine on August 3, 2026.

The first result was not the easy revenue win that publisher testimonials can make an ad-network migration sound like.

At my August 16 snapshot, 13 calendar days had elapsed—day 14 when launch day is counted—and Journey had finalized 12 revenue dates through August 14. The August 3 launch date may be partial because I have not reconciled the exact cutover time with Journey's reporting-day boundary.

Here is the comparison I can actually defend:

Reporting system Evidence window Gross revenue shown Simple average
GA4-linked AdSense revenue July 27–August 2, 7 full days $8.11 About $1.16 per full day
Journey ad server August 3–14, 12 finalized dates $1.76 About $0.15 per reported date

That makes the early Journey average roughly 87% lower. It is a directional comparison, not a controlled experiment: the windows have different lengths, the launch date may be partial, and traffic mix can change.

It would be equally misleading to compare only the raw totals, to call this a mature Journey RPM, or to claim that every publisher will see the same result.

Traffic was the control, not the explanation

When revenue falls after a migration, "traffic must have fallen" is an easy story. Independent GA4 data did not support it.

The last clean AdSense week recorded:

  • 8,273 sessions, about 1,182 per day;
  • 10,789 pageviews, about 1,541 per day.

The 12 complete post-cutover days from August 4 through August 15 recorded:

  • 14,793 sessions, about 1,233 per day;
  • 22,053 pageviews, about 1,838 per day.

Daily sessions were therefore about 4% higher and pageviews about 19% higher in the post-cutover control. Weekday mix, geography, devices, search demand, and top-page mix prevent a causal claim, but the data is enough to reject a traffic collapse as the simple explanation for the revenue gap.

This is why I keep analytics separate from the ad dashboard. The same evidence discipline helped when I investigated a suspicious traffic burst in GA4, Cloudflare, and origin logs: one screen is a signal, not the entire diagnosis.

Why I am not publishing a Journey RPM

Journey's ad server showed revenue, but its portal still showed zero imported sessions and pageviews in the traffic fields used for RPM.

Those zeros do not mean the site had no visitors; GA4 independently recorded 14,793 sessions. They do not mean Journey earned nothing; the ad server recorded $1.76.

They mean the denominator is missing from Journey's reporting path.

I could divide one system's revenue by another system's sessions and produce a number. I did not, because reporting timezones and metric definitions may not match. A provisional RPM would look more precise than the evidence allows.

A normal delay is one thing. Persistent zero imported traffic after this many finalized revenue dates is an unresolved reporting or integration issue, so I am documenting it and escalating it rather than hiding it inside an invented calculation.

The implementation lesson was bigger than the homepage

KeyboardTester.click is a custom PHP site with ten blog languages and hundreds of legacy localized bridge routes. The homepage and an English article both looked correct after launch.

An inventory audit later found a duplicate Journey wrapper on hundreds of bridge routes.

We removed the duplicate and rechecked the route family until each audited route exposed exactly one wrapper. We also verified the public ads.txt response, cache state, sitewide script, and connected GA4 property.

That changed my migration checklist:

  1. Inventory every renderer before changing the ad stack: home, article, category, locale wrapper, embed, legacy bridge, and special layout.
  2. Remove the previous programmatic network in line with the active onboarding instructions.
  3. Confirm exactly one new wrapper on representative pages and unusual routes.
  4. Verify the public root ads.txt response instead of assuming the file or redirect works.
  5. Clear only the affected application, server, and CDN caches, then inspect the public response again.
  6. Keep a tested recovery path. My shared-hosting failover case study explains the same reversible-change principle at the infrastructure layer.

"The tag appears on the homepage" is not a complete launch test on a templated site.

The latest dates improved—but the sample is still tiny

The first three reported Journey dates produced about $0.11 in total. The latest three finalized dates in this snapshot produced about $0.97.

That movement is encouraging. It is not enough to declare a successful migration, a stable RPM, or predictable monthly income.

The responsible response is to hold the setup steady long enough to measure it, while continuing to investigate the missing traffic import. Swapping networks every few days would destroy the comparison.

What I would do before switching today

Export a real baseline

Save clean 7-, 14-, and 30-day ranges for gross revenue, sessions, pageviews, geography, device mix, and top content. Record the timezone and last complete date in each system. Do this before changing code, not after a disappointing result.

Budget for both revenue and payment delay

Journey documents a Net 65 payment schedule. Reporting can also lag. A publisher needs enough cash buffer for a weak ramp and the payment timetable—not merely enough traffic to qualify.

Define review gates before emotions take over

My gates are 21, 30, 60, and 90 full post-launch days. I will also update earlier if Journey's missing session, pageview, and RPM import is repaired.

Write down what triggers support escalation, what justifies waiting, and what sustained gap would make you reassess. One unusually good or bad day should not write the policy.

Protect the evidence

I shared aggregate revenue, sessions, pageviews, dates, and tightly cropped proof on the original article. I did not publish account or property IDs, names, emails, payment details, page-level revenue, AdSense clicks, CTR, CPC, or ad-unit data.

Transparency does not require exposing a monetization account.

Would I recommend the switch?

Not as a universal yes or no.

If you have a clean baseline, cash buffer, complete route inventory, and a reporting setup you can independently verify, a time-boxed test can be reasonable.

If traffic imports remain blank, old scripts or duplicate wrappers remain, or cash flow cannot tolerate a ramp and Net 65, resolve those risks before treating anyone else's testimonial as your forecast.

My position at this snapshot is simple: Journey has not yet beaten AdSense on this site. Traffic held, the latest revenue dates improved, and the reporting problem remains real. All three facts belong in the same conclusion.

The source article contains the privacy-safe evidence crops, full comparison tables, official documentation, FAQs, and the dated update log. Bookmark it if you want the result after the first 12 dates rather than only the launch-day story:

AdSense to Journey by Mediavine: My Real Earnings

Top comments (0)