COPPA usually enters the conversation too late.
The team has already designed accounts, analytics, social features, push notifications, ad integrations, and maybe user-generated content. Then someone asks a question that should have arrived much earlier: does this product count as directed to children?
If the answer might be yes, COPPA is not a legal cleanup task. It is a product constraint.
That is because COPPA does not just ask for a privacy policy. It changes what you can collect, when you need parental consent, what your third-party tools are allowed to do, and how much operational overhead you are willing to carry for a child-directed product.
It is not just for obvious kids’ apps
The FTC’s COPPA FAQ makes clear that whether a site or service is “directed to children” depends on a mix of factors: subject matter, visual content, animated characters, child-oriented incentives, music, language, audience evidence, and whether advertising on the service is directed to children.
That matters because teams still use a very narrow test:
“We are not a kids app.”
That is not enough.
The FTC’s guidance on COPPA not just for kids’ sites is explicit that COPPA can also apply to general-audience services with actual knowledge they are collecting personal information from children under 13. It can also reach third parties like ad networks and plug-ins collecting information from users of child-directed services.
So the real product question is not only “who did we intend to build for?” It is also “what signals does the product send, what do we ask users, and what do our integrations collect?”
Mixed audience is not a free pass
One of the more useful parts of the FTC FAQ is its discussion of mixed-audience services.
If a service targets children under 13 but children are not the primary audience, there is a narrow path where the operator can age-screen users. But the FTC is specific about the conditions: you cannot collect personal information before collecting age information, and you must prevent collection, use, or disclosure of personal information from users who identify themselves as under 13 unless you first comply with notice and parental consent requirements.
That changes onboarding.
Age-gating is not a decorative screen to make the policy team feel better. If the flow asks for email, username, device identifiers, social login, or other personal information before the age signal is handled properly, the design is already on weak ground.
Teams like mixed-audience arguments because they sound like flexibility. In practice they require more discipline, not less.
”Actual knowledge” is easier to trigger than teams think
Many teams act as if they only have a COPPA problem once a child openly says, “I am 11.”
The FTC’s guidance says the picture is broader. A general-audience operator can have actual knowledge if it asks for and receives age information showing the user is under 13. The FTC also points to age-identifying questions like grade level or school type. Third parties can have actual knowledge too, depending on what the child-directed service tells them or what they clearly know from the surrounding context.
That creates risk in very normal product ideas:
- date-of-birth fields
- school-grade onboarding
- elementary-school classroom products
- child profiles inside family apps
- integrations that know they are embedded in a child-directed service
The dangerous mistake is pretending that this information is only for “segmentation” or “personalization.” If the data makes age obvious, the compliance consequences do not disappear because product called it something else.
Parental consent is a product system, not a checkbox
COPPA’s central rule is simple: if covered operators collect personal information from a child, they generally need verifiable parental consent first unless a limited exception applies.
The important word is verifiable.
The FTC’s page on verifiable parental consent says the rule does not mandate one method, but the chosen method must be reasonably designed, in light of available technology, to ensure the person giving consent is the child’s parent.
That has immediate product consequences:
- the consent flow needs real identity assurance
- the notice content has to be accurate
- the child account state has to depend on consent state
- parental controls and ongoing management need a home in the product
The FTC FAQ is also clear that weak shortcuts are not enough. For example, a bare app-store password on its own does not reliably show that the person entering it is the parent rather than the child.
This is why COPPA pushes teams toward simpler products. A feature that sounds manageable in a general app can become expensive once it needs parental notice, verifiable consent, state transitions, auditability, and support handling.
Every SDK creates a bigger COPPA surface
This is where a lot of child-directed products get themselves into trouble.
Teams think of COPPA as applying to their own forms and account data, while the real collection surface may include analytics SDKs, ad networks, embedded video players, social plug-ins, identity tools, and push providers.
The FTC is direct about third parties. If you run a third-party service like an ad network or plug-in and collect information from users of a child-directed service, you may be covered too. The main FTC FAQ also walks through how persistent identifiers, plug-ins, and internal-operations exceptions work.
The practical product lesson is that every embedded tool needs a separate question:
- what information does it collect?
- does it collect persistent identifiers?
- is the use truly internal operations, or something broader?
- does it support behavioral advertising, profiling, or broader disclosure?
- can the product work without it?
The FTC’s January 2025 announcement on final changes to the COPPA Rule pushes in the same direction. The agency highlighted separate parental consent for certain third-party disclosures tied to targeted advertising, tighter retention limits, and a broader view of what counts as personal information.
That is not a signal to get better at legal wording. It is a signal to reduce unnecessary collection and unnecessary third parties.
The cheapest compliance move is to avoid collecting data
This is the most practical product insight in the whole article.
If a child-directed service can work without accounts, profiles, public posting, chat, social features, ad tracking, or cross-service behavioral data, then every one of those things you remove makes COPPA easier.
That does not make the product less serious. It usually makes the scope more honest.
The teams that struggle most with COPPA are often trying to preserve product patterns borrowed from adult apps:
- social profiles
- public comments
- direct messaging
- targeted ads
- broad analytics collection
- open-ended content creation without strong controls
Each of those can be done, but each one raises the cost. If the feature is not central, remove it.
Parents create operational work whether you planned for it or not
COPPA is not only about collection at signup. It also creates an ongoing relationship with the parent.
The FTC expects privacy notices, direct notice to parents, parental consent where required, and parental rights around children’s information. The 2025 FTC announcement also emphasized deletion and retention obligations.
For product teams, that means parents need more than a policy link. They need:
- clear notices
- a way to manage consent
- a way to review or delete relevant information
- support flows that know what a child account is
- retention rules that actually delete what should not be kept
If the product cannot answer “what happens when a parent asks what we have and wants it removed?”, the implementation is not finished.
The lesson
COPPA does not just regulate what you say about a child-directed product. It changes what features are worth building in the first place.
Figure out early whether the service is child-directed, mixed-audience, or general-audience with actual-knowledge risk. Treat age signals carefully. Assume third-party tools are part of the compliance surface. Do not design parental consent like a thin checkbox layer on top of an adult product pattern.
The simpler truth is usually the cheaper one: collect less, rely on fewer SDKs, avoid unnecessary social and advertising features, and make the parent flow a first-class part of the product if children are in scope.