A Playable Ad Spec Sheet You Can Hand to Any Developer

A playable ad is a single self-contained HTML file that runs inside an ad network's player. It has three parts: a hook, a short interactive section, and an end card. Size limits are strict, external requests are usually blocked, and the network's own API handles the install click.

Why this matters

Playables convert well because the player has already tried the mechanic before installing. They also filter out people who would have bounced, which improves the quality of the installs you buy.

They fail for boring reasons. A file that is too large, an external font request that is blocked, or a missing network call means the creative never runs.

Handing a developer a complete specification removes most of that risk in one document.

What a playable ad is and where it runs

A playable is a miniature game delivered as one file, played inside another app.

It runs in an ad network's web view, which is a restricted environment. Most networks require everything to be inlined into a single HTML file: scripts, styles, images, and audio all embedded rather than fetched.

The install button is not yours. The network provides a call that opens the store, and using anything else means the click does not track.

Treat the playable as a very small game with a very large set of constraints, not as a cut-down version of your build.

Size limits by network

Limits vary and change, so confirm current numbers with each network before building. The practical planning ranges are consistent enough to work with.

Three techniques do most of the work.

• Reduce the palette and use compressed formats. Playables tolerate lower image quality than games do.
• Use vector or generated shapes where the art allows, since geometry is nearly free compared to bitmaps.
• Ship one hero asset and reuse it, rather than a full sprite set.

Assume the ad starts muted. Any information carried only by sound is information the player will not receive.

Structure: hook, play, end card

Three sections, and each has a job.

The hook, roughly the first two seconds. Something moves and the goal becomes clear. Many networks auto-play a short animation before interaction is allowed, so make that animation carry the concept.

The play, roughly five to fifteen seconds. One mechanic, one or two interactions, engineered so the player succeeds. This is not the place for difficulty. A player who fails a playable does not install.

The end card. Appears after success or after a time limit. It shows the game name, the icon, and one clear install button. It should also allow a replay, because a second play measurably improves intent.

Two design rules matter more than the rest.

1. Show the hand. An animated finger or tap indicator raises interaction rates substantially, because many viewers do not realise the ad is interactive.
2. Let them win. The purpose is to leave the player wanting to continue, not to test them.

Technical constraints

Hand this list to whoever builds it.

• Single file output. Everything inlined, no external requests of any kind.
• No external fonts. Use a system font stack or convert text to shapes.
• No cookies or local storage, which are often unavailable.
• Portrait and landscape both supported, resized responsively rather than letterboxed.
• Touch and mouse input, since previews are frequently tested on desktop.
• Runs offline once loaded, with no network calls of its own.
• Uses the network's install and completion API, wired to the correct events.
• Deterministic and short, with a hard time limit and a guaranteed end state.
• No console errors, which cause rejections during review.

The install call is the detail most often missed. Each network has its own function name and its own required lifecycle events, and using the wrong one produces a creative that runs and reports nothing.

Handoff format for developers

Give a developer these seven items and the build becomes straightforward.

1. The target networks, so the correct APIs and limits are used.
2. The mechanic, described in one sentence with a reference to the real game.
3. Assets, at final size, in the formats you want inlined.
4. The success state and how quickly it should be reachable.
5. The end card design, including exact text and the button label.
6. The time limit and what happens when it expires.
7. A test checklist, covering both orientations, muted playback, and a slow connection.

Ask for the source project alongside the built file. Playables get iterated frequently, and a build with no source means every variation starts over.

What we would do

Build the playable from the real game's mechanic rather than inventing something for the ad. It is the whole advantage of the format, and the alternative recreates the mismatch problem described in Three Ad Creatives That Beat the Game.

Make the first version deliberately simple: one interaction, guaranteed success, a clear end card. Test that against your video creative before building anything more elaborate.

Then iterate on the hook rather than the play. The opening two seconds move results more than the interactive section does, which mirrors what happens in the game itself.

The short version

• A playable is one self-contained file with everything inlined.
• Three parts: hook, a short guaranteed-success play, and an end card.
• Assume it starts muted, so nothing important lives in the audio.
• Show an animated tap indicator, and let the player win.
• Use the network's own install and completion calls, not your own link.
• Ask for the source project, because playables are iterated constantly.

Write the seven handoff items for your strongest mechanic and get one built. If you would like us to produce it alongside your video creative, tell us about the game.

Related reading: Setting Up Your First Facebook Creative Test, Reverse-Engineering a Winning Ad Hook in Four Beats, and The Pre-Test Checklist Before You Spend a Dollar on UA.