AppLovin Playable Ads: Complete Developer Guide

AppLovin moves more playable ad volume than almost any other SDK network. If you're running UA for a mobile game, chances are a significant chunk of your best installs come through AppLovin inventory. But their playable ad specs are strict, and the platform gives you zero feedback when something goes wrong. Your CTA just silently doesn't work. Your ad loads but never converts. You stare at the dashboard wondering what happened.

We've exported thousands of playable ads to AppLovin through Hookin. This guide covers every spec that matters, every rejection we've seen, and exactly how MAX mediation changes the game.

AppLovin Playable Ad Specifications

Requirement	Specification
File format	Single HTML file
Maximum file size	5 MB
Asset embedding	Base64 or base122. No external resources
External requests	Prohibited (no XHR, no CDN calls, nothing)
MRAID compliance	MRAID 2.0
CTA method	mraid.open(url)
Orientation	Must support both portrait and landscape
Audio on load	Muted until first user interaction
Timer start	On first user interaction, not on load
Auto-redirect	Prohibited. First tap cannot trigger store redirect
WebGL fallback	Required for 3D playables

The single-file requirement is non-negotiable. Every image, font, audio file, and script must be embedded directly in the HTML as base64 (or base122) data URIs. No folder structures, no asset manifests, no CDN calls. If your HTML makes a single outbound request, it either fails silently or gets rejected.

MRAID 2.0: Implementation Details

AppLovin uses MRAID 2.0. The SDK injects the MRAID library into the webview, so you don't bundle it yourself. But your code must use it correctly, and "correctly" on AppLovin means exactly one thing for CTAs: mraid.open(url).

Use window.open(), a custom redirect, or any other method and nothing happens. No error. No warning. No console log. Your ad just sits there refusing to convert. We've debugged this exact issue for clients more times than we'd like to admit. It's always the same conversation: "The ad works fine in the browser but nobody's clicking through." Yes, because mraid.open() isn't wired up.

MRAID Initialization Sequence

1. Check mraid.getState(). If it returns ready, proceed. If loading, listen for the ready event.
2. Once ready, your game can initialize. But remember: the ad timer doesn't start until the user interacts.
3. When the user taps the CTA, call mraid.open(storeUrl) to redirect to the app store.

Always wait for the MRAID ready event before calling any MRAID APIs. Calling methods before the bridge is initialized is a silent failure that's nearly impossible to debug without knowing to look for it.

Audio, Interaction, and Timing Rules

AppLovin's interaction model is built around a simple principle: nothing happens until the user acts.

• Audio: Must be muted on load. Only unmute after the first user interaction (tap, swipe, drag). When the ad closes or goes off-screen, kill all audio immediately.
• Timer: The ad timer starts on first interaction, not on load. Don't build gameplay around a countdown that begins before the user has touched anything.
• Auto-redirect: Any automatic redirect to the app store without a deliberate user action is an instant rejection. And the first tap can never be the one that triggers the redirect. The user must interact with the game before a CTA tap can send them to the store.

This "interaction-first" model is the opposite of how some other networks work. ironSource, for example, requires autoplay. If you're targeting multiple networks, you need separate builds. (For Unity and ironSource specs, see our Unity & LevelPlay guide.)

WebGL and 3D Playable Ads

Running a Three.js-based 3D playable on AppLovin? You need a WebGL fallback. If WebGL fails to initialize or loses context (which happens more often than you'd think on older Android devices), your ad must display a static fallback UI instead of a blank screen.

We've seen perfectly good 3D creatives bounced just because this was missing. It takes 20 minutes to add a static fallback screen with your end card and CTA. Just do it. AppLovin's QA checks for this specifically.

Common Rejection Reasons

AppLovin's review process isn't as transparent as Google's. You often get a generic rejection without much detail. Here are the five issues we see most frequently.

1. CTA Not Using mraid.open()

The number one issue. Your CTA button must call mraid.open(url). Not window.open(). Not a custom JavaScript redirect. Not an anchor tag with an href. Just mraid.open(). If you built your playable with a third-party tool that has its own CTA logic, rip that out and replace it.

2. Audio Playing Before Interaction

Any sound before the user taps triggers a rejection. This includes background music, UI sounds, and even audio context initialization that plays a brief blip. Initialize all audio muted. Unmute only after the first user interaction event fires.

3. Missing WebGL Fallback

3D playable ads that show a blank screen when WebGL isn't available get bounced. Add a static fallback with your brand, a brief message, and the CTA button.

4. File Size Over 5 MB

Measured on the raw HTML file. Base64 encoding adds roughly 33% overhead, so 3.75 MB of raw assets becomes 5 MB when inlined. Compress images to WebP, reduce audio bitrate, subset fonts. Our file size optimization guide covers every technique.

5. First Tap Triggers Store Redirect

The user must interact with the game before any CTA tap can open the store. If the very first tap on the ad sends users to the App Store, that's a rejection. Design your flow so the user plays first, then sees the CTA.

AppLovin MAX Mediation

If you're running UA through MAX, your playable ads live inside a mediated environment alongside 25+ ad network adapters. This changes how your creative gets served and tested.

How Mediation Affects Playable Delivery

Your playable competes with creatives from other networks in the waterfall or bidding stack. MAX serves playables through interstitial and rewarded ad units, and the mediation layer picks the winning ad based on eCPM. But here's the critical detail: your creative still gets wrapped in AppLovin's SDK container. So it must comply with AppLovin's playable specs regardless of which network originally served it.

This means if you're also running on Unity or other networks through MAX, the AppLovin spec requirements apply to all of them when served through MAX. Don't assume a Unity-compliant build will work in a MAX-mediated environment.

Testing in MAX

Use AppLovin's Mediation Debugger (built into the SDK) to verify your playable loads correctly across different network adapters. We've seen playables that work perfectly in direct AppLovin campaigns break when served through a mediated adapter because of timing issues in the MRAID handshake. The ad loads, the MRAID bridge isn't ready yet, and the CTA silently fails.

AppLovin also has a dedicated playable preview tool for catching problems before you go live. Use both. The preview tool catches spec violations. The Mediation Debugger catches runtime issues that only show up in mediated delivery.

Creative-Level Reporting in MAX

MAX supports creative-level reporting, which means you can see exactly how each playable creative performs against other ad formats (video, static) within the same campaign. Use this to compare playable IPM against your video baseline. If your playable isn't beating video on IPM, the game mechanic or end card needs work, not the media plan. For a structured approach to running these comparisons, our A/B testing guide covers the full framework.

Performance Metrics on AppLovin

AppLovin's Axon dashboard gives you creative-level performance data. The metrics that matter for playable ads:

• IPM (Installs Per Mille): AppLovin's north star metric. Installs per 1,000 impressions. This is the single best number for comparing playable performance against other formats. Benchmarks vary dramatically by genre and region, so compare within your own campaigns, not against industry averages.
• CTR: Percentage of users who tap the CTA. Low CTR with high impressions means your end card isn't converting. Test CTA text, button color, and placement.
• CPI: Cost per install. Track alongside retention to avoid chasing cheap but low-quality installs.
• ROAS: Revenue versus ad spend. The metric that actually matters for business decisions. A playable with higher CPI but better ROAS is the winner.

Optimization Tips

1. Keep gameplay under 15 seconds. AppLovin penalizes creatives with extended pre-CTA sessions
2. Test CTA placement. An end card after a satisfying gameplay moment beats an interruption-based CTA every time, and nailing the opening seconds matters just as much as the closing CTA
3. Watch IPM by creative. High impressions with low IPM means the gameplay isn't converting. Tweak the end card or adjust difficulty
4. Use raw gameplay for hyper-casual. Actual gameplay loops outperform polished trailers for installs in this genre
5. Refresh creatives every 2-3 weeks. Performance degrades as the audience saturates

How Hookin Handles AppLovin Export

When you export a playable ad for AppLovin from Hookin, the platform adapter handles every spec requirement automatically:

• Wraps your game in a full HTML document with all assets base64-embedded
• Injects MRAID 2.0 with mraid.open() wired to your CTA buttons
• Sets audio to muted-until-interaction
• Starts the timer on first touch, not on load
• Adds WebGL fallback for 3D playables
• Compresses assets to stay under the 5 MB limit

You build one game. The adapter handles AppLovin's specific requirements. Export to AppLovin and 9 other networks with a single click.

---

Create an AppLovin-ready playable ad on Hookin, free to start