Google's Game Ad Formats Are Application-Only. Model Your Portal Revenue for a No.

The interstitial and rewarded formats a web games portal earns most from sit behind an AdSense application Google does not guarantee approval on. Plan for a no.

Revenue models for games portals get built in the wrong order. Someone picks an eCPM, multiplies it by projected sessions, adds a fill-rate haircut, and closes the spreadsheet. Nobody checks whether the portal is permitted to serve the ad formats that model assumes.

Often it is not. The two formats that carry a game session — the full-screen break between rounds, and the opt-in rewarded video — are not general-purpose AdSense units you switch on next to your display tags. They come from a separate, application-gated product, and Google's own documentation says in plain words that you might not get in.

🚪 Two Sentences in Google's Documentation Decide the Model

Google's monetization product for browser games is H5 Games Ads, served through the Ad Placement API. The sign-up page is short, and two lines on it do all the work. First, you need an approved AdSense account to show ads in your H5 games. Second, and this is the one that belongs in the revenue model: "Account approval is not guaranteed as it is subject to partner eligibility." Access is requested through an application form, and the criteria behind "partner eligibility" are not published.

The same page asks approved publishers to comply with a limited-scope policy exemption for full-screen ads. Read that word again. Exemption. Full-screen ads in a game are not something AdSense ordinarily permits; H5 Games Ads is the carve-out that makes them legal for the publishers who get accepted. If you are not accepted, you are not looking at a lower eCPM. You are looking at a format you are not allowed to run.

What approval actually buys, per Google's AdSense Help article on the product: interstitials at natural breaks in play, rewarded ads the player opts into for an in-game prize, and both carrying display as well as TrueView and Bumper video demand. Two details in that article matter more than the format list.

• The formats support a game embedded directly into your page and iframed onto a different site. That is the licensing case, and it is explicitly covered.
• App integration through AdMob, for a game running inside a mobile app's webview, is Android only.

That second line quietly deletes a business case. If your roadmap has a portal wrapped as an iOS app monetized by the same ad stack as the web build, the documented path does not exist. Find that out now rather than in sprint eleven.

⛔ What You Are Allowed to Show Without the Exemption

Assume the application comes back no, or takes a quarter. What survives?

Display around the game frame survives. Rewarded survives in principle — opt-in formats sit outside the restrictions Google applies to interrupting ads, because the player chose them. What does not survive is the unprompted full-screen break, which is precisely the unit most portal revenue models lean on.

The constraints on full-screen ads are worth knowing even after approval, because they are design constraints, not paperwork:

• The ad must not be confusable with the normal operation of the page — nothing before the game has opened, nothing after it has closed.
• Interstitials fire at natural breaks, between levels or rounds, not at arbitrary moments in the journey.
• Non-opt-in interstitials must be closeable or skippable after 15 seconds.

Those rules dictate where in a licensed build an ad break can go. Which raises the question nobody asks the licensor.

🖼️ The Ad Call Inside the iframe May Not Be Yours

A licensed game arrives as a build, and a build can contain an ad SDK. When it does, the break that interrupts your player pays whoever's network IDs are compiled into it. That is not necessarily you.

There are three shapes in the market, and the licence decides which one you have:

1. A clean build. No ad calls. You host it, you place the ad breaks, you keep the revenue. This is what most buyers assume they are getting.
2. A build with the licensor's tags in it. The game monetizes on their account. You may be on a revenue share, you may be on nothing, and either way the eCPM you negotiated your model around is theirs to influence, not yours.
3. An embed link. The game never leaves the licensor's servers. Your page holds an iframe pointing at their domain. Every ad in it is served under their stack, their consent flow, and their seller relationships.

None of the three is illegitimate. Shape three is the standard deal on most free games feeds and it is a perfectly reasonable way to fill a catalogue. The failure is signing shape two or three while modelling revenue as though you had shape one. That gap does not show up until the first month's reporting, by which point the traffic has already been spent.

🗂️ ads.txt Is Fetched Per Domain, and the Games Are on Someone's Domain

Programmatic buyers verify who is authorized to sell a given piece of inventory by reading the ads.txt file on the domain that inventory is attributed to. If the game is served from the licensor's domain inside your iframe, your file is not the one being consulted. Their sellers are the authorized sellers. You are hosting the surface and they are selling the impression.

The specification has language for exactly this ambiguity. In 2022 the IAB Tech Lab added ownerdomain and managerdomain to ads.txt — the first naming the business that owns the site, the second declaring the primary or exclusive monetization partner for that site's inventory. Tech Lab's stated reason for adding them was that seller domains had been hard to validate programmatically and were frequently mismatched. Syndicated game content is a textbook generator of exactly that mismatch.

The due-diligence version of this takes four minutes. Get the URL the game is actually served from, strip it to the root domain, and open its ads.txt. You now know who sells that inventory, and it is a factual answer rather than a sales answer.

🧩 One Tag, a Managed Partner, or Your Own Wrapper

Assume you have established that the inventory is genuinely yours. Three architectures are available, and they differ far more in operating cost than in ceiling.

A single tag

AdSense display, plus H5 Games Ads if the application lands. Near-zero ongoing ops. One source of demand, which means one entity setting your price. Entirely defensible for a portal under real scale — the alternative costs more to run than it returns.

A managed gaming partner

Several firms sell managed ad stacks specifically into web and gaming publishers — Venatus, which acquired the browser-game network AdinPlay in 2023, along with Playwire, Snigel and others. They typically operate header bidding on your behalf and take a share. You are buying ad operations rather than hiring it. Treat the uplift percentages in their marketing as directional: those are vendor-published figures about their own product, and no independent body audits them.

Your own wrapper

Prebid, the open-source header-bidding wrapper, running in-house on top of an ad server. Maximum control and a permanent line in the org chart: bidder onboarding, timeout tuning, discrepancy reconciliation, consent plumbing, and someone who owns all of it on a Friday night.

The deciding variable is headcount, not revenue. And there is a games-specific cost the generic publisher advice misses — every wrapper adds latency before the first ad renders, on a page that is simultaneously downloading and starting a game. On a portal, ad-stack latency competes directly with time-to-first-playable-frame. A stack that lifts eCPM 15% and pushes the game start out by two seconds may well be a net loss, and it will show up in session metrics rather than in the ad report, which is why it usually goes undiagnosed.

⚖️ The Layer Underneath Is Under a Court Order

One more input, and it is genuinely outside your control. On 17 April 2025 the court in US v. Google ruled on liability, finding that Google had monopolized the open-web display publisher ad server market and the open-web display ad exchange market. The remedies phase ran from September 2025, with closing arguments held on 21 November 2025. As of August 2026 the remedies opinion has not issued, and appeals are expected to follow whatever does.

The DOJ asked for divestiture of AdX, possibly the ad server as well, and open-sourced auction logic. Google offered behavioral commitments instead — including a server-to-server integration between its ad server and Prebid, so publishers could reach its exchange through an auction Google does not control.

Do not try to trade on the outcome. Notice instead what both sides' proposals have in common: more demand routed through auctions that are not Google's. Google's own remedy proposal names Prebid. If your entire path to demand is a single Google integration with no second route, you are exposed to a decision being made by a federal judge on a timetable nobody has published. Building a second demand path is not a prediction. It is the cheap version of insurance.

🚫 Five Ways Operators Get the Ad Stack Wrong

• Modelling interstitial revenue before submitting the application. The format is gated and the gate has no published criteria. Build the base case on display and rewarded, and treat approval as upside.
• Assuming the iframe is theirs. Ask which domain serves the file. Everything downstream — ads.txt, consent, the ad account the money lands in — follows from that one answer.
• Buying a managed partner and hiring ad ops anyway. Pick one. Paying a revenue share for a service you also staff internally is the most common way a portal's contribution margin quietly disappears.
• Treating latency as an engineering concern. The ad stack and the game load on the same page and compete for the same seconds. Measure time-to-first-playable-frame before and after any stack change, every time.
• Running one demand path. Not because Google is unreliable, but because the plumbing between ad servers and exchanges is currently a live question in a US federal court.

📋 Six Questions to Settle Before You Model a Cent

1. Which domain serves the game file — ours or yours?
2. Does the build contain ad calls, and whose network IDs are in it?
3. Can we get a clean build with no ad calls, and what does that cost?
4. Does the licence permit us to insert our own ad breaks into the build?
5. Who is listed in the ads.txt of the serving domain?
6. Does anything in the licence restrict which ad partners we may use, or survive our switching them?

Six questions, answerable in one email. Every one of them changes a number in the model.

🎮 Where a Licensed Catalogue Fits

Forestry Games has licensed games since 2017 and carries a catalogue of 1,049 HTML5 and Android titles, alongside in-house HTML5 development and white-label portal builds. The questions above are the ones worth putting to any licensor, including us — the useful version of a licensing conversation is the one where hosting, ad calls and build cleanliness get written down before the catalogue is chosen, not after. The catalogue, the HTML5 titles and the monetization side are all worth walking through in that order.

🧭 What to Settle This Quarter

Submit the H5 Games Ads application this week if you have not — it costs an hour and the answer changes your forecast. While it is pending, rebuild the revenue model on display and rewarded only, and keep the interstitial line as a separate, clearly labelled upside case rather than folded into the base.

Then audit what you already licensed. For every title live on your portal, record the serving domain and whether the build carries ad calls. If more of your catalogue turns out to be monetized by someone else than you expected, that is not a renegotiation — it is a pricing input for the next renewal, and you now have the evidence to use it.