Playable ads guide

Unity Ads Playable End Cards: Best Practices That Pass Review (2026)

Unity Ads carries a large share of mobile game ad volume, so most game UA plans include Unity playables. Building for Unity has one extra layer most other networks don't: the MRAID wrapper. Get it wrong and the creative renders blank in-placement, even if it previewed correctly in a desktop browser. Current specs: Unity Ads playable ad specs.

What Unity Checks Before a Playable Serves

  • Format: single self-contained HTML file, all assets embedded.
  • Size cap: 5 MB per file (aim for under 1 MB for fastest load on mobile data).
  • MRAID 3.0: include a <script src="mraid.js"> tag (Unity's WebView supplies the SDK there), wait for MRAID to be ready, and call mraid.open() on CTA tap.
  • Orientation: support portrait, landscape, or both (match your game's native orientation).
  • No external requests: images, fonts, and scripts must be inlined.

Why the MRAID SDK Matters for Unity

MRAID (Mobile Rich Media Ad Interface Definitions) is the standard API that lets an HTML ad communicate with the native app container. On Unity Ads, the SDK is injected by the network. You don't bundle it yourself. But your creative must call mraid.open(url) on CTA tap instead of a plain window.location redirect, otherwise the install link won't route correctly on Unity placements. A playable ad maker that exports a Unity-specific file handles this injection automatically so you don't have to write any SDK code.

Aligning Your Creative With the Game Genre

Unity reaches mobile game players while they're already in a game context. That audience has higher tolerance for mini-game mechanics but lower tolerance for slow loading or confusing UX. Match your creative to the genre: a puzzle game end card should feel like a puzzle, a runner game end card should feel kinetic and fast.

The Game Template feature in Playable Ads Maker lets you drop a working Match-3 or Runner mini-game into your end card scene: the user swaps tiles or taps to jump before the CTA appears. Unity viewers are already mid-game, so a playable mechanic suits them well.

Designing for Viewers Who Are Mid-Game

A Unity Ads impression usually lands inside someone else's game, between levels or in exchange for a reward. That context shapes what works. The viewer already has a game in their hands and an expectation of how a game feels to touch, so a playable that responds instantly and clearly reads as competent, and one that lags or hides its controls reads as a cheap ad.

  • Make the first touch succeed. Whatever the viewer taps first should produce a visible result, ideally a satisfying one.
  • Keep the session short and finish on a win or a near-win. The viewer is on the way back to the game they were playing; leave them wanting the next move.
  • Show the store button early enough to find, but do not let it compete with the mechanic for the first touch.
  • Avoid look-alike interface. Buttons that mimic system dialogs or the host game's controls invite policy trouble; see playable ad policy and misleading ads.

The rewarded vs interstitial guide covers how viewer attention differs between the two placements.

Getting the MRAID Lifecycle Right

Most blank-render problems on Unity come from the order things happen in, not from a missing call. The container loads your HTML, then makes MRAID available, then reports that the ad is ready, and only later does the ad actually become visible to the player. A creative that starts its timeline at the first of those moments can finish its entrance animation before anyone sees it.

  1. Reference mraid.js with a script tag before any of your own code that touches it.
  2. Check mraid.getState(). If it reports loading, listen for the ready event before doing anything that depends on MRAID.
  3. Hold timed content (entrance animations, countdowns, auto-play demos) until the ad is actually on screen. MRAID 3.0 adds an exposureChange event that reports how much of the ad is visible; the older isViewable and viewableChange remain for compatibility.
  4. Route every store tap through mraid.open() with the URL for the player's platform.

A no-code exporter handles this order for you, but it is still worth knowing because it explains a whole class of review notes: a creative that looks fine in a desktop browser, where none of these events ever fire, and blank or half-finished in the real container. The MRAID explainer goes deeper, and the MRAID validator checks a file before you upload it.

Orientation and Resizing on Unity

Unity's specification asks playables to handle both orientations. In practice that means two things: the layout must make sense in portrait and in landscape, and it must lay itself out again if the device rotates or the container resizes while the ad is running. A creative designed only for portrait and simply stretched sideways will often pass the technical check and still look broken to the player.

  • Design both layouts deliberately. Move the headline and CTA rather than scaling the whole scene; a portrait stack often becomes a side-by-side arrangement in landscape.
  • Keep the CTA inside the visible area in both. A button pushed off the bottom edge in landscape is the most common orientation defect.
  • Test the rotation itself, not only each orientation from a fresh load. Turn the phone mid-interaction and confirm nothing resets or overlaps.

The orientation guide covers layout patterns that work in both.

Common Unity Approval Failures

  • External script or image URL: any network request fails Unity's sandbox check.
  • Wrong CTA routing: window.location instead of mraid.open() breaks the install link.
  • Missing MRAID ready handler: creative displays before the ad container is ready, causing blank renders.
  • File over 5 MB: rejected automatically.
  • CTA with no iOS or Android URL: one-platform links are flagged in review.

A Pre-Submission Checklist for Unity

  • One HTML file, every asset inlined, no requests to any other address.
  • Under the 5 MB cap with room to spare, ideally well under 1 MB.
  • mraid.js referenced by a script tag, and nothing runs against MRAID before it reports ready.
  • The store tap uses mraid.open() with separate iOS and Android URLs, and both URLs open the right listing.
  • Portrait and landscape both laid out and tested, including a rotation mid-play.
  • No sound that starts before the player interacts, and nothing that depends on audio to be understood.
  • Opened on a real Android phone and a real iPhone, and played through to the CTA.

If a creative is rejected anyway, the rejection reasons checklist lists the causes reviewers cite most often across networks.

Building Unity End Cards Without Code

In Playable Ads Maker, select the Unity network in the export modal. The tool injects the correct MRAID initialization, wires the CTA button to mraid.open() with your iOS and Android URLs, and embeds all assets. Download the HTML, test on a real Android and iOS device (Unity primarily serves on Android but iOS volume is significant), and upload in the Unity Ads dashboard under your app's Playable or Interactive End Card placements.

Unity A/B testing tip

Unity Ads supports A/B creative testing within a placement. Export two variants (e.g. different headlines), upload both, split traffic 50/50, and run for at least 5,000 impressions per variant before drawing conclusions on install rate.

Create playable end cards in minutes—no code required.

Open Playable Ads Maker

Check a build against these specs

The free Playable Ad Spec Checker grades an HTML or ZIP against every network’s size cap, packaging, MRAID rules and store-exit calls. It runs entirely in your browser — no upload, no sign-up.