Why Playable Ads Get Rejected — And the QA Checklist That Prevents It

A playable rejection costs more than the resubmission. It costs the campaign start date, and it usually arrives days after the creative was finished, when the team has moved on. The frustrating part is that the same handful of causes account for most rejections across every network — and every one of them is catchable in a ten-minute pass before upload.

1. The click uses the wrong call

The most common technical rejection there is. Each network expects its own click mechanism: mraid.open(url) on MRAID networks such as Unity, ironSource, AppLovin, Chartboost, Vungle and InMobi; ExitApi.exit() on Google; FbPlayableAd.onCTAClick() on Meta; window.install() on Mintegral. A creative wired to window.open works flawlessly in your desktop browser and fails inside the SDK, which is precisely why it survives internal QA and dies at review.

2. Something is fetched at runtime

External requests are the second big cause. A font loaded from Google Fonts, an image left on your CDN, an analytics beacon, a stray script tag. Reviewers check for these automatically. Everything has to be embedded in the package, with the single common exception of Google's own exitapi.js on Google Ads campaigns.

3. It is over that network's size limit

Limits vary by network, and this is where teams get caught assuming a single figure applies everywhere. Several networks cap well below the commonly-quoted 5 MB, so a creative built to the loosest limit will be rejected by the stricter ones. Check the limit for each network you are actually submitting to, and treat the strictest as your build target if you are shipping one creative to several.

4. The packaging shape is wrong

Some networks want one self-contained HTML file. Others want a ZIP arranged their way — occasionally specifying which file must sit at the root. Submitting a single HTML where a ZIP is expected, or a ZIP with the entry file one directory too deep, is a straight rejection with a confusing error message.

5. The creative does not represent the app

This one is editorial rather than technical, and it is enforced most visibly by Google: reviewers check whether the playable reflects the app being advertised. Gameplay, visual style and general feel should resemble what the user gets after installing. A mini-game bearing no relationship to the product is the classic cause, and rebuilding it is expensive — which is why it is worth settling before production, not after.

6. Missing lifecycle signals

Several networks expect to be told when the playable has ended, and some expect a ready or viewability handshake before the content starts. Missing these does not always break the ad visibly, which is why they slip through: the creative plays, the reviewer's tooling reports an incomplete integration, and the notice is cryptic.

7. Store links that point somewhere unexpected

A link to the wrong regional storefront, a staging URL left in place, or a bundle ID mismatch between the creative and the campaign. Automated checks catch broken links; they do not catch a working link to the wrong listing.

The pre-submission checklist

1. Open the exported file on a real iOS device and a real Android device. Emulators miss touch, audio and performance problems.
2. Record the network tab through a full playthrough. Zero external requests, other than Google's exitapi.js on Google campaigns.
3. Confirm the file or package is under the limit for each network you are submitting to — not the highest limit you have read.
4. Confirm the packaging shape matches each network's requirement, including where the entry file sits.
5. Tap the CTA on both platforms and confirm the correct store listing opens for the correct territory.
6. Play the creative to completion and confirm the end card appears and is tappable.
7. Check the creative visually represents the product being advertised.
8. Test with sound off — most impressions start muted — and confirm it is still understandable.
9. Validate through the network's own tool where one exists, such as Google's h5validator.

What to do when you are rejected anyway

Rejection notices are frequently terse and occasionally misleading — a generic "does not meet technical requirements" can mean any of the causes above. A method that saves time:

1. Read the notice for a named API or file. If it mentions a specific call, packaging or size, that is the actual cause and you can fix it directly.
2. If it is generic, work the checklist in order of likelihood: click call, external requests, size, packaging. Those four cover the large majority.
3. Reproduce in the network's own preview or validator rather than your browser. The failure usually only appears inside the SDK, which is why it reached review in the first place.
4. Fix one thing per resubmission where you can. Changing four things and passing tells you nothing about which was wrong, and the next creative will repeat the same mistake.
5. Keep a note per network of what has been rejected before. Most teams hit the same two or three causes repeatedly, and a short internal list is worth more than any general guide.

The rejections that are not technical

A separate class of rejection concerns content rather than integration, and these cost more because the fix is creative rework rather than a config change. The recurring ones: gameplay that misrepresents the app, misleading claims about rewards or difficulty, fake interface elements such as imitation system dialogs or false close buttons, and age-inappropriate content for the campaign's rating. Networks vary in how strictly they enforce these, but a creative that fails one usually fails several, so it is worth resolving before submitting anywhere.