Rewarded and interstitial ads without getting rejected

The question: "How do I show rewarded ads in a browser game without getting the game rejected?"

Ad rules are the part of portal review with the least room for interpretation. CrazyGames states it plainly: a game will be rejected without feedback if it does not follow them. The rules are also strikingly consistent across portals, because they all exist to protect the same two things: the advertiser's impression, and the player's willingness to come back.

Here is what they actually require.

The four rules every portal enforces

If you get only these right, most of the rest follows.

1. Pause the game, mute the audio, and disable input, for the whole break

Not because it looks polite. The ad plays on top of your game, in the same tab. A running game loop steals frames from the video, your music plays over the ad audio, and a keypress meant for the ad reaches your game instead. Portals treat this as mandatory for approval, not as a quality suggestion.

Two details that get missed:

Mute when the ad actually starts, not when you request one. CrazyGames calls this out specifically. Requesting an ad and muting immediately means the player sits in silence through however long the request takes, and through a failed request that never plays anything at all. Mute on the started callback.
Restore on both outcomes. Unmute and re-enable input on success and on error. A game that only restores audio in the success path goes permanently silent the first time a request goes unfilled.

Yandex requires the game paused during both the ad and the two-second warning that precedes it, and allows at most 0.33 seconds between the user's action and the ad starting.

2. Never interrupt active gameplay

Ads go at breaks the player already perceives as a break: level complete, death, a map change, the moment they choose to retry. Never mid-level, never on a timer during play, and never on a navigation button, because a player reaching for "next" is not asking for an ad and will misread the click.

CrazyGames states the rule as: an ad must not come as a surprise. Yandex requires ads only at logical pauses. Both prohibit ads in the opening minutes, before the player has any reason to care about your game.

3. A rewarded ad is opt-in, labelled, and optional

This is where most rejections happen, and every clause below is a real requirement somewhere:

The player must know an ad is coming before they commit. The button says "Watch ad for 50 gems", not "Get 50 gems". Yandex requires the trigger text to make it unambiguous.
The alternative must be equally prominent. CrazyGames requires the "continue without watching" option to be the same size, font and colour as the watch option. Making the decline path smaller, greyer or slower is a rejection reason, not a growth tactic.
The reward is a bonus, never a gate. Yandex states it directly: a rewarded reward must not affect the ability to continue playing. A level that can only be finished by watching an ad fails.
No request button on an active gameplay screen. In a racing game, the button cannot be on screen during the race.
Do not chain. CrazyGames prohibits chaining multiple ads, and specifically prohibits combining a between-levels interstitial with a rewarded ad to continue the same level.

4. Grant the reward only on the success signal

Every SDK gives you a way to distinguish "the video was watched" from "the request failed, the player closed it, or an ad blocker ate it". Reward only the first.

// The shape is the same everywhere: one callback means watched, another means
// it did not happen. Only the first grants anything.
requestRewardedAd({
  adStarted:  () => { pauseGame(); muteAudio(); disableInput(); },
  adFinished: () => { restore(); grantReward(); },
  adError:    () => { restore(); /* no reward, and the game continues */ },
});

The error path is not an edge case. Unfilled requests are routine, ad blockers are common, and a game that hangs waiting for an ad that never arrives is a worse failure than one that never showed an ad. On CrazyGames, players using an ad blocker must be able to play normally and must not be penalised.

Getting that distinction right per portal is where the work actually is, because each SDK signals it differently: a boolean resolved from a promise on one, a dedicated reward callback on another, a status constant on a third. The Yes2SDK ads module normalises all of them to one watched-or-not result, so there is a single place where the reward is granted and a single error path to keep the game moving.

The frequency rules, in numbers

You do not control ad pacing as much as you might think, and that is deliberate.

Rule	Value
CrazyGames interstitial frequency	at most one per 3 minutes, enforced by the SDK, which ignores an early request
CrazyGames first interstitial	after level 3 or 4, or once the tutorial is done and 3 to 5 minutes have been played
CrazyGames rewarded revive	around once per session, with a countdown on the revive button
Yandex rewarded video	call frequency unlimited
Yandex interstitial	platform managed; no random timers during play
Poki	the backend decides; signal every opportunity

The important consequence: on most portals, requesting an ad is not the same as showing one. Poki's documentation is explicit that not every commercial break plays an ad, and that you should signal as many opportunities as possible and let their system optimise. CrazyGames simply ignores a request that comes too early.

So the correct pattern is to signal every natural break honestly and treat the resolved callback as "the break is over, resume", whether or not anything played. Rationing your own requests to avoid annoying players does not reduce ad load; it just hides opportunities from a system that was already pacing them.

One useful side effect worth knowing: on Poki, a rewarded interaction resets the interstitial timer, so a player who just opted into an ad will not immediately be shown another.

Banners are a different set of rules

Banners are not small interstitials, and the rules barely overlap.

Never during gameplay. Menu, pause and results screens only.
Only on screens that stay open. CrazyGames requires the screen to be open at least 5 seconds on average, because that is the condition under which a banner earns anything at all.
Never overlapping game UI, at any size, and clearly distinguishable from your own content. Reserve the space in your layout rather than floating a banner over it.
Caps. At most two banners per screen on CrazyGames, with 30 seconds minimum between refreshes of the same container and 120 refreshes per size per session.
No banner render or refresh while a video ad is playing.
On Yandex, sticky banners are the only additional ad block permitted, and custom RTB banners are prohibited.

Things that quietly disqualify a build

Any third-party ad network. Every portal requires ads through its own SDK. Yandex prohibits third-party advertisers including static ad images and text; YouTube Playables prohibits off-platform advertising of any kind.
Modifying the ad block's appearance or content. Explicitly prohibited on Yandex.
Keeping a rewarded button clickable but inert when no ad is available. CrazyGames names this directly. Hide the button or show a timer.
Ads before the player has experienced the game. Named on more than one portal.
Forgetting that ad-removal purchases must actually remove ads. If you sell it, Yandex requires ads to stop.

Where the effort actually goes

None of the above is difficult. What makes it expensive is that you implement it once per portal, against a different API with different callback names, different frequency behaviour and different definitions of what counts as success, and then maintain all of them as each portal revises its rules.

That is the problem the Yes2SDK ads module exists to remove. One integration ships your HTML5 game to every supported web game platform. You write one rewarded flow and one interstitial flow against a single API that already distinguishes watched from not-watched, and the QA Inspector replays your build's event log against each portal's real ad rules, so an unmuted break or a reward granted on an error path shows up as a failed check rather than as a rejection.

The ads module reference has the API, and each supported platform's requirement sheet carries its current numbers. They are listed in the docs index, and the API overview carries the current support matrix.