Privacy questions about playable ads usually arrive in the wrong shape: someone asks whether the creative needs a consent banner, or whether it can drop a pixel. Both have the same answer: the creative is the last and least privileged thing in the chain. Almost every decision about consent and tracking has already been made by the time your HTML file is rendered, by parties you have no contract with.
That is mostly good news. It also means the small number of privacy risks that do live inside the file are easy to overlook, because everyone assumes the layer above handled it.
Who consents to what
Four layers, in order. The publishing app collects consent, through its own consent management platform, before any ad is requested. The mediation and network layer receives that consent signal and decides what can be used for targeting and measurement. The measurement layer (the attribution framework and the advertiser's measurement partner) operates within it. The creative renders inside a container at the end of that chain.
The creative is not a party to the consent decision and cannot obtain consent of its own. A consent prompt inside a playable would be both meaningless and, in most containers, prohibited. If your creative appears to need one, the design has gone wrong somewhere upstream.
The consent signal, and where it lives in an app
In Europe the operative mechanism is the IAB Europe Transparency and Consent Framework. Version 2.3 became the required version from 28 February 2026: TC strings created after that date must carry the new disclosedVendors segment, which records the vendor IDs actually shown to the user in the consent interface, and strings created after that date without it are invalid. Strings created before it remain valid.
In an app environment the string is not passed to the creative. Vendors read it from the operating system's shared storage (the IABTCF_ keys in NSUserDefaults on iOS and SharedPreferences on Android) which is a place an HTML creative in a webview has no access to. That is the concrete reason a playable cannot make its own consent decisions: it cannot see the signal.
iOS: ATT, SKAdNetwork and AdAttributionKit
App Tracking Transparency is the consent layer Apple placed in front of the advertising identifier: an app must show the system prompt before accessing the IDFA or tracking a user across other companies' apps, and Apple enforces it at App Store review. Most users decline, and device-level attribution now covers a minority of iOS traffic: measurement partners have reported figures around one in ten.
What replaced it is aggregated. SKAdNetwork provides delayed, aggregated postbacks rather than user-level data, and Apple has moved on to AdAttributionKit as its successor, introduced with iOS 17.4 and extended since; there will be no SKAdNetwork 5.0, and the two frameworks can operate alongside each other. AdAttributionKit adds things SKAdNetwork handled poorly, including re-engagement measurement, configurable attribution windows and support for alternative app stores.
None of this is implemented in the creative. It matters to a creative team for one reason: creative-level attribution on iOS is a property of campaign structure rather than something the ad file can report, which is why the measurement design has to be settled before the creatives are built rather than after.
What the creative cannot do
A compliant playable makes no network requests. That is a packaging rule, imposed for size and reliability reasons rather than privacy ones, and it happens to eliminate most of the privacy surface as a side effect. No tracking pixel, no analytics beacon, no remote configuration, no font from a CDN, no error reporting endpoint.
The practical consequence is that anything the creative learns stays in the creative unless it is passed out through the container's own API, and those APIs carry event signals rather than user data. If a proposed measurement plan requires the ad to send something somewhere, the plan is not implementable in this format.
The four risks that do live in the file
Each of these has shipped in real creatives, and each survives casual review because the file looks like it is doing nothing.
- A third-party snippet pasted in for measurement. A vendor tag copied from a display workflow will attempt an outbound request. It will usually be blocked by the container or caught in review, and where it is not, it is an undisclosed vendor processing data on an impression whose consent string it never saw.
- Identifiers appended to the CTA URL. The store-exit link is the one thing the creative sends outward. Query parameters describing the user rather than the campaign turn a click into a data transfer, and they persist into the destination's logs.
- Form fields. A creative that asks for an email address, a postcode or an age is collecting personal data inside an ad container, with no privacy notice, no lawful basis established and no way to honour a later deletion request. Lead capture belongs on a landing page.
- Fingerprinting by accident. Canvas measurement, font enumeration and precise device probing are sometimes written for legitimate reasons: picking a rendering path, choosing an asset resolution. The techniques are indistinguishable from fingerprinting, they are increasingly blocked at the platform level, and they are worth avoiding in favour of the feature checks the browser exposes directly.
The rule to hand a creative team
The playable is a rendering surface, not a data collector. It receives no user data, stores none, and sends none. Everything it needs to know arrives as a build-time configuration value; everything it needs to report goes out through the container's own event API. Any requirement that does not fit that shape is a requirement for a different part of the stack.
Children's audiences are a separate regime
If the app is directed at children, the analysis above is not sufficient. Personalised advertising is restricted or prohibited outright, the platform families policies impose their own creative rules, and the standard is what the app is directed at rather than who happens to be using it. Those obligations are covered in a separate guide.
A short review checklist
- Search the exported file for any absolute URL that is not the store link.
- Read the store link's query string and confirm every parameter describes the campaign, not the person.
- Confirm there are no input fields of any kind in the creative.
- Confirm no third-party tag was pasted in during production.
- Confirm nobody added device probing to solve a rendering problem.
- Confirm the file size and the absence of outbound requests, since both are checked by the network anyway.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker