Children’s privacy

What happens if my kids app collects an advertising ID?

Under COPPA a persistent identifier is personal information, but there is a narrow exception: collecting a persistent identifier and no other personal information, used for the sole purpose of supporting the internal operations of the service, with a notice describing exactly which internal operations and how the identifier is kept from being used to contact or profile anyone. That exception is a COPPA exception only. Google Play is stricter and structural — an app that solely targets children must not transmit the Android advertising identifier at all, and must not declare the AD_ID permission when targeting API level 33 or above, which is visible in your manifest whether or not you ever read the identifier. In a mixed-audience app the same transmission ban covers children and users whose age is unknown. Apple bars sending device information to third parties from a Kids Category app, even from sections intended for adults. So satisfying the COPPA exception does not clear you to ship.

Under COPPA an advertising ID is personal information

A persistent identifier is personal information under the Rule, which is the fact that surprises teams who think of COPPA as being about names and email addresses. Collecting one from a child therefore engages the notice and verifiable-parental-consent machinery in the ordinary way — unless an exception applies. The 2025 amendments widened the definition of personal information further, adding biometric identifiers and government-issued identifiers, so the direction of travel is toward more of what an SDK routinely handles being in scope rather than less.

The internal-operations exception, and how narrow it actually is

The Rule permits collecting a persistent identifier without prior verifiable parental consent where three things hold together. First, you collect a persistent identifier and no other personal information — the exception collapses the moment anything else is collected alongside it. Second, you use it for the sole purpose of providing support for the internal operations of the website or online service, “sole” being the operative word. Third, you give the online notice required by §312.4(d)(3), which must describe the specific internal operations the identifier is collected for and the means used to ensure it is not used or disclosed to contact a specific individual, to build a profile, or for any other purpose — including through behavioural advertising. Read together, this is an exception for making the service work, not an exception for monetising it. An identifier flowing to an ad network to target advertising is outside it by construction.

A second, much narrower identifier exception exists and rarely helps

The Rule also permits collecting a persistent identifier and no other personal information from a user who affirmatively interacts with the service and whose previous registration with that operator indicates they are not a child — but only where the operator is treated as directed to children solely because it has actual knowledge that it collects personal information directly from users of another child-directed service. No §312.4 notice obligation arises in that case. The conditions are specific enough that it is worth checking against the text rather than assuming it fits; it is not a general “we know this user is an adult” carve-out.

Google Play does not have an exception — it has a ban

An app that solely targets children must not transmit the Android advertising identifier (AAID), the SIM serial, the Build serial, the BSSID, the MAC address, the SSID, the IMEI or the IMSI. There is no internal-operations qualifier attached. The prohibition is on transmission, which is a genuinely useful distinction when you plan the work: an identifier read on-device and never sent off it is a different question from one leaving the device, and the evidence that satisfies the rule is a network-level check rather than a code search. Google also states flatly, without limiting it to child-only apps, that the device phone number must not be requested through the Android TelephonyManager API.

The AD_ID permission is a manifest-level check you cannot argue with

An app targeted solely at children should not declare the AD_ID permission when it targets Android API level 33 or above. From API 33 the advertising identifier requires an explicit permission, so this is checkable by reading the manifest — whether or not the identifier is ever actually read at runtime. That makes it one of the cheapest things to get right and one of the most conspicuous to get wrong: a transitive dependency that declares the permission for you puts it in your manifest without a line of your own code, and manifest merging is where this usually goes unnoticed.

Mixed audience: the ban reaches users whose age you do not know

An app targeting both children and older audiences must not transmit those same identifiers from children — or from users whose age is unknown. The unknown-age half is the operative part and the one that changes an architecture. Absent a reliable age signal, the app has to treat the user as a child for these purposes, which would mean disabling the identifiers for the entire user base. That is why a neutral age screen is the usual mechanism: it produces the age signal that lets you satisfy the rule for children without switching identifiers off for every adult too. The same screen typically carries the mixed-audience SDK rule and the ads age-screening rule as well, so one implementation is often the evidence for three duties.

Apple: device information to third parties, adult sections included

A Kids Category app may not send personally identifiable information, or device information, to third parties. Apple states this without the “in limited cases” hedge it attaches to analytics and advertising, and its guidance on designing safe and age-appropriate experiences adds two things that widen it materially: the rule applies even in sections of the app intended for adults, and the only stated route through it is that the parent explicitly consents. So an adult-facing settings or parent area does not escape it, and the exception is parental consent rather than user consent. In practice this, rather than any targeting rule, is what disqualifies a candidate SDK — because an SDK that transmits identifiers off-device is a problem however its serving is configured.

Amazon judges the component, not the identifier

Amazon approaches the same problem from the other end. Where an app is directed only at children and uses SDKs that collect personal information — advertising and analytics SDKs are Amazon’s own examples — each of those SDKs must be child-suitable, meaning it complies with COPPA and other applicable laws. The evidence is per-SDK and specific: an inventory of every component that collects personal information, and for each one the basis on which it was judged child-suitable. A vendor’s general claim of being privacy-friendly is not that basis. Amazon separately bars any SDK whose own terms of service prohibit use in child-directed apps, which is a licence question rather than a technical one. In a mixed-audience app a non-child-suitable SDK may be used only where reasonable measures ensure it collects personal information from adult users alone; Amazon’s example of such a measure is a neutral age screen, and the duty is about the outcome, so the evidence is the gating implementation plus a check that the SDK is genuinely inert on the child path.

What this means for the build

Treat the identifier question as four separate determinations rather than one. Whether the identifier is personal information you have a lawful basis to collect is COPPA. Whether it leaves the device is Google Play, and whether your manifest declares AD_ID is Google Play again. Whether any device information reaches a third party anywhere in the app is Apple. Whether each component that touches it has been individually judged child-suitable is Amazon. An SDK whose ordinary operation depends on the advertising identifier will fail more than one of those, and no configuration flag reconciles them — which is why the honest answer to “can we keep our current ad SDK” is usually a per-store answer with per-store evidence behind it.

These store policies change in place, without notice

None of the three store policies carries a version number or a deprecation notice; the stores rewrite the pages and the new text is simply what binds you. Keel models each against the text retrieved on 13 August 2026, which is why its frameworks carry a retrieval date rather than a version. Google has announced a replacement Families policy taking effect on 26 August 2026; Keel scores the policy in force rather than a published preview, and re-verifies on or after that date. Keel also runs a monthly drift monitor over these source pages, which reports a change for a human to read and never edits framework content on its own. COPPA is different in kind — it is a published federal rule with an amendment history — but check the live text of both before you rely on any of this for a submission.

FAQ