A playable can look perfect in a desktop browser and still fail the moment it enters an ad SDK. That is why Unity Ads playable requirements are not just a file-format checklist. They shape how you build the first interaction, package assets, handle the install call, and test the ad before spend is attached to it.

For UA teams, the costly mistake is treating the playable as a miniature version of the game. A playable ad is a short, self-contained sales experience running inside a constrained mobile environment. It has to load quickly, respond to touch reliably, and get users to the store without breaking the host app. Build for those conditions from the first scene, not during a rushed export review.

What Unity Ads Playable Requirements Actually Cover

Network specifications can change, so always verify the current Unity Ads documentation and your dashboard’s upload feedback before final delivery. In practice, the requirements fall into two categories: whether the HTML5 package can be uploaded and whether it behaves correctly inside the ad container.

The upload side typically concerns the packaged archive, entry file, supported web technologies, file size, and asset structure. The runtime side is where most production issues appear: loading states, screen orientation, audio behavior, touch input, browser compatibility, MRAID communication, and the call to action.

A valid ZIP file is not automatically a launch-ready playable ad. An ad can pass a basic upload check but show a blank screen after a slow initialization, lose its CTA after a replay, or attempt to open a store URL in a way the container blocks. Treat technical acceptance as the starting line, not the finish line.

The package needs to stand on its own

Your exported playable should be a self-contained HTML5 package with a clear entry point, commonly an `index.html` file at the expected location in the archive. Keep the directory structure intentional. If the runtime cannot find a script, texture, font, or audio file because an export added an unexpected parent folder, the player sees a broken ad rather than your concept.

Avoid depending on external assets, remote configuration, third-party scripts, or network calls for essential gameplay. Mobile ad environments may restrict those requests, and they introduce loading uncertainty that a 20-second ad cannot afford. Bundle the assets needed for the experience. If an asset is not necessary to communicate the core game promise, remove it.

File size is a creative constraint as much as a technical one. A high-resolution background, several music tracks, and long animation sequences may look harmless in a project folder but become expensive on a mobile connection. Compress images thoughtfully, reduce unused frames, reuse sprites, and favor short audio cues over heavy soundtracks. The goal is not the smallest possible package. It is a package that starts quickly without stripping away the interaction that makes the ad persuasive.

Build for the host environment, not a normal web page

A playable runs in an ad container, not in a full desktop browser. Assume the device has limited memory, an inconsistent connection, and a user who may tap before the opening animation finishes. The first meaningful frame should appear fast, and the first meaningful action should be obvious.

Start with a visible loading state when initialization could take more than a moment. Then transition immediately to the hook: drag a character away from hazards, merge two objects, choose the correct path, or tap rapidly to defend a base. Do not make users wait through a logo sequence before they can understand the mechanic.

Orientation should be deliberate. If the game is landscape, design the playable in landscape and make the orientation handling predictable. If the concept can work in portrait, it may reduce friction for users holding a phone naturally. What matters is that layout, touch targets, and the CTA remain usable on the devices and placements where the ad will run.

Unity Ads Playable Requirements for MRAID and CTAs

MRAID is the bridge between an HTML5 playable and its host ad environment. Your creative may use it to understand basic container information and trigger the appropriate action when a user taps the CTA. You do not need to turn every playable producer into an MRAID specialist, but you do need to test the behaviors that depend on it.

The central rule is simple: do not rely on ordinary browser navigation for an install action. Use the network-supported CTA flow and make sure the button works after the ad has loaded, after gameplay ends, and after a restart if your experience includes one. A CTA that appears visually but does nothing is a complete failure, even if the interaction itself is excellent.

Keep CTA logic separate from game logic. For example, a runner playable might let the user swipe through three gates, show a score, and reveal a “Play Now” button. The score screen can be rebuilt or replayed without changing the install-event logic. That separation makes it much easier to create variations safely.

Test for these common failure points before submission:

• The CTA is visible, tappable, and uses the expected store-opening behavior.
• The playable does not assume a browser tab, keyboard, hover state, or unrestricted pop-up behavior.
• Audio starts only when permitted by user interaction and never prevents gameplay if muted.
• The ad survives rapid taps, backgrounding, replaying, and low-end-device performance.
• All text, controls, and legal elements remain inside the safe visible area across target screens.

A good rule for touch targets is to make them larger than the visual icon suggests. A small close-looking button, a cramped choice panel, or a CTA sitting too close to the edge creates accidental taps and missed intent. The user should understand what to do in under a second and complete the primary action without precision.

A Production Workflow That Prevents Late Rework

Start with the campaign question, not an asset folder. Are you testing a puzzle hook against a progression hook? Are you adapting a winning video concept into a playable? Are you trying to qualify users by showing a real combat decision rather than a cinematic promise? Your answer determines which interaction belongs in the first five seconds.

Next, reduce the game to one mechanic and one payoff. For a merge title, that might be combining two units to defeat an oversized enemy. For a city builder, it could be choosing the correct upgrade to stop an attack. The playable does not need the full economy, map system, or tutorial. It needs one clean moment that makes the advertised game feel worth installing.

Build the happy path first. Make sure a new user can finish the interaction without failing. Then add controlled friction only if the concept needs it: a near miss, a choice between two paths, or an enemy that creates a satisfying recovery. Deliberate fail states can work, but only when the next action is obvious. An unexplained failure is not a hook.

Once the interaction works, create a compact asset plan. Reuse the same character frames, buttons, effects, and backgrounds across variants wherever possible. Change the opening situation, challenge level, or payoff screen instead of rebuilding the entire ad for every test. This is where a no-code production workflow is especially useful: creative teams can duplicate a proven structure, swap assets, tune timing, and generate new concepts without putting every adjustment in an engineering queue.

PlayableMaker can support that workflow with reusable assets, templates, browser-based editing, previews, and validation utilities. The practical advantage is not that every playable should be template-driven. It is that teams can reserve developer time for genuinely custom mechanics while moving routine variations and network-ready exports faster.

Test the Ad Like a User Will

Previewing on a large monitor catches obvious layout problems, but it does not replicate ad delivery. Test on actual phones, across the operating systems and device performance levels relevant to your media plan. Check both the first launch and repeated launches. Cached assets can hide issues that appear only for a new user.

Run one test with sound off, one on a slower connection, and one with impatient input. Tap before the loading sequence ends. Swipe rapidly. Rotate only if the placement might allow it. Leave and return to the app if your test environment supports it. These are not edge cases in mobile advertising. They are normal user behavior.

Watch for creative issues as well as technical bugs. Does the opening resemble the game you want to acquire users for? Does the interaction make the CTA feel earned? Does the end card explain the next step without covering the result the user just achieved? A technically compliant playable that misrepresents the game can create poor downstream user quality.

The best next step is to make a small pre-launch QA routine part of creative production, not a final gate owned by one person. When designers, UA managers, and producers can preview the same build early, technical compliance and better creative decisions happen at the same time.