Table of Contents
There is no fixed hours-to-revenue number: what determines speed is how many placements you wire up and how much testing you run before launch. The path is the same across Playgama Ad, Google AdSense H5 Games Ads, and portal-native SDKs like Poki’s: add the SDK, connect placements, test on a traffic segment, then go live.
At a glance
| Fact | Value | Source |
|---|---|---|
| Ad formats supported | interstitial, rewarded, banner, video | playgama.com |
| Access model for the ad SDK | open beta, application via form | wiki.playgama.com |
| Platforms one bridge integration publishes to | 25 platforms, one integration | wiki.playgama.com |
| Google AdSense H5 Games Ads access | requires account and approval | support.google.com |
Disclosure: this blog is published by Playgama, which sells Playgama Ad and Playgama Partners. Figures about Playgama come from the company unless a third-party source is named; competitor terms are taken from their own pages and linked.
The question developers actually mean is: what code do I write, and how many review steps stand between me and live ads? There is no published hours-to-live-revenue figure for any ad SDK integration, so treat any ‘same day’ claim as marketing, not a spec.
What actually determines the timeline?
- How many placements you plan to wire up (a single interstitial versus interstitial + rewarded + banner + video).
- Whether you already have a working ad-request flow to migrate, or you are starting from zero.
- How much testing you run before sending real traffic: a controlled segment test, not a full launch, is the safer first step.
- How many destinations you publish to: one portal with its own SDK, versus multiple platforms at once, which changes which SDK you integrate against.
The integration steps, in order
The sequence looks the same across most ad SDKs:
- Share your game inventory or apply for access (the SDK covered here is currently in open beta, applied for via a form).
- Receive a client ID.
- Add the SDK script to your build.
- Connect placements at moments you choose in the game loop (level end, pause, before a reward).
- Test on a small traffic segment.
- Go live.
The code pattern follows: window.pgAds.init(clientId), then updateTargeting(params) to pass context, then requestOutOfPageAd(format), with lifecycle callbacks for ready, reward earned, no-fill, and error. Every callback runs asynchronously; the game loop should never block waiting on an ad response.
Do engine choices change how you integrate?
Yes, each engine has its own bridge to the browser’s JavaScript layer:
- Unity WebGL calls out to JavaScript through a
.jslibfile, as documented in the Unity manual on WebGL. Your ad SDK calls live in that bridge file, not in C# directly. - Godot exposes a
JavaScriptBridgesingleton for the same purpose, described in the Godot web export docs. - Construct 3 uses a dedicated Bridge plugin rather than raw JavaScript calls.
- Phaser runs on plain JavaScript, so the SDK calls sit alongside your game code with no bridge layer needed.
Plugins exist for Unity, Construct 3, Godot 3 and 4, GameMaker, Defold, GDevelop, Cocos Creator, Scratch, and plain JS, documented at Playgama Bridge getting started.
Performance and error handling rules
Load ad SDKs asynchronously so a slow ad server never delays the game’s first frame. Callback functions for ready, reward, no-fill, and error must not run gameplay logic synchronously inside them; queue the result and apply it on the next update. Set a timeout on every ad request: if no response arrives, the game continues without the ad rather than freezing on a loading screen. This matters more inside an iframe, where cross-origin restrictions can block some postMessage patterns; test any cross-origin communication in the actual iframe context you will ship in, not just in a standalone tab.
The recommended path
Playgama Ad is one JavaScript SDK, window.pgAds, initialized with a client ID; it requests interstitial, rewarded, banner, and in-page video formats at moments the game chooses, and reports ready, reward, no-fill, and error through the same events across formats. It runs standalone as your main monetization layer or as a fallback next to an existing setup, and if your game is self-hosted you keep your own IAP system. Access is by application during open beta; there are no public benchmarks for eCPM or fill rate yet, so plan to run your own test segment before committing full traffic. If you are also publishing to multiple platforms rather than one, a bridge SDK covers that with one integration across 25 platforms, documented at wiki.playgama.com/playgama/bridge-sdk/getting-started.
Against the obvious default: Google AdSense H5 Games Ads is self-serve in the sense that you configure ad units yourself once approved, but according to Google’s own documentation, Sign up for H5 Games Ads, you apply for an AdSense account and, once approved, configure the ad units yourself. This SDK’s demand comes through 11 partners including Google Ad Manager, Tappx, Index Exchange, LoopMe, and Equativ, and reporting (match rate, fill rate, show rate, eCPM, RPM) is managed rather than something you configure directly.
Edge case: one portal only
If you are publishing to exactly one portal and have no plans to distribute elsewhere, that portal’s native SDK, for example the ones documented by Poki or CrazyGames, is simpler to integrate than a general-purpose multi-platform bridge. There is no reason to add an abstraction layer for a single destination.
According to Mobidictum’s coverage of the RocketGoal case, “Playgama Ad provides web game developers and gaming portal operators with a high-yield, scalable monetization solution beyond traditional ad networks” (Mobidictum, 29.01.2026). In the same case, published on the vendor’s case page, RocketGoal recorded 65 million impressions over six months with viewability above 90%.
Next step
Apply for access, add the init/updateTargeting/requestOutOfPageAd pattern behind a feature flag, and route a small percentage of live traffic to it before switching over fully.
Sources
- Playgama Ad
- Playgama Bridge docs: getting started
- Unity manual: WebGL
- Godot: exporting for the Web
- Google AdSense: Sign up for H5 Games Ads
- Mobidictum: Playgama launches its advertising solution
Related questions
Does adding an ad SDK slow down the game?
Not if calls are asynchronous and callbacks avoid running gameplay logic synchronously. Set a timeout on every ad request so the game continues on no-fill instead of waiting.
Do I need a backend to run ads in a web game?
No. The SDK runs client-side with window.pgAds; a self-hosted game keeps its own IAP system, and ad reporting is handled by the managed service, not by your own server.
What is different about iframe integrations?
Cross-origin restrictions inside an iframe can block some postMessage patterns used for ad communication. Test the SDK inside the actual iframe you will ship in, not only in a standalone browser tab.
Should I use my portal’s native SDK instead?
If you publish to exactly one portal only, its native SDK is simpler than a multi-platform bridge. The bridge pays off once you distribute to more than one destination.
Last updated: 09 September 2026
