Google Ads HTML5 App Campaign: How the Asset Is Used

Key takeaways - In an App campaign, an HTML5 file is one asset in a pool. You supply the pieces, and Google assembles and places the ads. - You do not choose placements for the HTML5 asset. It is eligible only where the inventory can render it, so keep video, image, and text assets in the campaign too. - The click-through uses ExitApi, not clickTag, because the destination is the app store listing connected to the campaign. - Build the asset to stand alone: a clear first few seconds, a short interaction, and an end card that sends the user to the store. - Read results at the asset level and give the test enough time before drawing conclusions.

What an HTML5 asset is in an App campaign

If you have run Display campaigns, you are used to uploading a creative and attaching it to an ad with its own landing URL. App campaigns work differently.

An App campaign is built around one app. You give Google the store listing, a budget, a goal, and a set of assets: headlines, descriptions, images, videos, and HTML5 files. Google combines them into ads and decides where to show them.

So when you upload a google ads html5 app campaign asset, you are not creating an ad in the traditional sense. You are adding an option to the pool. The playable or interactive file is something the system can choose when a placement supports it.

Playable ads in Google Ads follow the same logic. A playable is just an HTML5 asset the user can interact with. If you are new to the format, What Is a Playable Ad? covers the basics.

How Google uses the asset

Three things follow from the asset model.

1. Eligibility depends on the placement. App campaigns run across many surfaces, and not all of them can render an interactive HTML5 file. Where the file is not eligible, the campaign falls back to other assets. That is why a campaign with only an HTML5 file is a poor setup. It would have nothing to serve in those places.

2. The mix is automatic. You cannot say "show the playable on this surface and the video on that one." The system chooses combinations based on what it expects to perform. Your job is to give it good, distinct options.

3. The destination is fixed by the campaign. The user ends up on the store listing of the app you selected. The HTML5 file does not carry its own destination URL. It only has to tell the host environment, at the right moment, "the user wants to go to the store."

That last point is where most technical mistakes happen.

Click-through: ExitApi, not clickTag

In Display, the clickTag convention passes a landing URL into the creative. In App campaigns, the creative does not know or need the URL. Instead, it calls ExitApi, an API provided by the host environment that triggers the click-through to the destination Google already has.

In practice, that means:

• Every tappable element that should lead to the store, such as the install button, the end card, or the full-screen "tap to continue" area, must call ExitApi.
• A hardcoded store link inside the file is a policy problem and will not behave the way you expect.
• A file built for Display with a clickTag will not work as intended here without changes.

We cover the mechanics in ExitApi in App campaigns. If your file came from another tool or an older Display build, check this first.

What you control, and what you don't

It helps to be clear about the boundary.

You control:
- The content and quality of the HTML5 asset.
- The first moments of the experience, the interaction, and the end card.
- The other assets in the same campaign: video, images, text.
- The app, goal, and budget that frame the campaign.

You do not control:
- Which placement serves the asset.
- How often it is chosen compared with other assets.
- How Google combines it with text or other elements around it.

This is why a single "hero" playable rarely carries a campaign alone. A good setup treats the HTML5 file as one strong option within a campaign that has healthy alternatives.

Build the asset for an unknown context

Because you cannot predict where the asset will appear, build it to hold up in different contexts.

• Make the first screen self-explanatory. The user may have no context. A short, visible instruction such as "tap the matching tiles" beats a long intro.
• Show the core action quickly. If your game is a puzzle, let the user solve something. If it is a utility app, show the result of the main action. Playable Ad Best Practices goes into tutorial, core loop, and end card in detail.
• Keep it light. Heavy files load slowly, and a slow load means the user may never see the interaction. Check the current file size spec in Google Ads Help rather than trusting any number you remember.
• Design for sound-off. Many users will not hear anything, so make sure the experience works without audio.
• Make the end card unmistakable. One clear call to action that calls ExitApi is better than several competing buttons.

Packaging and policy

Google expects a specific package structure: a ZIP with an HTML entry file and its resources, within the size and dimension rules in the current spec. The spec lives in Google Ads Help, and it can change, so check it before each production cycle.

Common reasons for rejection are practical rather than mysterious:

• Missing or incorrect ExitApi call.
• External requests to resources not allowed by the spec.
• Files that fail to load or render in the preview.
• Behavior that is misleading, such as a fake "close" button that triggers a click.

The step-by-step upload process is in How to upload an HTML5 ZIP to Google Ads, and the Playable HTML5 QA checklist is useful to run before you submit.

Where this fits with the rest of the campaign

Think of the HTML5 asset as a third creative type next to video and static images. Each does a different job.

• Video tells a story passively and works where the user is watching.
• Images and text cover the broadest range of placements.
• HTML5 / playable lets the user try the product, which can filter for people who actually like what they play.

That filtering effect is the usual argument for playables. It is a reason to test them, not a guarantee. Whether it helps your app depends on your game, your audience, and how well the interaction represents the real product.

Reading the results

Asset-level reporting in App campaigns lets you see how individual assets perform relative to each other. A few cautions apply when you read it:

• Do not judge too early. The system needs time to try the asset in different combinations. Early swings often settle.
• Compare like with like. If you launch a new HTML5 file alongside a new video and a new headline set, you will not know which change mattered.
• Look past installs. A playable may attract users who understand the product better. Check downstream events such as tutorial completion, registration, or purchases, not only the install count.
• Change one thing at a time. Replace or add one HTML5 variant, leave the rest, and wait.

If the asset is not getting served at all, check the status in the asset list first. A rejected or limited asset will not be eligible, and the reason is usually shown there.

A simple workflow

1. Confirm the campaign has a healthy base of text, image, and video assets.
2. Build the HTML5 asset with ExitApi on every store-bound action.
3. Test it in the preview and on real devices, with sound off and on a slow connection.
4. Run through the QA checklist, then upload the ZIP.
5. Let it collect data, then compare it at the asset level before you iterate.

If you do not have a developer to build the file, a tool can shortcut the first steps. PlayableRun turns a store listing into an HTML5 playable and exports a ZIP intended for Google Ads. As with any generated output, review it before you upload it, which is what How to Review the Output is for.

Try it on a real listing

If you want to see what an interactive asset looks like before committing to a build, browse the live demos. If you would rather generate one from your own listing and run it through the checklist above, you can create a free account.