What a playable ad actually is

Most ad formats are passive: a static image, or a video that plays start to finish while the viewer watches. A playable ad is different — it's a working, scaled-down slice of the real game or app, embedded in the ad slot so the viewer can interact with it before deciding whether to install anything.

A typical playable gives you a few seconds of a real mechanic — match three tiles, guide a ball through a maze, pop a stack of blocks — followed by a call-to-action that sends you to the app store or advertiser's page. It's not footage of gameplay; it's the gameplay itself, running live in miniature, inside the space a banner or video would normally occupy.

How it works technically

Under the hood, a playable ad is a self-contained bundle of HTML, CSS, and JavaScript — the same technologies behind any interactive web page, just packaged to run inside an ad container instead of a browser tab. The host app (a game, a news app, a social feed — wherever the ad slot lives) renders that bundle in a WebView, and the playable's own JS drives everything: input handling, animation, simple game logic, and the transition to a call-to-action screen.

Because the playable runs inside someone else's app rather than a normal web page, it needs a way to talk to the host: to report itself as loaded and ready, to learn the ad slot's dimensions, and — critically — to tell the host "the user tapped, open the store listing now." That communication mostly happens through MRAID (Mobile Rich Media Ad Interface Definitions), an IAB-standard JavaScript API most ad SDKs inject into the WebView, or through a network's own proprietary playable SDK layered on top of or instead of MRAID.

In practice this means every asset the playable needs — images, audio, fonts, sometimes an entire engine runtime if it was exported from a game engine — has to ship inside that one bundle. Most networks don't let a playable reach the open internet once it's loaded, so assets a normal web page would fetch on demand get inlined as base64 (or more compact base122) data directly in the HTML, decoded at runtime instead of downloaded.

Playables get produced a few ways: hand-built in HTML/CSS/JS from scratch, assembled with a dedicated playable-ad builder, or exported from a game engine's own playable tooling (Unity's Playworks/Luna is one example) that converts a real game scene into this same kind of self-contained HTML5 bundle. Whichever path produced it, the result is the same shape: one interactive unit that runs standalone, with no server behind it, inside someone else's app.

Why advertisers use them

A video ad measures attention — did someone watch to the end. A playable measures something closer to intent — did someone engage with the mechanic long enough to reach the call-to-action. Someone who plays a few rounds of a match-three demo before tapping "install" has effectively previewed the game and self-selected as a plausible fit, in a way a passive viewer hasn't.

  • Higher engagement. Interaction demands attention in a way passive viewing doesn't — a viewer has to do something to move forward.
  • Better-qualified installs. Having sampled the real mechanic, playable-driven installs tend to retain better than installs from a format that never showed real gameplay.
  • Format novelty. Among a feed of static and video ads, something the viewer can touch and manipulate tends to stand out.

None of that makes playables strictly better than video or static — they typically cost more to produce and test — but for game and app install campaigns, they're a well-established part of the format mix precisely because they measure a different, often stronger, signal.

The technical constraints that make them tricky

The same properties that make a playable powerful also make it fussy to ship correctly, because every major ad network enforces its own variation of the same underlying rules:

  • Size limits. Most networks cap a playable at 5 MB, with several recommending closer to 2 MB. Once every asset is embedded rather than loaded on demand, a build that felt lightweight during development can push past the limit fast.
  • No external requests. Networks like AppLovin, Meta, TikTok, Unity Ads, and Vungle prohibit the creative from reaching any external server once loaded — no CDN-hosted images, no analytics pings, no external fonts. Everything has to be self-contained in the package.
  • Per-network click-through APIs. There is no universal "open the app store" call. Google Ads expects a clickTag variable plus its own ExitApi; AppLovin, Unity Ads, and Mintegral rely on MRAID's mraid.open(); Vungle listens for window.parent.postMessage('download','*'); Mintegral separately expects window.install(); TikTok expects window.openAppStore() from its own Playable SDK; Meta expects FbPlayableAd.onCTAClick(). Wiring the wrong one in is a common cause of a rejected creative.
  • Package shape. Even the container varies — some networks want a single flat HTML file with everything inlined, others want a ZIP with a specific entry-file name, a matching folder structure, or an accompanying config.json declaring orientation.

None of these constraints are exotic individually. What makes multi-network playable production time-consuming is that they're all slightly different across networks, and a build fully compliant for one network is often not compliant for the next without rework.

Where a tool like PlayableKit fits

This is the layer most teams eventually automate. A game engine's playable export tool — Unity Playworks/Luna, for instance — is good at producing one working HTML5 build from a game scene, but it isn't trying to solve per-network packaging. PlayableKit picks up from that single export and repackages it for each target network: applying the correct click-through API, inlining assets where required, matching the expected file and folder naming, and checking the result against that network's size and structure rules before it ships. The playable itself doesn't change — only how it's wrapped for each destination.

Curious how this looks with a real Unity export? See how it works specifically for Unity Playworks/Luna builds, or how a general HTML5 playable converter handles the same problem for playables built outside Unity.