Apple and Google can identify child-configured devices, but Pixalate identified 12 large developers of child-directed apps whose ad requests did not transmit child-directed flags to ad partners—enabling downstream collection of IP address, location, and other device signals that can be used for fingerprinting.
Apple & Google do not provide clear and reliable labeling of apps that may be child-directed across all apps, nor do they provide developers with a notification mechanism that identifies when a child-configured device is accessing the developers' apps. This gap can lead to ad SDKs (software development kits) freely collecting device identifiers, rich attributes, and other environment signals of children.
Apple and Google lack a universal, verified "Child-Directed" designation visible to all partners. Instead, there's patchwork system in which only some apps are clearly categorized as for-kids.
Apple and Google know when a device is child-configured, but they do not automatically pass this 'Child Device' status to the apps installed on that device, leaving developers blind to who is holding the phone.
Audience status is self-declared by developers and is not routinely audited by the app stores. Downstream ad platforms typically trust these flags; Pixalate commonly observes that when the COPPA flag is set to false, user data is processed as general-audience traffic.
Age gates are easily bypassed, and apps rarely require Verifiable Parental Consent (VPC)—such as a credit card or ID check—meaning a child can grant permission to track data without a parent ever knowing.
A few ad SDKs override missing or incorrect COPPA flags using their internal child-app lists, but most SDKs observed by Pixalate rely on developer-provided settings and do not correct these misconfigurations.
Because the safety flags are missing, apps broadcast children's IP addresses and location data to ad partners while treating the child's device as if it belongs to an adult.
Click on any developer portfolio to explore reviewed app(s) and see which apps are at risk of transmitting children's personal information without verifiable parental consent (VPC) alongside user attributes and potential fingerprinting signals.
This research endeavors to highlight systemic child-safety risk conditions that online safety and privacy regulators have previously cited as points of contention in enforcement actions, without making specific determinations of legal compliance. No assertions or determinations are made regarding whether any identified app developer(s) or associated partner(s) is legally compliant with, or in violation of, the Children’s Online Privacy Protection Act (COPPA).
Any references to parent ownership, or majority-ownership are shared solely for the purposes of corporate context and should not be construed as implying parent-ownership level operational involvement in, or control over, app-level data processing and compliance practices.
KYD is about developer-level accountability: ad partners need developers to clearly notify them when child traffic enters the app ecosystem. Pixalate's analysis examines whether child-directed signaling parameters (e.g., the coppa=1 flag in ad requests) are transmitted alongside device and environment signals observed from these likely child-directed apps. This research does not argue that app stores are the sole responsible party, but demonstrates how current store-level design choices amplify downstream compliance failures.
FTC v. HyperBeard Inc., No. 3:20-cv-03683 (N.D. Cal.) FTC Complaint link
In its action involving HyperBeard, the Federal Trade Commission (FTC) alleged COPPA violations based on claims that the app developer did not adequately signal that certain apps were child-directed and failed to appropriately limit targeted advertising.
As federal and state lawmakers advance proposals that would make app stores responsible for age assurance and parental consent, the largest app-store operators have pushed back—warning that store-level mandates could drive broad collection and sharing of sensitive age data, and advocating approaches that rely more heavily on parental controls and developer-side implementation. Our findings highlight the core weakness in that model: when child-status or age-related signals do not propagate reliably end-to-end across the app ecosystem, shifting obligations to parents and downstream developers predictably creates enforcement gaps at the handoff points, reducing the real-world effectiveness of the protections policymakers intend.
Apps transmit IP addresses, user agents, and device models to ad/attribution network partners without a child safety flag (e.g., coppa=true) and consequently treat the user as a general-audience app user. This practice also permits cross-app/device tracking that can be used to amass profiles on misidentified child app users and goes beyond COPPA’s “internal operations” limit, leaving the developer exposed due to such misconfigurations. Furthermore, under COPPA § 312.2(11), ‘information concerning the child…that the operator collects online from the child and combines with an identifier’ constitutes personal information that requires parental consent. Failing to notify downstream partners via appropriate child safety flags allows this type of tracking to proceed as if the app user were an adult, creating a significant risk of COPPA non-compliance.
All data is derived from Pixalate's Know Your Developer database, which provides risk ratings for 356,095 developers across Google Play and Apple App Store.
Under COPPA, IP addresses, geolocation, and other persistent identifiers constitute personal information. Operators collecting children's personal information must obtain Verifiable Parental Consent (VPC) prior to any collection of personal information.
All 12 in-scope apps are likely child-directed, have U.S.-based traffic, did not observe VPC during testing, and transmit IP and/or geolocation coordinates in the programmatic advertising bidstream, according to Pixalate's data.
Pixalate’s Mobile Application Know Your Developer Ratings (“KYD”) reflect Pixalate’s opinions that Pixalate believes may be useful to parents, guardians, educators, regulators, researchers, and participants in the digital media industry. Any data shared is grounded in Pixalate’s proprietary technology and analytics, which Pixalate is continuously evaluating and updating. Any references to outside sources should not be construed as endorsements, affiliations, or associations with any third-parties. Pixalate is sharing this data not to impugn the standing or reputation of any entity, person or app, but, instead, to report research findings and trends pertaining to the time period studied.
It is important to note however, that classification of a mobile application developer (“app developer”) within a particular risk tier does not mean that the app developer, its applications, or any associated practices are in violation of any laws or regulations, including the Children’s Online Privacy Protection Act (COPPA) or any other global privacy framework. Further, the app(s) of an app developer(s) that appear(s) to be directed to children (e.g., users under 13 years of age, as defined by the COPPA Rule) does not mean that any such app, or its operator, is failing to comply with the COPPA Rule.
Pixalate’s determinations are based on a proprietary methodology that incorporates a combination of signals and automated processes. Additionally, with respect to app developers that appear to have characteristics that, in Pixalate’s opinion, may trigger related privacy law or regulatory compliance obligations and/or risk, such assertions reflect Pixalate’s opinions i.e., they are neither facts nor guarantees. While Pixalate endeavours to apply rigorous standards in compiling this KYD, no assurances or guarantees can be, or are, made as to the accuracy or completeness of any classification. This article/expose, including all content set forth herein–constitutes Pixalate “Materials” under Pixalate’s Terms of Use, and is licensed subject to–and conditioned expressly upon–compliance with each of the applicable terms and conditions of such Pixalate Terms of Use. Per the MRC, “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes. Also per the MRC, “‘Invalid Traffic’ is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.”.
Apple and the Apple logo are trademarks of Apple Inc; Google, Google Ad Exchange, the brand “Google Play,” its logos, and other Google logos are trademarks of Google LLC. These companies are not affiliated with, nor do they endorse or sponsor, any products, data, content, reports, materials or services associated with Pixalate. Any other brand logos, names, or trademarks not explicitly mentioned herein – but otherwise mentioned, displayed, or used in any of Pixalate’s materials, including this report – are the property of their respective owners.
The headline and subheader tells us what you're offering, and the form header closes the deal. Over here you can explain why your offer is so great it's worth filling out a form for.
Remember:
Contact
Offices
Disclaimer: The content of this page reflects Pixalate’s opinions with respect to the factors that Pixalate believes can be useful to the digital media industry. Any proprietary data shared is grounded in Pixalate’s proprietary technology and analytics, which Pixalate is continuously evaluating and updating. Any references to outside sources should not be construed as endorsements. Pixalate’s opinions are just that - opinion, not facts or guarantees.
Per the MRC, “'Fraud' is not intended to represent fraud as defined in various laws, statutes and ordinances or as conventionally used in U.S. Court or other legal proceedings, but rather a custom definition strictly for advertising measurement purposes. Also per the MRC, “‘Invalid Traffic’ is defined generally as traffic that does not meet certain ad serving quality or completeness criteria, or otherwise does not represent legitimate ad traffic that should be included in measurement counts. Among the reasons why ad traffic may be deemed invalid is it is a result of non-human traffic (spiders, bots, etc.), or activity designed to produce fraudulent traffic.”
