How I scaled ARPDAU from $2 to $22 at Gamezop: a monetization playbook
Most monetization advice optimizes for the ad. The interesting question is how to optimize for the session — the chain of decisions that gets a player to a second, third, fourth ad without resenting any of them.
When I joined Gamezop in August 2024, the platform was generating about $2 in ad revenue per 1,000 daily active users. Eleven months later that number was $22, and the lift translated into roughly $400,000 of incremental annual revenue. This post is an honest account of the decisions that mattered, the experiments that quietly failed, and the Google Invalid Traffic crackdown that almost erased the gains in a single week. I am writing it because most monetization writing on the public internet optimizes for the ad — the placement, the format, the CPM. The interesting question is how to optimize for the session.
The starting picture
Gamezop distributes a catalog of HTML5 games across partner properties. The largest of these is Microsoft's MSN, where the games appear embedded inside the news and entertainment surfaces. A user typically arrives via an article tile, plays for a few minutes, and either bounces back to the news feed or follows a recommendation to another game. Each game session can serve interstitial ads, rewarded video, and banner inventory; the revenue model is essentially the same as any web publisher running Google Ad Manager, with a games-specific twist around session length.
At $2 ARPDAU, the platform was monetizing fine — but the lift potential was obvious. Median session length on the highest-monetizing games was around 7 minutes; on the lowest, under 90 seconds. Revenue per session varied by an order of magnitude depending on which game a user landed on first. The funnel was leaky in both directions: users who landed on a game they did not like bounced immediately, and users who liked their first game often did not discover the second one.
The two-axis frame
I started by writing down the simplest possible model: ARPDAU equals (revenue per impression) multiplied by (impressions per user per day). The first factor is mostly priced externally — your floor prices, your demand stack, your viewability. The second factor is entirely a product problem. It comes down to how many ad-worthy moments a user experiences inside a session, and how many sessions you can produce per user.
Phrased that way, the work split cleanly. The ad-ops team owned revenue per impression. I owned impressions per user per day. We agreed not to step on each other's experiments, and to share dashboards so we could spot when one optimization stole from the other.
Experiment 1: Client-side notifications
The first big intervention was a permission-gated browser notification that re-engaged users between sessions. The notification surface a user sees outside the game — in their OS tray, on a notification shade — is an underused real estate for HTML5 game networks because most publishers treat games as a session, not as an app. We treated them as an app.
The notification was not a generic "come back!" message. It was tied to the specific game the user had played most, with a teasing copy like "Your puzzle has been unbeaten for 4 days." The opt-in prompt only fired after a user had completed at least one full game session, which produced a 38% opt-in rate — well above the 5–10% we had benchmarked against generic publishers. Notifications were rate-limited to a maximum of two per week per user.
Day-7 return-visit rate increased by 11 percentage points among opted-in users. The ad inventory impact was straightforward: more sessions, same revenue per session, more revenue per user. This single change accounted for roughly a quarter of the ARPDAU lift.
Experiment 2: The Switch Game API
The second intervention was more structural. We built a small API layer that intercepted the end-of-game state and, instead of returning the user to the catalog grid (where they would scroll, get distracted, and often leave), offered a single recommended next game with a one-tap launch. The recommendation engine was deliberately simple in v1: weighted by a blend of personal play history, global completion rates, and the differential ARPDAU between the current game and candidates.
The ARPDAU weight was the controversial bit. We were explicitly nudging users toward higher-monetizing games when the personal-fit signal was weak. Two checks kept this honest: first, the recommendation never showed a game outside the user's genre preference set, regardless of revenue; second, we monitored the bounce rate on the recommended game itself, and if a candidate produced > 50% immediate bounce we deweighted it.
The Switch Game API increased average games-per-session from 1.3 to 2.4. Sessions got longer, total impressions per user climbed, and the recommendation logic naturally surfaced higher-monetizing inventory without us having to hard-sort by revenue. This experiment accounted for roughly half of the lift.
The IVT crackdown
About six months in, revenue stopped growing for two weeks. Then it dropped. Then a notice arrived from Google: a portion of our traffic had been flagged as Invalid Traffic, and a clawback was being applied.
The temptation when you get an IVT notice is to blame your traffic sources — the syndication partners, the embedded surfaces, anyone but yourself. We took the opposite approach. We ran a full root cause analysis assuming our own monetization changes were complicit, because the timing fit. The investigation surfaced two things. First, a small cohort of users were generating sessions that looked statistically identical to real users but converted on ads at impossible rates — a classic bot pattern. Second, one of our recommendation experiments was unintentionally amplifying these sessions because the bots were clicking through every Switch Game prompt, which the recommender read as engagement.
We rolled out three safeguards in eight days: a session-quality scoring signal that fed into the recommender as a negative weight, a domain-diversification policy that capped exposure to any single traffic source, and a manual review pipeline for anomalous CTR spikes. Revenue recovered within the month. Long-term, the IVT episode was probably the most important PM lesson of the year: optimization signals are not neutral. If your recommender treats engagement as a proxy for value, an attacker who can fake engagement gets to set your product strategy.
What did not work
Two ideas that sounded great on paper failed. The first was an interstitial ad shown on the transition between two games inside a session, on the theory that users had committed enough to tolerate it. They had not. Session length dropped 22% and the revenue from the interstitial did not offset the lost impressions later in the session. We pulled it.
The second was a personalized loading screen showing the user their weekly stats. It was a delightful piece of UX. It also added 1.4 seconds to perceived load time and reduced game starts by 6%. Delight is real but expensive, and on a session-economy product you have to be ruthless about latency.
Three principles that generalize
- · Decompose ARPDAU into a product factor and a market factor. Revenue per impression is mostly negotiated; impressions per user is mostly built. Most PMs underinvest in the second because the first is louder.
- · Treat session length as the upstream of everything. Longer sessions produce more impressions, more retention, and more options. Any feature that buys session length is worth paying real UX cost for; any feature that costs session length needs to clear a high bar.
- · Engagement is not value. The Invalid Traffic episode taught me that recommender signals must be triangulated against quality signals, not just behavioral ones. If your monetization machinery cannot distinguish a bot from a delighted user, an attacker will eventually set your roadmap.
Closing
The headline number — $2 to $22 — sounds dramatic. The underlying story is mundane: we found two real product levers, pulled them carefully, watched what they broke, and fixed what they broke. That is most of what monetization product management actually is. The glamorous parts (RTB stack tuning, header bidding optimizations, demand partner negotiations) get the conference talks; the unglamorous parts (session-quality scoring, recommendation guardrails, latency budgets) do the actual work.