Google UAC Playable Ads: Passing Review & Building Lean

Google's Universal App Campaigns run on automation: the ML system decides which creatives to serve, to whom, and at what frequency. Interactive HTML5 assets (playables and end cards) give Google's auction more engagement data than video or static images. But getting a creative into Google's inventory requires passing the HTML5 ad validator, which has stricter checks than most teams expect. Current specs: Google Ads playable ad specs.

Google Playable Ad Technical Requirements

• A .ZIP with the HTML entry point and every asset self-contained (no external URLs), holding no more than 512 files.
• 5 MB cap, measured on the .ZIP you upload.
• Store exit through ExitApi.exit(), with exitapi.js as a literal <script> tag in the head, not mraid.open().
• HTTPS-only assets (even embedded base64 is fine; no http:// URLs anywhere in the HTML).
• No document.write() or eval(): Google's validator rejects these.
• CTA must detect device and route to correct store (iOS vs Android).
• Creative must function without errors in a mobile webview on both platforms.

The HTML5 Ad Validator

Google runs your HTML through its HTML5 ad validator before the creative becomes eligible for delivery. The validator checks for external network requests, blocked JavaScript APIs, malformed HTML, and performance signals like initial load time. A creative that passes in Chrome desktop can still fail the validator if it uses a deprecated API or makes a DNS lookup.

The most common validator failures: images referenced from external URLs (even HTTPS ones), JavaScript that accesses navigator.geolocation or other gated APIs, and inline scripts that exceed the parser's size threshold. A no-code playable ad maker that's built specifically for Google's format avoids all of these by design: assets are base64 encoded, no external APIs are called, and the output is clean HTML5.

How Google's ML Auction Uses Interactive Data

UAC uses engagement data to decide which creative to favour in later auctions. An interactive end card with a 5% interaction rate tells the system the creative works for that audience. Creatives with strong interaction signals get more impressions, which compounds the data advantage. Starting with a well-designed interactive creative gives you a faster learning curve than starting with static assets.

Lean Creatives Win on Google UAC

Google serves on every kind of phone and connection. A 4 MB creative will load slowly on mid-range Android phones on 3G. A 400 KB creative loads in under a second. Faster loading improves viewability and interaction rates, which feeds better signals back into the auction. On Google, file size affects performance, not only compliance.

Use compressed images (WebP preferred), CSS animations instead of JavaScript-driven motion where possible, and system fonts or small web-safe fonts instead of custom font files. Playable Ads Maker's export-time compression targets the Google format specifically. After export, check the file size in the download; if it's over 1 MB, use the compression option and re-export.

App Campaigns Assemble Your Ad From Parts

Universal App Campaigns are now simply called App campaigns in Google Ads, and the way they work explains a lot about how to build for them. You do not upload finished ads. You supply assets (text lines, images, videos and HTML5) and Google combines them into ads across its properties, including Search, Google Play, YouTube and its display network. Your playable is one ingredient among several, and Google decides when and where it appears.

That has three practical consequences:

• Your playable may appear without your video beside it. It has to make sense on its own: name the game, show the mechanic and present the CTA without relying on footage the viewer may not have seen.
• Asset reporting is your feedback loop. Google rates individual assets over time, and a playable that keeps a low rating is a signal to replace it rather than to keep waiting.
• Variety helps the system. Supplying HTML5 assets with genuinely different mechanics or hooks gives the campaign something to choose between, which a set of near-identical variants does not.

Reading a Validator Rejection

When an HTML5 asset is disapproved, the reason is usually specific enough to fix in one pass, provided you fix the cause rather than the symptom.

1. Read the exact disapproval reason on the asset rather than guessing from the general policy.
2. Open the ZIP and confirm its structure: the HTML entry point where Google expects it, no extra folder wrapping everything, and no more than 512 files.
3. Search the HTML and scripts for anything that reaches outside the package: an absolute http address, a font loaded from a CDN, an analytics snippet left in from testing.
4. Confirm exitapi.js is a literal script tag in the head, not injected later by your own code, and that every store tap goes through ExitApi.exit().
5. Remove anything another network needed but Google does not, such as an mraid.js tag carried over from a Unity or AppLovin build.
6. Re-export, re-zip and upload again, then watch the new asset's status.

Porting a build from another network is where most of these problems start. A file that was correct for one network's container is rarely correct for Google's, which is why exporting each network's file separately beats editing one by hand. The rejection reasons checklist covers causes common to every network.

Testing a Google Build Before Upload

1. Unzip the export into a fresh folder and confirm the HTML opens and plays in a phone-sized browser window. The store exit may behave differently there than inside Google's ad container, so judge the exit on a real preview rather than in the browser.
2. Run the ZIP through the playable ad spec checker for Google to catch structural problems before review does.
3. Open the playable on a real Android phone and a real iPhone and play it through to the CTA with the sound off.
4. Check the ZIP size and the file count against Google's limits, and note both in your upload log.

Ten minutes here is cheaper than a disapproval followed by a resubmission and another wait.

Uploading to Google Ads UAC

1. Open your UAC campaign in Google Ads.
2. Navigate to Assets → Ad Assets → HTML5.
3. Upload the exported ZIP.
4. Google runs the validator automatically: check the status column for approval.
5. Once approved, the creative enters the rotation and Google's ML begins serving it.

Common Mistakes on Google

• Uploading a bare HTML file. Google's playable asset is a ZIP; a loose HTML file is not what the upload expects.
• Relying on a redirect for the store exit. window.location or window.open in place of ExitApi.exit() fails review and does not open the store correctly.
• Treating the cap as the target. A file that only just fits under 5 MB is slow on the mid-range phones that make up much of the reach. Aim well under it; see size targets.
• Expecting instant results. App campaigns need time and conversions to learn which assets work. Judge a playable on its asset rating after the campaign has had a fair run, not after a day.
• Replacing every asset at once. Swap one or two at a time so the campaign keeps the learning attached to the assets that stay.