# Playable best practices > Learn how to design, build, and test playable ads that engage players and pass moderation the first time. 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-the-core-experience). * Design around [Unity controls and both orientations](#design-around-unity-controls-and-both-orientations). * Plan the [end screen](#plan-the-end-screen). * Reduce the [file size](#reduce-the-file-size). * [Test](#test-your-playable) your playable. * Avoid common [rejection reasons](#avoid-common-rejection-reasons). These best practices are recommendations. For the requirements that every playable must meet to pass moderation, refer to [Playable specifications](../specifications/playable). ## 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: 1. **Core mechanic** ### 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. 2. **Hints** ### 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. 3. **Length** ### 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. 4. **Structure** ### 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. | 5. **Format** ### 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. | 6. **Download button** ### 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. 1. **Safe area** ### 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. The following diagrams show the reserved areas in each orientation: 1. **Landscape** **Reserved areas and safe zone in landscape orientation:** ![A wireframe of a playable ad in landscape orientation. 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.](/api/media?file=user-acquisition/media/images/layout-guide-playable-landscape.svg) 2. **Portrait** **Reserved areas and safe zone in portrait orientation:** ![A wireframe of a playable ad in portrait orientation. 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.](/api/media?file=user-acquisition/media/images/layout-guide-playable-portrait.svg) 2. **Responsive layout** ### 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:** ![A wireframe of the Unity end card, with the app icon, game title, star rating, Install button, and close button.](/api/media?file=user-acquisition/media/images/layout-guide-endscreen.svg) 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. 1. Pack animation frames and UI art into sprite sheets, so animation loads from one bitmap instead of many inlined images. 2. Lower the resolution of art to what the device displays. 3. 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. 1. **Desktop browser** ### 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. 2. **Device** ### 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](../preview-creative-packs). While the playable runs, rotate the device. The playable must play correctly in both portrait and landscape orientations from the same build. 3. **Final checklist** ### 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](../specifications/playable#layout-requirements) from the same build. * It pauses and resumes on the MRAID [`viewableChange` event](../specifications/playable#viewability-requirements). * Its CTA opens the [correct store page](../specifications/playable#app-store-redirect-requirements) on iOS and Android. * It meets the requirements in [Playable specifications](../specifications/playable). ## Avoid common rejection reasons The following list shows the most frequent reasons that moderation rejects playable creatives, in order of frequency: 1. Content that doesn't work 2. Deceptive redirects, such as gameplay elements that open the app store 3. Content that doesn't scale or respond to orientation changes 4. Gambling or nudity 5. Audio that ignores the iOS mute switch 6. A broken install button 7. Audio that doesn't stop when the screen locks or the app moves to the background 8. Redirects without player interaction 9. Fake errors or deceptive alerts in the UI 10. One-tap playables, with no gameplay before the CTA For the full list of moderation criteria, refer to [Moderation checks](../moderation/moderation-checks).