Playable ad best practices

Learn how to design, build, and test playable ads that engage players and pass moderation the first time.

Read time 12 minutes

Last updated 3 days ago

Playable ads let players try a short interactive version of your game before they install it. This page provides recommendations for designing, building, and testing playables for Unity Ads User Acquisition. The recommendations apply to both standalone playable ads and playable end cards that run after a video ad.

The best practices on this page help you do the following:

Design the core experience.
Design around Unity controls and both orientations.
Plan the end screen.
Reduce the file size.
Test your playable.
Avoid common rejection reasons.

These best practices are recommendations. For the requirements that every playable must meet to pass moderation, refer to Playable asset specifications.

Design the core experience

The core experience is what the player sees and does from the first frame of your playable to the end of its gameplay loop. Players decide whether to start tapping before they read anything, so the core experience must get them playing quickly and then keep them engaged.

Refer to the following best practices for designing the core experience:

Show the core mechanic immediately

Open your playable on a state the player can act on right away, such as a board mid-puzzle, a car already moving, or a tower about to fall. Make sure the mechanic is live on the first frame and that a single tap target is clear.

Avoid logos, studio splashes, and cinematic intros. They push the first tap past the point where most players drop off.

Teach with one hint

Players decide whether to start tapping before they read anything, so they won't stop to read instructions. Teach the core mechanic with one visual hint, and then remove the hint so it doesn't get in the way of gameplay.

A pointing hand or a single highlighted path is usually enough. For example, show a pulsing hand on the one available action, and then fade it out. Repeat the hint only if the player stalls.

Avoid blocks of rules over the play area, or tutorials that take several taps to dismiss.

Let the loop set the length

Pick a single mechanic from the game and build the whole playable around it. A short loop that ends in a clear success or failure moment keeps the creative honest about what the game is.

There's no single correct duration for a playable. However, players need to understand the core mechanic within the first 3 to 5 s because the Unity close button can appear after only 5 s. After that point, the right length depends on the type of mechanic.

The following table shows typical lengths for common types of playables:

Playable mechanic	Example genres	Typical length
Simple and repetitive	Hyper-casual	20 to 40 s
Takes time to explore	Puzzle Merge Mid-core	More than 2 mins

Playables with deeper mechanics still convert well at longer lengths because the player chooses to stay.

Base the length on how quickly the gameplay moves, not on a target duration. If your gameplay loop is simple, don't add filler content to make the playable run longer.

Structure your playable in stages

The core experience runs from the first frame of your playable to the end of its gameplay loop, and each part of that span has a different job. The start screen gets players tapping, the gameplay keeps them engaged, and the end screen prompts them to install.

Structure your playable in the following stages:

Stage	Best practices
Start screen	Show only a short gameplay guide. Show the first interaction by example, and animate into gameplay if there's no input.
Gameplay	The player finishes the loop at their own pace. If the mechanic holds attention, a longer loop is fine. Use drop-off data to decide when to end.
End screen	Show a failure or congratulations message, with the game name, icon, and logo. You can animate the download button for attention, but avoid strobe effects, which Apple doesn't allow.

Adapt the playable to how it's served

Unity Ads can serve your playable in two formats: as a standalone playable ad, or as a playable end card after a video ad. The format determines how much of the core experience your playable needs to provide because players arrive with different levels of context.

Refer to the following best practices for each format:

Format	Player context	Best practices
Standalone playable	No prior knowledge of the game	Capture the player's attention. Teach the mechanic. Set your own pace. Loops of 2 mins or more work best in this format.
Playable end card	Already introduced to the game by the video	Skip the setup, and start at the moment the video promised. Focus on converting the player instead of teaching.

Add a download button during gameplay

A persistent download button during gameplay reliably earns more clicks than waiting for the end screen. This matters most for longer playables because many players who decide to install never reach the end screen.

Use the following best practices for the download button:

Keep the button visible throughout gameplay.
Place the button inside the safe area.
Place the button outside the play area, so it doesn't cover gameplay.
Don't animate the button too much.
Keep a separate download button on the end screen. Don't make the gameplay button the only way to reach the store.

Design around Unity controls and both orientations

Your playable shares the screen with controls that Unity draws over it, and it must fit every screen shape that Unity serves it to. Content that's hidden behind Unity's controls or cut off after an orientation change makes your playable harder to play. Moderation also rejects playables that don't scale or respond to orientation changes.

The following tabs describe how to keep important content in the safe area, away from Unity's controls, and how to design one responsive layout for both orientations.

Keep important content in the safe area

Unity can display its own controls in the top and bottom areas of the ad. These controls include the countdown, the close button, and UI for privacy and consent. The controls that appear depend on the type of ad, the region, and the player's consent state. These controls can also change over time.

Use the following best practices to design around the top and bottom areas:

Don't assume that the top and bottom areas are empty.
Keep interactive content inside the safe area in the middle of the screen. Interactive content includes your heads-up display (HUD), hints, and download button.
Use the top and bottom areas only for wallpaper or other non-interactive graphics.
In landscape orientation, leave more room for the top and bottom areas. These areas take up a larger share of the screen in landscape orientation.

A wireframe of a playable ad. Bands at the top and bottom of the screen are reserved for the Unity overlay and native platform features. The safe zone between them holds important elements, logos, and calls to action. — Reserved areas and safe zone in a playable

Design one responsive layout

Unity serves your playable in both portrait and landscape orientations, and ads serve to both portrait-locked and landscape-locked games. Design a single layout that adapts to the screen instead of asking the player to rotate their device.

Use the following guidelines to build a responsive layout:

Anchor the HUD, score, and download button to the safe area, not to fixed pixel offsets.
Scale the play area instead of the controls.
Make tap targets large enough to tap easily on small screens.
Fill extra space on purpose, with a wallpaper or by moving the download button into it.
Test the layout again after every layout change.

Check your layout on portrait 9:16 phones, landscape 16:9 phones, and 4:3 tablets. Include the extremes, such as tall phones and short landscape windows.

Plan the end screen

When the player skips or closes your playable, Unity shows a final end card with the app icon, store rating, game name, and a download button. You don't build this end card, and you can't change its style. Because there's always a final install prompt, design your own end screen as the reward moment, not as the only chance to convert.

Layout of the Unity end card

Use the following best practices for your end screen:

Carry the art, characters, and reward from the playable into your end screen.
After the success moment, keep one call to action (CTA) visible. Start the CTA with a verb.
Don't recreate the Unity end card.
Don't use fake close buttons or fake system UI.
Don't disguise a CTA as gameplay.

Reduce the file size

Every playable must be less than 5 MB. If your playable is over the limit, try the following techniques in order until the file is small enough. Image and video files are usually the largest part of a playable, so the techniques that reduce them come first.

Pack animation frames and UI art into sprite sheets, so animation loads from one bitmap instead of many inlined images.
Lower the resolution of art to what the device displays.
Compress audio before you inline it.

Minification is a requirement for every playable, so minify the file as your final step, even if it's already less than 5 MB.

Test your playable

Testing helps you find problems before moderation rejects your playable. Test your playable in three stages: in a desktop browser, on a real device, and against a final checklist before you submit it. The following tabs cover each stage.

A desktop browser lets you play through your playable while you build it. However, a desktop browser or simulator doesn't run your playable in the real ad unit, and many common rejection reasons only appear on a real device. Always test on a device before you submit your playable.

Test in a desktop browser

Use the following guidelines to test your playable in a desktop browser:

Make sure that the final build also runs without MRAID, so you can test the complete playable in a desktop browser.
View the playable at mobile resolution by using the browser's mobile view or an iframe.
Confirm that the download button opens the correct store page.

Test on a device

Preview your playable on a real device with the Ad Testing app. The User Acquisition dashboard generates a QR code for each creative pack when you select Show QR code. For more information, refer to Preview creative packs with the Ad Testing app.

While the playable runs, rotate the device. The playable must play correctly in both portrait and landscape orientations from the same build.

Check your playable before you submit it

Before you submit your playable, confirm that it meets the following criteria:

It loads and reaches the first interaction in less than 2 s on a mid-tier device.
It plays correctly in both portrait and landscape orientations from the same build.
It pauses and resumes on the MRAID
```
viewableChange
```
event
.
Its CTA opens the correct store page on iOS and Android.
It meets the requirements in Playable asset specifications.

Avoid common rejection reasons

The following list shows the most frequent reasons that moderation rejects playable creatives, in order of frequency:

Content that doesn't work
Deceptive redirects, such as gameplay elements that open the app store
Content that doesn't scale or respond to orientation changes
Gambling or nudity
Audio that ignores the iOS mute switch
A broken install button
Audio that doesn't stop when the screen locks or the app moves to the background
Redirects without player interaction
Fake errors or deceptive alerts in the UI
One-tap playables, with no gameplay before the CTA

For the full list of moderation criteria, refer to Creative moderation checks.

Documentation

Development

User Acquisition

Monetization

Industry

Unity Ads User Acquisition

Advertising Management API

Advertising Statistics API