Pangle & Liftoff Playable Ad Specs: Packaging and Submission

Pangle and Liftoff both carry meaningful playable volume, and both are under-documented in general guides that stop at Google, Meta and Unity. They also share a characteristic that catches teams out: the failures are almost never about your creative and almost always about how the archive is assembled. This guide covers the packaging rules that decide acceptance.

Pangle: the packaging is the spec

Pangle is ByteDance's ad network, sitting alongside TikTok in the same family, and its playable requirements are specific in ways that are easy to get subtly wrong.

• Submit a .zip, not a loose HTML file.
• The main HTML file must sit in the first-level directory and must be named index.html. Not main.html, not ad.html, and not one folder deep.
• The package is expected to include config.json alongside index.html for correct rendering.
• Compressed size under 5 MB.
• No JS redirects anywhere in the creative.
• No HTTP requests at runtime — everything embedded.
• The click-to-jump operation is handled through the network's own front-end SDK rather than a raw browser call.

Why the no-request rule is enforced so strictly

The prohibition on HTTP requests and JS redirects is not bureaucratic. A creative that fetches at runtime can change after review, which makes the review meaningless, and it introduces latency into a format measured in seconds. Networks in the ByteDance family enforce this aggressively, and automated checks catch it reliably — including requests you did not intend, such as a font that was linked rather than embedded, or an analytics call left in from a test build.

Liftoff

Liftoff is a programmatic DSP with machine-learning-driven optimisation, and it now includes Vungle following their combination — which matters practically, because Vungle's playable requirements are the ones you are likely to encounter under the Liftoff name.

Liftoff's own click handling does not take a URL from your creative in the way a plain MRAID network does, so a per-button custom destination cannot travel there. If your creative relies on sending different users to different destinations, that is a network-level constraint rather than something to solve in the creative.

• ZIP packaging, with the entry file at the archive root — the same trap as Pangle.
• Fully self-contained; no runtime fetching.
• Because Liftoff optimises on machine learning, creative variety matters more than on a manually-bid network. A single creative gives the model very little to work with.

What ML-driven buying means for your creative plan

This is the strategic difference between these networks and a manually-managed one. On a DSP that optimises with machine learning, the model is looking for signal about which users respond to which creative. Supplying one playable is like giving a search algorithm one keyword — it will do something, but you have removed most of what it optimises on.

In practice that means shipping a small set of genuinely different creatives rather than one polished creative and a set of near-identical colour variants. Different mechanic, different opening, different end card framing. Variants that differ only cosmetically look like one creative to the model.

A shared submission checklist

1. Build to the strictest size ceiling among your target networks, not the most generous.
2. Extract every archive fresh into an empty folder and confirm the entry file is at the root, correctly named.
3. Include any per-network manifest the network expects alongside the entry file.
4. Record the browser network tab through a complete playthrough — zero external requests.
5. Grep the built file for redirect patterns and stray script tags left from development.
6. Test on real iOS and Android devices, not emulators.
7. Submit to the strictest network first; passing there predicts the rest.

Fitting them into a network mix

Pangle pairs naturally with TikTok, since they share an ecosystem and often an audience strategy. Liftoff sits alongside Moloco as the programmatic, ML-optimised half of a buying mix, contrasted with the mediation-heavy Unity, ironSource and AppLovin side. Running one creative across all of them is reasonable — provided it was built to the tightest constraint in the set and packaged correctly for each.

Diagnosing a rejection on either network

Rejection notices from both are terse, and the wording rarely names the real cause. A diagnostic order that saves time:

1. Extract the submitted archive into an empty folder. If index.html is not the first thing you see, correctly named, stop — that is almost certainly it.
2. Check for a missing manifest file where the network expects one alongside the entry file.
3. Search the built HTML for http:// and https:// outside of comments. Anything not embedded is a request, including a linked font or a leftover analytics endpoint.
4. Search for redirect patterns — location assignment, meta refresh, window.open — which are prohibited outright rather than merely discouraged.
5. Check the compressed size against the ceiling, not the uncompressed size.
6. Only then look at the creative itself.

The ordering matters because the first three causes account for the large majority of rejections on these two networks, and each takes under a minute to check. Teams frequently rebuild a creative in response to a rejection that was actually an archive structure problem.

What to keep in your own notes

Published specs and what review actually enforces are not always in step, and both move. A short internal record — what each network accepted, what it rejected and with what wording, and the date — becomes more reliable than any external documentation within a couple of campaigns. It is also the fastest way to onboard whoever inherits the account.