How to Test a Playable Ad Properly (Before the Network Does)

A playable that works in a desktop browser has passed roughly a third of the tests that matter. The environment it actually runs in is a webview inside another app, on a phone, over mobile data, with an SDK injecting scripts around it and a system close button overlapping one corner. Most of the failures that get creatives rejected or quietly waste spend are invisible until you put the file on hardware.

What a desktop browser cannot show you

Four things, all of which have ended campaigns. Touch behaviour is the first: a mouse has hover and a precise point, a thumb has neither, and interactions tuned with a cursor are routinely too small or too precise to hit. Safe areas are the second — notches, rounded corners, the home indicator and the network's own close button all occupy space your desktop preview treats as usable canvas.

The third is audio. Desktop browsers autoplay muted content freely; iOS silences a bare audio element when the hardware mute switch is flipped, and does so regardless of the volume setting, which means a large and invisible share of your audience gets no sound at all. The fourth is performance: a development machine renders a particle burst without noticing, a three-year-old mid-range Android does not.

The order to test in

Test cheapest-to-check first, because each stage eliminates work in the next. Static analysis first, then a desktop functional pass, then real devices, then the network's own SDK tool. Doing it in the other order means discovering a missing store link after you have already spent twenty minutes side-loading a test app.

Stage 1 — static checks, before you open anything

Confirm the file is genuinely self-contained: no image, font, script or stylesheet referenced by an http URL, because ad containers block outbound requests and the asset will simply never load. Confirm the size against the strictest network in your mix. Confirm the store-exit call matches the network you are building for — mraid.open() will not report a click on Google, and ExitApi.exit() will not report one on Unity.

These are all readable from the file without running it, which is why they are worth automating. Our free Playable Ad Spec Checker does this pass in the browser, but the point is the checks, not the tool — a grep for "http" in the exported HTML catches the most common one.

Stage 2 — desktop functional pass

Open the file directly and drive the whole flow: the interaction responds, the win state fires, the end card appears, the CTA is clickable. Then resize the window from tall to wide and confirm the layout survives the rotation rather than cropping through the focal point. Use the browser's device toolbar to check a small viewport, but do not mistake that for a device test — it emulates dimensions, not input, not GPU, not the mute switch.

Check the console. A playable that throws an error and keeps running is one small change away from a playable that throws an error and stops.

Stage 3 — real devices

One iPhone and one mid-range Android is the minimum useful set, and "mid-range" is the important word: testing on a flagship tells you almost nothing about the hardware most of your audience holds. The fastest way to get the file onto a phone is to host it somewhere reachable and open the URL, which is what a web preview link is for.

On device, check in this order: does it render at all; does the first interaction respond to a thumb rather than a fingertip-precise tap; does the layout clear the notch and the home indicator; does it hold a steady frame rate through the busiest moment; does the CTA open the correct store listing on that platform. That last one is worth doing on both platforms separately, because a single wrong URL is invisible until someone lands on the wrong app.

Stage 4 — the network's own test tool

Several networks publish a way to run your creative inside their real SDK, and it is the only environment that reproduces MRAID injection, the container's close button and the actual click plumbing. Unity provides a demo app that loads a playable from a URL or a local file. AppLovin and Mintegral both publish preview tools. TikTok validates technical requirements at upload but explicitly does not check safe zones or playability, so that part stays your job.

This stage is where MRAID problems surface. If the creative waits for a viewability signal that the container never fires, it will sit on a blank screen here and nowhere else — a failure mode that is impossible to see in a browser, because a browser has no MRAID container at all.

The six failures worth catching yourself

• An external asset request — the single most common rejection, and entirely visible in the file.
• Over the size cap for the strictest network in your mix.
• A store exit that opens a URL directly instead of calling the network's click API, so the click is never attributed.
• A missing viewport meta tag, which renders the ad at desktop width and scales it down.
• A layout that crops through the CTA in the orientation you did not design for.
• An interaction that is available but not obvious, so the ad reads as a static image and gets dismissed.

None of these require a specialist to find, and all of them cost more to discover in a review queue than in ten minutes on a phone. The asymmetry is the whole argument for a QA pass: automated checks fail instantly at upload, but anything needing human judgement waits in a queue, and a rejection there costs you the queue time twice.

What to do with the result

Keep the checklist with the creative rather than in someone's head. Teams that ship playables regularly end up with a short document per campaign recording which devices were tested and what was found, and the value is not the record — it is that the next creative starts from a known-good baseline instead of re-litigating the same six failures.