End cards, designed with the ad and tested on their own.

What an end card is

An end card is the screen shown when a video or playable ad finishes, carrying the call to action that sends the player to the store. Unity's definition: "End cards are creative assets displayed at the end of an ad with a call to action for users to download the advertised product."

End cards come in three kinds. Moloco lists them as "Static, Animated, Interactive". A static end card is an image. An interactive end card is a small HTML file, built like a playable, that runs after the video. On some networks the end card is not optional: Unity says "all video ads must also include an end card."

Why end cards matter for a game studio

The video earns attention. The end card is where the install decision gets made, and in most accounts it is the asset that changes least. We wrote up why in End cards are the most under-tested asset you own.

Two pieces of outside evidence make the point. In a 2024 Singular article, John Koetsier described a test Bigabid's Avi Cohen ran with two end cards on the same ad: one "similar looking, just with a CTA and a logo", the other "completely unrelated and generic." The result: "the generic-looking end card worked better." Our reading is not that generic end cards win. It is that nobody can call an end card in advance, so it has to be tested.

The networks also push interactive end cards. ironSource's archived creative guidance says "we recommend pairing your videos with interactive end cards (IEC) to increase user engagement." Moloco writes that for its top gaming advertisers "as much as 70% ~ 80% of video spend" is paired with interactive end cards "instead of static ones." Those are the networks' own descriptions of their own inventory.

Specs per network

As published by each network. ironSource's pages are read from Wayback Machine snapshots from early 2026 because the live URLs now redirect to Unity's general docs.

Network	Static end card	Interactive end card
AppLovin	9:16 image; 320×480, 320×512, 640×1138 or 768×1024; minimum 270×480; GIF, JPEG or PNG up to 10 MB	HTML assets follow AppLovin's HTML playable spec: one HTML file, 5 MB or less, MRAID v2.0, no external network calls
Unity Ads	JPG, PNG or GIF, 5 MB; square 800×800 is the default and recommended; 800×600 (4:3) and 600×800 (3:4) also accepted	One inline, responsive, minified HTML file up to 5 MB; MRAID 3.0; versions for both orientations; runs after a 15 to 60 second video
ironSource Ads	Full screen: 9:16 and 16:9 phone images, 3:4 and 4:3 tablet images optional, 2 MB max. A carousel end card is also offered	HTML file 5 MB or less; users must interact at least once, and for at least 7 seconds, before the store redirect
Mintegral	"Video&Image Endcard" output: 1200×627 image and 512×512 icon required; 720×1280 and 768×1024 among optional sizes	"Video&Playable" output pairs a video with a playable
Google App campaigns	Auto end screen, generated from campaign information (app name, icon, price, install link); in-stream ads in app install campaigns only	None described on Google's auto end screen page

Two details catch teams out. Unity warns that "Dynamic cropping might occur" on portrait and 4:3 images and asks for a 100-pixel buffer from the cropped edges. And for iOS, Unity says to "only depict the Apple app store logo."

There is also an end card you do not build. When a player skips or closes a playable on Unity, "Unity shows a final end card with the app icon, store rating, game name, and a download button. You don't build this end card, and you can't change its style." On Google, the auto end screen "will appear by default after eligible video ads."

Static or interactive

A static end card is cheap to make and quick to vary, which makes it the right first test. An interactive end card costs more to build but gives the player something to do. ironSource's guidance says "An IEC should supplement the video it’s paired with", for example letting users "try out the gameplay shown in the video." Unity says the same about playable end cards: "Skip the setup, and start at the moment the video promised."

The rules that apply to playables apply to interactive end cards too. Unity: "Do not automatically redirect or use the first touch to redirect to the app store." AppLovin requires that an HTML ad "must not redirect to app stores on the first tap/click."

In our view the choice follows the game. If the video shows a mechanic that is fun to touch, an interactive end card that lets the player do it is the natural close. If the video sells a story, a character or an offer, a static card that repeats it is often enough, and it lets you test more versions. Some of our playables carry their own closing screen, built in the same file: play Hatch Em All for Dragon City, The Getaway for Metacore, Level 1 for Hello Kitty or Legend of Breeding for CritterCraft through to the end.

What a good end card does

Our view, with the guidance that supports it:

It keeps the ad's promise. The end card should show the game the ad just sold, in the same words and the same look. Unity's video guidance: "It helps user retention if the app experience is what was expected after seeing the trailer."

It has one job. One call to action, starting with a verb, as Unity recommends for playable end screens. Cohen's tip in the Singular piece: "you could use a finger pointing at the install button."

It survives the crop. Keep the logo, the button and the key art inside the safe buffer, and build each ratio the network asks for rather than letting one image be cropped.

It agrees with the store page. ironSource notes that a low conversion rate "could mean that the user is seeing something they weren’t expecting in the store itself." AppLovin lets a creative set point to a custom product page on iOS or a custom store listing on Android, so the end card and the page can say the same thing.

More detail, including the full spec notes, is in End cards: what they are, the specs, and how to test them and What makes a good end card for a mobile game video ad?.

How to test an end card

The hard part is isolation. Cohen again: "it’s very hard to test it alone without the video." So hold the video constant and run new end cards against the current one. Then reverse it: hold the winning end card and vary the video.

Test big differences before small ones. ironSource: "test more significant variables in the user experience first to see if they make an impact, before testing smaller factors", for example level 1 against level 2 before colours and text.

On AppLovin a creative set can hold up to 10 files of each asset type, which is room for several end cards beside one video. For HTML end cards, AppLovin's analytics events include ENDCARD_SHOWN and CTA_CLICKED. Use them to see where players drop off, then judge the end card on installs and payers in your MMP, not on clicks on the card.

How Flixr makes end cards

We design end cards in house, with the video or playable they close and from the same brief as the landing page, so the last screen shows what the ad promised. We size and build them to each network's published specs, and test them as their own variable: new end cards against the current one, with the video held constant.

We run and read paid media on AppLovin, Meta and TikTok, with a creative lead inside your ad account and read-only access to your results, so we are judged on the same numbers as your team. The first month is a read of 90 days of your ads, a gap analysis and the first three hypotheses; after that the loop runs every week: brief, make, launch, read, log.