What If Kids Use My App and I Did Not Build It for Them?
“We are not a kids’ app” is the answer most founders give, and they believe it.
I believe it too. I have never checked whether my own support inbox already tells a different story, or what happens the moment it does.
What Triggers COPPA Obligations?
The Children’s Online Privacy Protection Rule at 16 C.F.R. Part 312 applies to operators of services directed to children, and to operators with actual knowledge that they are collecting personal information from children. A Child means an individual under the age of 13.
Whether a service is directed to children is a multi-factor assessment, not a declaration you make about yourself. The Rule directs consideration of subject matter, visual content, use of animated characters or child-oriented activities, music or audio content, the age of models, the presence of child celebrities, and whether advertising on the service is directed to children. It also considers competent and reliable empirical evidence about audience composition and evidence about the intended audience.
How Do You Acquire Actual Knowledge by Accident?
This is the dangerous route in, because it does not require you to go looking. If a user tells you their age, if a parent emails support about their child’s account, or if a ticket says “my daughter is 11 and she cannot log in,” you may have acquired knowledge you never sought.
Once acquired, obligations can follow. The fact that you never wanted the information is not a defense, and the record sits in your help desk, searchable and timestamped, answered by a team that had no idea it mattered beyond the technical issue.
What Do the Obligations Actually Require?
Where the Rule applies, the requirements are substantive rather than cosmetic. Verifiable Parental Consent is required prior to any collection, use, or disclosure of personal information from a child, subject to limited exceptions set out in the Rule.
Related obligations cover what may be collected and why, parental access and deletion rights, and retention. None of this is satisfied by adding a line to your privacy policy.
Common Mistakes Founders Make
- Relying on a terms-of-service age requirement. A line stating users must be 18 does not control if the facts show otherwise, and it does not undo knowledge already acquired elsewhere.
- Not training support to recognize the signal. Support is the likeliest place for age information to arrive. Without instruction to escalate, they will resolve the ticket helpfully and the record will simply sit there.
- Assuming intent is the test. “We did not build it for kids” is a fact that matters in the analysis. It is not by itself the answer.
A Quick Founder Check
- Do we have data suggesting minors use our product, from analytics, support tickets, app store reviews, or social media?
- Has anyone searched our support system for messages referencing a user’s age?
- Do we collect date of birth or age anywhere, and what do we do with it?
- Do behavioral advertising or third-party analytics SDKs run on accounts that might belong to minors?
- Do our marketing imagery and channels reach an audience including minors?
- Has support been given any instruction about escalating age information?
- If we learned tomorrow that a user was 11, does a written process exist?
The Bottom Line
The first step is almost always a search of your own support inbox and analytics, because most companies in this position already have the answer sitting in their systems and have simply never looked for it. It is much easier to handle at 2,000 users than at 200,000.
Download the Data Mapping Worksheet to inventory what you collect and from whom, which is the necessary starting point for any assessment here: https://primumlaw.com/primumlawgroup/data-mapping-worksheet/