Instrumenting a playable: what to measure
Network dashboards report completion and CTA taps. Everything that explains why a playable underperforms has to be built into the build itself.
Network reporting for a playable ad typically gives a studio four numbers: impressions, engagement rate, completion rate, and the click-through to store. That is enough to know whether a playable is working overall and almost nothing about why. A playable that completes at a below-average rate could be losing players in the first two seconds because the load felt slow, or three steps in because a mechanic was unclear, or at the very last screen because the end card's call to action was unclear rather than the game itself. Network dashboards do not distinguish between these, and they are entirely different problems requiring entirely different fixes.
The metrics worth building in
Time to first interaction is the earliest useful signal and the one most playables skip entirely. It measures how long a viewer takes from the playable loading to their first tap, and a long gap here usually means the opening screen failed to make clear what the player is meant to do, not that the mechanic itself is weak. This number should be captured before any gameplay logic runs, as close to the render event as the framework allows.
Step-level drop-off is the metric that actually locates a problem inside a multi-step playable. Rather than a single completion percentage, logging an event at each discrete step, each tap, each screen transition, each decision point, shows exactly where players stop. A playable that loses forty percent of viewers between step two and step three has a step-three problem, and no amount of polishing step one will fix it.
CTA interaction deserves its own event, separate from completion. A viewer can complete a playable's gameplay portion and still fail to engage with the end card, or conversely abandon the gameplay early but tap through on an end card shown after a timeout. Treating completion and CTA engagement as the same event, which some simpler builds still do, hides which half of the playable is actually underperforming.
Session length within the playable, not just whether it completed, helps separate a player who breezed through because the interaction was too easy from one who engaged for a reasonable stretch before dropping off. The two look identical on a completion metric and mean very different things for iteration.
Where network reporting and in-build instrumentation disagree
A network's engagement or completion definition is not always transparent, and different networks measure the same concept differently, some count a completion the moment a player reaches the end card regardless of whether they interact with it, others require an explicit CTA tap. This is why comparing raw completion percentages across networks without checking each one's definition produces conclusions that do not hold up. In-build instrumentation, logged directly by the playable through its own analytics calls rather than relied upon from a network's dashboard, is the only way to get a consistent, comparable measure across every placement a build runs on.
Building the instrumentation without bloating the file
Analytics logging adds weight to a build already fighting a tight file size budget, so events should be batched and sent in as few network calls as possible rather than fired individually per interaction. A lightweight local event queue that flushes at natural break points, end of a step, playable completion, CTA tap, keeps the analytics overhead small enough that it does not compete with the file size discipline this site's earlier work on playable production covered in Playable Ads Are Becoming the Operating System of Mobile UA, which argued that playables now carry enough of the acquisition funnel to be treated with the same rigour as any other measurement surface, not as a lightweight add-on to a video creative slate.
The end result of good instrumentation is not a prettier dashboard. It is a production team that knows which specific screen to redesign next, instead of guessing from a single completion number that could mean five different things.
Sharing the data without duplicating the work
None of this instrumentation needs to live in a bespoke analytics stack. A small, consistent event schema, the same step names, the same interaction labels, applied across every playable a studio produces, lets a measurement team roll up results across concepts and genres without rebuilding a dashboard for each new build. The schema is worth agreeing once, in writing, between the playable production team and whoever owns measurement, precisely because it is the kind of decision that gets made ad hoc under deadline pressure and then quietly diverges build by build until nobody can compare one playable's results against another's with any confidence.
