Two different meanings of "optimize" — and which one matters here
It's worth being blunt about this up front, because the word gets stretched to cover two very different jobs:
- Performance optimization — reducing texture resolution, re-encoding audio at a lower bitrate, trimming draw calls, improving frame rate on low-end devices. This happens (if at all) back in the Unity project, before export. It's a design and asset-authoring decision.
- Compliance / structural optimization — making sure the exported build satisfies the specific packaging rules of the network you're submitting to: file size under the cap, correct entry file, correct click-through call, correct metadata. This happens after export, and it's a mechanical, per-network translation problem.
PlayableKit operates in the second category only. It takes a Unity Playworks/Luna export and repackages it per network — correct click API, correct asset embedding, correct file/folder naming, correct metadata — so the same creative actually meets each network's technical bar. It does not re-encode images, re-compress audio, or otherwise change the creative's visual or audio quality. If your build is heavy because of large textures or long audio clips, that's still something to address in the Unity project itself; PlayableKit's job starts after that decision has already been made.
Why a rejected creative costs more than it looks like
A single rejection rarely means "fix one line and resubmit in five minutes." In practice it means: someone gets a rejection notice (sometimes vague, sometimes days later), traces it back to which network-specific requirement was missed, patches the build by hand, re-tests it in that network's preview environment, and resubmits — then waits through another review cycle to find out if the fix actually worked. Do that across six networks with six different sets of rules, and a single creative refresh can burn a week of back-and-forth that has nothing to do with whether the ad itself is any good.
That cost compounds because the rules aren't consistent between networks. A build that's perfectly compliant for Google Ads can fail outright on AppLovin or Meta for reasons that have nothing to do with quality — it's the wrong packaging format.
The specific things that actually cause rejections
These aren't guesses — they're the real per-network requirements a build has to satisfy:
| Cause of rejection | What the network actually requires |
|---|---|
| Size overage | Every network caps creatives at 5 MB; Meta and Unity Ads specifically recommend staying near 2 MB. A build that's fine loaded from relative paths can exceed the cap once assets are properly embedded as required. |
| Wrong click-through API | Google expects a clickTag/ExitApi call, AppLovin and Unity Ads expect mraid.open(), Vungle expects window.parent.postMessage('download','*'), Mintegral expects window.install(), TikTok expects window.openAppStore() via its own Playable SDK, and Meta expects FbPlayableAd.onCTAClick(). Shipping the wrong one — or an MRAID call on a network that explicitly prohibits the MRAID format (TikTok, Meta) — is a hard rejection, not a warning. |
| Missing orientation / config metadata | Google requires an orientation meta tag in the HTML; TikTok requires a first-level config.json declaring Playable_orientation alongside a root-level index.html. |
| Wrong packaging shape | Mintegral wants the ZIP name, top-level folder, and HTML filename to all match. AppLovin, Meta, Unity Ads, and Vungle each require a single self-contained HTML file with zero external requests — no relative-path assets, no external scripts or fonts. |
None of these are subjective creative judgments. They're binary pass/fail checks, and a build built for one network's rules will fail a different network's rules by default — because the rules genuinely conflict (an MRAID call that's required on one network is prohibited on another).
How validating before submission actually reduces rejection cycles
The fix isn't to guess harder — it's to check the specific things that get checked, before a network's review does it for you:
- Start with the raw export. PlayableKit's free Playable Ad Validator checks your raw Playworks/Luna export ZIP for a valid entry file, missing engine/cache assets, a recognizable click-through hook, and JavaScript syntax errors in inline scripts — the structural problems that would break every downstream conversion, before you've spent time packaging for any specific network.
- Check real per-network numbers, not a guess. Raw upload size doesn't reliably predict pass/fail — a converted single-HTML output can end up smaller (unused cache generations dropped) or larger (assets base64/base122-embedded where they weren't before) than the source ZIP. The free Playable Size Checker runs your export through PlayableKit's real conversion pipeline for every supported network and reports the actual resulting size against that network's actual limit — Google, Meta, AppLovin, Mintegral, TikTok, Unity Ads, Vungle.
- Convert per network's actual rules, not a generic export. Once you know the build is structurally sound, PlayableKit applies each network's correct click API, asset embedding, and package shape automatically from the same source export — so the version you submit to AppLovin was built to AppLovin's rules, not adapted after the fact from a Google-shaped build.
If file size itself is the recurring problem — not the wiring or packaging, but the byte count — see how encoding overhead and asset weight actually break down on Playable Ad Compression. And if you're comparing this whole per-network conversion step against doing it by hand, Playable Ad Converter walks through what the automated version replaces.
The bottom line
"Optimizing" a playable ad for ad-network review means matching each network's actual technical requirements — size, click API, metadata, package shape — well enough to clear review on the first attempt. It is not about making the game run faster or look better; that work happens earlier, in the Unity project. Treating the two as the same problem is exactly what leads teams to spend review cycles debugging something that was never a performance issue in the first place.