Playable Ad Analytics: What You Can Measure Inside the Ad, and What You Cannot

The first thing to understand about measuring a playable ad is that you cannot phone home. Ad containers run creatives in a sandboxed webview that blocks outbound requests, and several networks treat an attempted request as a policy violation rather than a bug. Any measurement plan that starts with "we will fire an event to our analytics endpoint" is a plan to get the creative rejected.

What that rules out

Third-party analytics SDKs, custom event beacons, remote configuration, A/B assignment fetched at runtime, and anything that loads a script from a CDN. All of them are standard practice on the web and all of them are disqualifying here. It is worth saying plainly because teams routinely try to port a web measurement stack into a playable and discover the constraint at review.

It also rules out the comfortable assumption that you can instrument your way out of a creative question. In a playable, most of what you learn comes from designing the creative so that its outcomes are legible in the network's own reporting.

What the networks give you

Every network reports impressions, clicks and installs at the creative level, and that trio already answers more than teams assume. Click-through rate tells you whether the creative earned a decision; install rate per impression tells you whether the decision survived the store page; the ratio between them tells you whether the ad is over-promising.

Some networks additionally expose engagement or completion signals, and where they do those are the most useful numbers you have, because they separate "did not care" from "cared but did not convert". The reporting granularity varies enough between networks that it is worth checking what each one exposes before designing a test that depends on a metric only two of them report.

What the SDK exposes to the creative

Inside the ad, the container's own API is the one legitimate channel. MRAID reports when the ad becomes viewable and what its state is — in MRAID 3.0 through the exposureChange event, which reports an exposed percentage between 0 and 100. That is not analytics in the tracking sense, but it is exactly what you need to avoid the most common measurement error in playables: starting the experience while the ad is off screen, so the first three seconds you carefully designed play to nobody.

Several networks also expect lifecycle calls from the creative — Mintegral looks for gameReady and gameEnd, Liftoff for a completion signal. Those are contracts with the container rather than measurement for you, but firing them correctly is what makes the network's own completion reporting accurate, which loops back into the numbers you will be reading.

Designing for legibility instead of instrumentation

If you cannot instrument the inside of the ad, you have to make the outside of it informative. The practical technique is to separate what you want to learn into different creatives rather than different code paths inside one creative.

Testing whether a tutorial hand improves completion? Two creatives, one with and one without, each reported separately by the network. Testing two end card layouts? Two creatives. This feels wasteful next to a runtime flag, but a runtime flag produces a number you cannot see and a network report you cannot segment, so it produces nothing at all.

Naming is measurement infrastructure

Because the creative name is often the only dimension you can slice by, it is doing more work than in any other channel. A convention that encodes the variables — mechanic, hook, end card, orientation, locale — turns a flat list of creative rows into something you can actually pivot. Teams that skip this end up six weeks in with forty creatives called things like final_v3_new and no way to answer which mechanic won.

On iOS this becomes structural rather than cosmetic. Under SKAdNetwork, creative-level attribution survives only through the source identifier, so campaign structure determines what you are able to learn at all. Anything not separated at that level is averaged away permanently — there is no post-hoc breakout.

A measurement plan that fits the constraints

1. Decide the one question this batch of creatives answers, before building them.
2. Split that question across separate creatives rather than runtime branches.
3. Name them so the variable under test is readable in a report row.
4. Gate the experience on a real viewability signal so early seconds are not wasted off screen.
5. Fire whatever lifecycle calls the target network expects, so its completion data is accurate.
6. Carry in-ad choices into the click URL where the destination can record them.
7. Judge on the post-install event that reflects why you ran the campaign, not on CTR alone.

None of this is as satisfying as a dashboard of in-ad events, and it is worth being honest that playable measurement is coarser than web measurement and will stay that way. The constraint is not a gap waiting for a clever workaround — it is a deliberate property of the format, and the teams that do best with it are the ones who design experiments the format can actually report on.

Reading the funnel you do get

Impressions, clicks and installs form a three-stage funnel, and the ratios between the stages localise a problem better than any single number does. A low click rate with a healthy click-to-install rate means the creative is not earning attention but converts the people it reaches — a hook problem. A high click rate with a poor click-to-install rate means the opposite: the ad is compelling and the promise is not surviving contact with the store listing.

That second pattern is the one worth watching for, because it usually means the creative is over-promising rather than under-performing. It also tends to reappear later as weak retention, which is the expensive version of the same problem.