Liftoff playable ads: requirements, formats & common errors

What Liftoff Monetize actually is

Liftoff is a mobile growth advertising company best known for user-acquisition and re-engagement tooling. In 2021 it acquired Vungle, whose mobile ad network — the mediation and demand-side business that served playable and video creatives across a large publisher footprint — became the product now branded Liftoff Monetize. If you came here searching "Liftoff" rather than "Vungle," this is almost certainly the network you're looking for: Liftoff doesn't run a second, separate playable-ad network alongside it.

Liftoff's own positioning leans on that combination rather than hiding it. The pitch is a single growth platform spanning both sides of the business — Liftoff Accelerate for user acquisition and Liftoff Monetize for in-app ad monetization — so a publisher can run both acquisition and monetization through one relationship instead of stitching together separate vendors. Vungle's SDK, its publisher network, and its ad-serving infrastructure didn't get rebuilt from scratch to make that happen; they became the Monetize half of a broader platform under new branding and a new go-to-market story. That's why the creative spec — the part that actually determines whether your HTML file gets approved — carried over largely unchanged from what Vungle shipped before the acquisition.

Inside PlayableKit, this is reflected directly in the network picker: the build target is labeled Vungle (Liftoff), one integration with both names attached, because that's how the underlying spec is actually versioned and served.

Technical requirements

These are the concrete rules a playable has to satisfy for a Liftoff Monetize placement, as encoded in PlayableKit's network spec for this target:

• Single self-contained HTML file. One document, no companion asset folders, no ZIP wrapper — everything the ad needs has to live inside one .html file.
• 5 MB maximum. That cap applies to the finished file — markup, script, and every embedded asset combined — not to your pre-encoding source assets.
• All assets embedded, no external requests. Images, audio, fonts, and any library code must be inlined as data URIs or encoded blobs decoded at runtime. A hosted image, a CDN-loaded font, or an analytics beacon firing to an external domain is grounds for rejection, not just a style violation.
• Primary CTA fires window.parent.postMessage('download','*'). That call is what tells the Liftoff container the user tapped through to the store listing. mraid.open(url) is the fallback path for environments that expect MRAID's click-through instead of postMessage.
• No audio before user interaction. Sound must wait for a tap or click; autoplay audio on load is not allowed.

Wiring only one of the two CTA paths is the single most common reason a creative that plays perfectly in a browser still fails in review — some inventory expects postMessage, some expects the MRAID fallback, and a build that only implements one of them will pass in some placements and silently fail to register a click in others.

Accepted formats & size limits

Liftoff Monetize accepts a single HTML5 file as the entire creative — there's no separate video or static-image playable spec here, just the one HTML format, and no ZIP container to unpack. PlayableKit's internal entry file for this target is named vungle.html. The 5 MB ceiling is a hard cap, not a soft recommendation, and it's worth measuring the file after encoding rather than before: base64-encoding binary assets like images and audio typically inflates their size by roughly a third, so a source build that looks comfortably under 5 MB as separate files can land right at, or past, the limit once everything is inlined into one document.

Common upload errors

• Multiple files or a ZIP instead of one HTML document. Liftoff Monetize wants a single file — anything packaged as a folder structure or archive gets rejected before a human even looks at the creative.
• External asset references. A relative path to an image, a CDN font link, or any fetch/XHR call to an outside domain violates the no-external-requests rule, even if the asset itself is small.
• Only one CTA path wired. Implementing postMessage without the MRAID fallback (or vice versa) leaves the ad non-functional in whatever environment expects the other call.
• Autoplay audio on load. Sound firing before any tap or click is a straightforward compliance failure, not a judgment call.
• Oversized file after encoding. Checking size against the raw asset folder instead of the final single-file output is a common way teams miss the 5 MB cap until the network flags it.

Best practices

Wire both CTA calls every time — postMessage('download','*') as primary, mraid.open(url) as fallback — rather than betting on which one a given placement expects. Test the build with no network connection at all; if anything breaks or fails to load, there's an external request hiding somewhere that needs to be inlined instead. And measure the actual output file, post-encoding, against the 5 MB cap before you submit rather than after a rejection tells you it's too big.

Exporting a compliant build with PlayableKit

PlayableKit supports Liftoff Monetize today under the Vungle (Liftoff) build target — this isn't a roadmap item. Upload your existing playable export, select that target alongside whichever other networks you're shipping to (Google Ads, Meta, AppLovin, Mintegral, TikTok, Unity Ads), and PlayableKit produces a vungle.html file with every asset embedded, both CTA paths wired, and the result checked against the 5 MB cap automatically. Vungle/Liftoff builds are available on the Studio plan and above; the entry-level Starter plan covers Google, Meta, AppLovin, and Unity Ads only, so it's worth confirming current plan coverage on the pricing page before you plan a release around it.