The Playable Ad QA Checklist to Run Before Submission

A playable that passes on the device the team built it on and fails on the device it gets served to isn't a rare event. Without a deliberate QA pass it's close to the default outcome. Networks render playables inside their own webviews, with their own memory ceilings and their own quirks in how they handle the MRAID or network-specific wrapper around the file. A desktop preview shows you none of that. Hence the playable ad QA checklist, which exists to catch what the preview never will.

Before anything else: file size and load time

Most rejections trace back to load time. So does most silent underperformance, which is worse. A playable that takes more than three to four seconds to become interactive on a mid-tier Android device loses a meaningful share of viewers before they've done anything, and that loss never shows up as a rejection; it shows up as a quietly worse install rate that gets blamed on the creative concept rather than on technical delivery. Check total file size against each network's stated limit rather than a generic industry figure, since the limits vary widely and some networks compress assets server-side in ways that can distort textures or break sprite sheets if the source wasn't built with headroom.

Test load time on a genuinely low-end device profile, not the newest phone in the office. No such device in the building? A mid-range Android handset from two to three years ago is a reasonable proxy, since a meaningful share of served impressions will land on hardware in that range.

Tap targets and input handling

Tap targets need testing at the actual rendered size the playable will appear at inside an ad unit, not the size it looks correct at in a full-screen preview build. A button that reads clearly at full screen can shrink below a comfortable tap size once scaled into a rewarded video end-card slot or an interstitial frame with network-mandated close-button padding. Every interactive element should have a tap target no smaller than roughly 44 by 44 points, checked at the smallest common serving size, not just the largest.

Input handling also needs testing for the failure case, not just the success case: what happens if a user taps outside the intended target or taps twice quickly, and what happens on a tap during a transition animation. A playable that freezes or advances incorrectly on a mistimed tap will generate confused or accidental installs with poor day-one retention, which then gets misread as a creative or audience problem rather than a QA gap.

It's a QA gap.

End-card logic, every path

The end card is where most technically sound playables still leak conversion, because it's the one screen every viewer reaches regardless of how they played the interactive portion. Test every path to it. Not only the intended one: what the end card shows if a user completes the playable, if they run out the timer without completing it, and if they skip early where the network allows skipping. Each path should still present a clear, correctly labelled call to action and should never leave a user on a blank or frozen frame while a store link resolves.

Verify the store link itself on every target platform and store variant the campaign will run against. A single hardcoded link that points to one listing will misdirect a share of users on the other platform, and it's easy to miss because it fails silently rather than throwing a visible error.

Network-specific rendering quirks

Different networks wrap playables differently, and a file that renders correctly in one network's preview tool can clip or letterbox in another's, or come out mis-scaled. Before wide submission, preview the build inside each network's own testing tool where one exists rather than relying on a single generic MRAID preview, and check specifically for safe-area handling around notches and rounded corners on newer devices; a UI element anchored to a screen edge is the most common thing to get clipped.

Orientation, audio and localisation

Orientation lock deserves an explicit test rather than an assumption. Some networks will still serve a portrait build inside an ad unit locked to the wider orientation, and a build without an explicit orientation lock will sometimes render sideways or with UI elements stacked incorrectly instead of getting rejected outright, which means the failure reaches live traffic before anyone notices. Confirm the orientation the build declares matches the orientation every target network will actually serve it in, not only the orientation used during internal review.

Audio defaults get the same scrutiny. Most networks serve video and playable ads with sound off by default, relying on a tap or an explicit mute toggle to enable it, and a playable that assumes sound-on as its baseline experience, using audio cues as the only signal for a key interaction, will confuse a meaningful share of viewers who never hear it. Build every core interaction to work with a visual cue as well as an audio one. Then test the full flow muted before assuming sound will carry any part of the experience.

Localisation QA too often gets treated as a text substitution check and nothing more, which misses the more common failure mode: text that fits in English overflowing its container in German, or a right-to-left language breaking a UI element that nobody tested against a mirrored layout. Any playable running in more than one language needs its longest expected string tested in every UI element that displays copy, not a spot check in the authoring language.

The playable ad QA checklist, condensed

Run this sequence before every submission: confirm file size against the specific network's limit; test load time on a low-end device profile; verify every tap target at minimum serving size; walk every end-card path including timeout and skip; confirm store links resolve correctly on both platforms; and preview inside each target network's own rendering tool where available. None of these steps is individually difficult. The discipline of running all of them, every time, in the same order, is what actually prevents the rejection or the silent performance loss, not any one clever test on its own.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• A Year-End Playable File Size Load Time Audit to Run
• A playable QA holiday code freeze checklist to run early