Children's Privacy Compliance Checklist: Audience Analysis, Age Gates, Parental Consent, Data Minimization, and Ad Tech

By Casey Scott McKay · 2024-03-18

This checklist audits a product for children's privacy exposure and then remediates it, starting where enforcement actually starts rather than where the statute begins. Phase one is a network traffic capture, because identifier transmission from a child-directed surface is observable by anyone with a proxy and is the basis of most enforcement. It then forces the audience determination memo, runs the internal searches that surface actual knowledge the company already has in writing, and specifies an age screen that supports a defense instead of undermining it. It walks the verifiable parental consent flow screen by screen, the parent dashboard, and the retention regime including derived segments and trained models. It separates the teen cohort as its own state-law workstream, handles school deployments, and closes with vendor operator terms and the release checklist that keeps the fix from silently reverting.

IP and Technology > Privacy Data Security | Checklist | Published 18 March 2024 - Updated 30 April 2026 | Casey Scott McKay - marksy.us

Summary. This checklist audits a product for children's privacy exposure and then remediates it, starting where enforcement actually starts rather than where the statute begins. Phase one is a network traffic capture, because identifier transmission from a child-directed surface is observable by anyone with a proxy and is the basis of most enforcement. It then forces the audience determination memo, runs the internal searches that surface actual knowledge the company already has in writing, and specifies an age screen that supports a defense instead of undermining it. It walks the verifiable parental consent flow screen by screen, the parent dashboard, and the retention regime including derived segments and trained models. It separates the teen cohort as its own state-law workstream, handles school deployments, and closes with vendor operator terms and the release checklist that keeps the fix from silently reverting.

Keywords: network traffic capture · software development kit inventory · audience determination · directed to children factors · actual knowledge search · age screen design · verifiable parental consent · direct notice · parent dashboard · internal operations exception · contextual advertising · retention per element · derived data deletion · teen cohort · design code tracking · education deployment · vendor operator terms · safe harbor · enforcement response · release checklist

How to use this checklist

| Phase | What it covers | |---|---| | 1 | The network traffic capture | | 2 | Software development kit inventory | | 3 | The audience determination memo | | 4 | Actual knowledge searches | | 5 | The age screen | | 6 | Age assurance proportionality | | 7 | The parent contact step | | 8 | The direct notice | | 9 | Verification method selection | | 10 | The parent dashboard | | 11 | Consent logging and failure paths | | 12 | Monetization rebuild | | 13 | Retention per data element | | 14 | Derived data and models | | 15 | The teen cohort | | 16 | Design code tracking | | 17 | Education deployments | | 18 | Vendor operator terms | | 19 | Safe harbor assessment | | 20 | Enforcement response | | 21 | The release checklist | | 22 | Ownership and annual cycle |

Boxes marked [Gate] must clear before the product collects anything from a user who may be a child.

The matter. A general-audience mobile game with fourteen million installs, marketed as "for all ages," discovered after a published traffic analysis that three advertising kits transmitted device identifiers on launch, that four hundred and twelve support tickets stated an age under thirteen, and that a product research deck described a persona named "Maya, age 10."

Phase 1. The network traffic capture

[ ] [Gate] Put a proxy in front of a test device with the certificate trusted at system level, or use the platform's network inspector.
[ ] Start from a clean install with no prior state.
- Why. Identifiers persisted from an earlier session hide the launch behavior, which is the behavior that matters.
[ ] [Gate] Capture the cold launch first. Many kits transmit on initialization, before any consent screen appears and before any user action.
- Why. This is the most common finding and the most damaging, because transmission happened before the user could have been screened.
[ ] Walk every surface — onboarding, the age screen itself, main experience, settings, purchase flows, and web views, which are routinely forgotten and carry their own tags.
[ ] Record per call: destination host, whether it is a known advertising or analytics endpoint, and payload fields — advertising identifier, vendor identifier, IP address, device model, locale, event and screen names, and any user-supplied values.
[ ] [Gate] Flag every persistent identifier leaving a surface that could be child-directed.
- Why. Under 16 C.F.R. § 312.2, a persistent identifier usable to recognize a user over time and across services is personal information.
[ ] Repeat on the web property, especially pages with video content, given 18 U.S.C. § 2710.
[ ] Write it up as a dated before-and-after table. This becomes the remediation record and the most valuable exhibit in an inquiry.

Phase 2. Software development kit inventory

[ ] List every advertising, analytics, attribution, crash, and support kit in the build.
[ ] Reconcile against the traffic capture. They will not match; there is almost always a kit nobody listed.
[ ] [Gate] Remove unlisted kits immediately.
[ ] Enable child-directed or limited-data mode where it exists — correctly, on every surface, on every release.
[ ] [Gate] Verify by re-capture. Vendor documentation is not evidence; the capture is.
- Trap. Several kits document a limited-data mode that suppresses some fields and not others.
[ ] Replace kits with no such mode with a contextual-only provider.
[ ] Add a build-time check: any new advertising or analytics dependency fails the build until registered with an owner and a child-directed configuration.

Phase 3. The audience determination memo

[ ] [Gate] Choose one of three answers, in writing, dated: directed to children, mixed audience, or general audience with an actual-knowledge risk.
[ ] Work each 16 C.F.R. § 312.2 factor: subject matter; visual and audio content including animated characters and bright palettes; child-oriented activities and incentives such as collectibles and virtual pets; music and language including reading level; age of models and use of child celebrities; the advertising carried; and empirical evidence of audience composition.
[ ] Look at the analytics before writing the conclusion.
- Why. The empirical factor is the one most likely to contradict the company's stated position, and it is discoverable.
[ ] Name a decision-maker and date it.
[ ] Refresh on material product change, marketing change, or analytics shift.
[ ] Remember why the memo matters more than the conclusion. A regulator's first question is how the determination was made, and "nobody made it" is the worst answer.

Phase 4. Actual knowledge searches

[ ] [Gate] Search support ticket text for stated ages, "my son," "my daughter," "my kid," grade levels, and school names.
[ ] Search profile fields for birth years implying a user under thirteen.
[ ] [Gate] Search analytics and research documents for age breakdowns, "kids" segments, and personas.
- Why. A persona named for a ten-year-old is actual knowledge in written form, produced by the company. This is the most damaging category.
[ ] Search marketing briefs and media plans for children as a target or channels with documented child audiences.
[ ] Check app store listings — age rating, reviewer comments, platform-supplied demographics.
[ ] Collect parent communications of any kind.
[ ] Ask support staff whether the users seem young, and note that a written answer is knowledge.
[ ] Handle what you find. Knowledge cannot be un-learned, deliberate ignorance is not a defense, and the data already collected must be consented to or deleted under 16 C.F.R. § 312.10.

Phase 5. The age screen

[ ] [Gate] Neutral. Ask for date of birth without displaying a minimum age first.
- Trap. Showing "you must be 13" before the question teaches the user what to answer.
[ ] [Gate] Non-retryable. Persist the answer against the device or account.
[ ] Placed before collection, not after the first session.
[ ] Define the under-thirteen path: stop collection, delete data from that session, and either route to parental consent or decline with an explanation.
[ ] Do not allow immediate re-registration with a different birth year.
[ ] Understand its limits. The screen supports a no-actual-knowledge defense for users declaring an older age. It does not convert a child-directed service into a general-audience one.

Phase 6. Age assurance proportionality

[ ] Match the method to the risk. Self-declaration is unreliable; document verification excludes users and creates a sensitive-data problem; behavioral inference is intrusive and error-prone.
[ ] [Gate] Do not collect more identity data than the risk warrants. The verification data is itself sensitive.
[ ] Document the reasoning for the method chosen.
[ ] Delete verification artifacts promptly where an identification document is used.
[ ] Watch the biometric dimension of facial matching, which carries separate state exposure. See the Biometric Data Checklist.

Phase 7. The parent contact step

[ ] [Gate] Collect only the parent's email address at this step, which 16 C.F.R. § 312.5(c) permits for the purpose of obtaining consent.
[ ] Collect nothing about the child — not a name, not a birthday, not a photograph.
[ ] Delete the parent's address if consent is not obtained within a reasonable time.
[ ] Log the request and the deletion.

Phase 8. The direct notice

[ ] [Gate] Meet 16 C.F.R. § 312.4: that the operator wishes to collect from the child; that consent is required; what is collected; how it is used; whether it is disclosed and to whom; that the parent may review and refuse further collection; and how to consent.
[ ] Write it for a parent on a phone in ninety seconds — plain language, collection as bullets.
[ ] State the internal-operations posture plainly — no targeted advertising to the child, no sale, no sharing.
[ ] Name the parent dashboard and a contact address.
[ ] Confirm participation is not conditioned on more information than the activity reasonably needs, per 16 C.F.R. § 312.7.
[ ] Version it. The notice consented to is the notice that governs.

Phase 9. Verification method selection

[ ] [Gate] Choose a method meeting 16 C.F.R. § 312.5 — a reasonable effort, given available technology, to ensure the consenter is the parent.
[ ] Payment-card notification. Fast and high-completion; excludes parents without cards. Requires actual notification, not merely a captured card number.
[ ] Signed form return. Universal, slow — build it as a fallback so nobody is excluded.
[ ] Telephone or video call with trained personnel. Higher friction, highly defensible; reserve video for sensitive collection.
[ ] Government identification against a database, with prompt deletion.
[ ] Knowledge-based challenge, sufficiently difficult that a child in the household could not answer.
[ ] Email-plus only where information is used internally and not disclosed.
- Why. Choosing email-plus is choosing a monetization model, because any third-party disclosure removes the method.
[ ] Build one high-completion method plus one universal fallback, and log which was used.

Phase 10. The parent dashboard

[ ] [Gate] Build authenticated parent identity, separate from the child's account.
- Why. This is the architectural decision that makes everything else possible, and retrofitting it later means adding an identity system to a product that has none.
[ ] Show what was collected, in categories a parent understands.
[ ] Provide refuse-further-collection, with a clear statement of the consequence for the account.
[ ] Provide deletion, covering production, analytics, derived segments, and vendors — per 16 C.F.R. § 312.6.
- Trap. A delete control that removes the account row and leaves the analytics copies documents a promise the company did not keep.
[ ] Show the consent record — notice version, method, date.
[ ] Reachable without the child's device.
[ ] Log every dashboard action.
[ ] Test it end to end by someone not on the team that built it.

Phase 11. Consent logging and failure paths

[ ] [Gate] Log which parent consented, to which notice version, by which method, at what time, for which child account.
[ ] No consent given — delete the parent's contact information and do not collect from the child.
[ ] Consent revoked — stop collection, delete on request, confirm.
[ ] [Gate] Material change in practices — obtain fresh consent. Posting an updated notice is not consent.
[ ] Retain consent records long enough to defend, and segregate them from operational data.

Phase 12. Monetization rebuild

[ ] [Gate] Confirm what is available under the internal-operations exception: contextual advertising selected by content; frequency capping and delivery measurement; analytics for service operation; authentication and preferences; security and fraud prevention.
[ ] [Gate] Confirm what is not: behavioral or interest-based advertising; audience segmentation and lookalike modeling; cross-service profiling; sales or sharing with advertising platforms; retargeting anywhere.
[ ] Model the revenue delta and present it in month one.
- Why. Contextual monetizes materially below behavioral. A project that surfaces this in month six does not survive.
[ ] Consider subscription or direct payment, which sidesteps the question entirely.
[ ] Give growth the boundary as a number, not as "consult legal."

Phase 13. Retention per data element

[ ] [Gate] State a purpose per data element.
- Why. 16 C.F.R. § 312.10 measures "reasonably necessary" against a purpose, and an undefined purpose has no endpoint.
[ ] State a retention period per element, with reasoning.
[ ] Build automated deletion on a schedule, with evidence it ran.
[ ] Delete on account closure and on revocation.
[ ] Delete on inactivity.
- Trap. A dormant child account holding data for six years is the fact pattern regulators cite.
[ ] Instruct vendors to delete, and record confirmation.
[ ] Trace one account end to end as the scoping exercise: where every piece of its data lives, and when each is deleted.

Phase 14. Derived data and models

[ ] [Gate] Treat profiles, segments, and inferences built from a child's data as that child's data.
[ ] Delete derived segments when the source is deleted.
[ ] Scope model exposure. Enforcement orders have increasingly required deletion of models and algorithms trained on unlawfully collected children's data.
[ ] Record which models were trained on which datasets, because without that record the remediation scope cannot be bounded.
[ ] Exclude children's data from training sets going forward, and evidence the exclusion.

Phase 15. The teen cohort

[ ] [Gate] Run it as a separate workstream, because the federal rule stops at thirteen and almost nothing else does.
[ ] Check state opt-in requirements, including Cal. Civ. Code § 1798.120 for consumers known to be under sixteen.
[ ] Treat known children's data as sensitive under statutes like Colo. Rev. Stat. § 6-1-1308 and Va. Code § 59.1-577.
[ ] [Gate] No behavioral advertising to known teens. The highest-risk practice and the first question in an enforcement letter.
[ ] Set high-privacy defaults — geolocation off, profiling off, no public-by-default profiles, restricted adult discoverability.
[ ] Prefer defaults over disclosures, since teens do not read notices.
[ ] Build a separate data map for the thirteen-to-seventeen cohort.
[ ] Do not avoid screening to avoid knowledge. That is the deliberate-ignorance posture that reads worst in an investigation.

Phase 16. Design code tracking

[ ] Track the state design codes as a moving workstream, not as settled law.
[ ] Note the litigation posture. California's provisions at Cal. Civ. Code § 1798.99.31 were substantially enjoined in NetChoice v. Bonta, with similar challenges elsewhere and Moody v. NetChoice supplying the framework.
[ ] Build the overlapping good practice regardless: high-privacy defaults for minors, no precise geolocation by default, no profiling of minors, plain-language terms, and no dark patterns nudging toward lower privacy.
[ ] Review status annually and decide on any provision that has come into force.

Phase 17. Education deployments

[ ] [Gate] Confirm school consent is available — service used solely for an educational purpose, collection limited to that purpose, no commercial use.
[ ] Check education records obligations under 20 U.S.C. § 1232g.
[ ] Check state student-data statutes prohibiting targeted advertising to students, non-educational profiles, and sale of student data — Cal. Bus. & Prof. Code § 22584 is the model.
[ ] [Gate] Ship a separate education build with no advertising kits and analytics limited to service operation.
[ ] Put a district-facing data processing agreement in place, with deletion on contract termination.
[ ] State plainly that no student data is used commercially.

Phase 18. Vendor operator terms

[ ] [Gate] Require acknowledgement of operator status where the vendor collects from a child-directed surface, per 15 U.S.C. § 6501.
[ ] Limit use to support for internal operations, with express prohibitions on contacting an individual, behavioral advertising, and profile building.
[ ] Prohibit onward disclosure and combination with other sources.
[ ] Require a configuration commitment described by field, not by feature name, so it can be tested.
[ ] [Gate] Reserve verification rights — the right to test by traffic capture and require remediation within a stated period.
[ ] Require deletion on instruction and termination, covering derived data, with written confirmation.
[ ] Require notice of any change to what the kit transmits.
[ ] Accept refusal as the answer. A kit whose vendor will not agree cannot be used on a child-directed surface.

Phase 19. Safe harbor assessment

[ ] Consider a program approved under 16 C.F.R. § 312.11 for genuinely child-directed services, particularly smaller ones.
[ ] Understand what it buys — structure, expertise, an external deadline, and evidence of good faith.
[ ] Understand what it does not — immunity.
[ ] Skip it for a general-audience service managing an actual-knowledge risk; it addresses a different problem.
[ ] Do the work either way, since the assessment checklist is a good proxy for what an inquiry examines.

Phase 20. Enforcement response

[ ] Preserve immediately.
[ ] [Gate] Run the Phase 1 capture and the Phase 4 searches before answering, because you need to know what a regulator will find.
[ ] Produce records rather than characterizations.
[ ] Fix what the inquiry reveals, with dates.
[ ] Assemble the single most valuable exhibit: a dated remediation record showing identifier transmission stopped before any letter arrived.
[ ] Expect penalties per violation under 15 U.S.C. § 6505 and 15 U.S.C. § 45, and orders that may require deletion of data and models.
[ ] Note that 47 U.S.C. § 230 does not apply — it concerns liability for third-party content, not the operator's own collection.

Phase 21. The release checklist

[ ] Traffic capture on every release, not every quarter.
- Why. Kit configurations silently revert on upgrade more often than anyone expects, and the second finding is always worse than the first.
[ ] Dependency check — no new advertising or analytics kit without an owner and a child-directed configuration.
[ ] Age screen regression test for retry and for leading language after any onboarding change.
[ ] Notice version check where collection practices changed.
[ ] App store age rating check at submission.

Phase 22. Ownership and annual cycle

[ ] [Gate] Name one owner with authority across product, engineering, growth, and support.
[ ] Publish four triggers: a new advertising or analytics kit; any change to the age screen or account creation; marketing targeting a younger audience; and any school deployment.
[ ] Give legal a two-day turnaround on those triggers.
[ ] Quarterly: traffic capture; kit reconciliation; age screen test; a five-minute support ticket search for stated ages.
[ ] Semi-annually: audience memo re-read against current analytics and marketing; retention job evidence reviewed; parent dashboard tested by an outsider.
[ ] Annually: full audience determination refresh; verification method reviewed against completion rates; vendor terms re-papered; teen workstream reviewed against new statutes; design-code status refreshed.
[ ] Measure the one number: time from a support ticket saying "my son is 9" to that account being handled correctly.

Phase 23. Model direct notice

Use this as the pattern for Phase 8. It is a product screen, not a legal document.

Your child wants to use Acme Play

Acme Play is a game for kids. Before your child can create an account, we need your permission.

What we would collect

A username your child chooses (please don't use their real name)

Their game progress and scores

A device identifier we use to keep the game working and to show ads chosen by the game screen, not by anything about your child

What we would not do

We do not use your child's information to target advertising to them

We do not sell or share your child's information

We do not require your child to give us more information than the game needs

Your rights as a parent You can see everything we've collected, ask us to stop collecting, and ask us to delete it — at any time, from the Parent Dashboard or by emailing parents@acme.example.

[ Give permission ] [ No thanks ]

We got your email address from your child so we could ask you. If you don't give permission, we'll delete it.

[ ] First line identifies the service and the request.
[ ] Collection list is specific and short, as 16 C.F.R. § 312.4 requires and as parents will actually read.
[ ] The "would not do" block states the internal-operations posture in plain words.
[ ] The rights paragraph names the interface, implementing 16 C.F.R. § 312.6.
[ ] The last line commits to the deletion the parent-contact exception requires.
[ ] Keep out: cross-references to the general privacy notice instead of saying what is collected; legal terminology; anything about the child not yet lawfully collected; and any suggestion that participation requires more disclosure than the activity needs.

Phase 24. Rewrite reference

| Written | Rewritten | |---|---| | "You must be 13 or older to use this service." (terms only) | A neutral, non-retryable date-of-birth screen before collection, with a defined under-13 path. | | "Are you over 13? [Yes] [No]" | "What is your date of birth?" with no minimum stated and no retry. | | "We collect information to improve our services." | The specific list: username, game progress, device identifier — and what each is used for. | | "We may share information with our partners." | Name the categories and purposes, or do not share. On a child-directed surface, sharing for advertising is not available. | | "By using this app you consent to our privacy policy." | Verifiable parental consent by a method meeting 16 C.F.R. § 312.5, logged. | | "Contact us to exercise your rights." | A parent dashboard with authenticated parent identity, review, refusal, and deletion. | | "We retain information as long as necessary." | A stated retention period per data element, with automated deletion and evidence it ran. | | Ad kit initialized on app launch | Ad kit initialized only after the age screen resolves, in child-directed configuration, verified by capture. |

[ ] Run every child-facing surface through this table.
[ ] Confirm each replacement is accurate, since a stated practice the company does not follow is separately actionable under 15 U.S.C. § 45.

Phase 25. Evidence request, written in advance

Draft once so it can be sent unchanged when a letter arrives. Name the system and the owner for each.

[ ] Audience determination memo, all versions, with dates and decision-makers.
[ ] Network traffic captures, before and after remediation, dated.
[ ] Software development kit inventory with configuration settings per release.
[ ] Age screen renderings per version, with the persistence logic described.
[ ] Direct notice, every version, with dates.
[ ] Consent records — parent, notice version, method, timestamp, child account.
[ ] Parent dashboard action log.
[ ] Retention schedule per data element, and evidence the deletion job ran.
[ ] Derived data and model training records identifying which datasets fed which models.
[ ] Support tickets mentioning ages, and the disposition of each.
[ ] Analytics and research documents describing audience age composition.
[ ] Marketing briefs and media plans for the period.
[ ] App store listings and age ratings, with change history.
[ ] Vendor operator terms for every kit collecting from a child-directed surface.
[ ] Education agreements and the education build manifest, if applicable.

Why this belongs here. Most of these do not exist in retrievable form at most companies, and the week an inquiry arrives is a much worse time to discover that than a quarterly review — particularly since the regulator may already have the traffic capture from a published analysis.

Phase 26. Product-type boxes

Run the base checklist, then the boxes for the product in play.

Mobile game with advertising.

[ ] Cold-launch capture is the critical test; most kits transmit on initialization.
[ ] Rewarded video and interstitial providers are separate kits with separate configurations.
[ ] In-app purchase flows collect payment data that may reach the parent, not the child — check who the account holder actually is.
[ ] Leaderboards and usernames are public disclosure of a child's chosen identifier; require non-identifying names and moderate them.

General-audience social or video product.

[ ] The actual-knowledge search in Phase 4 is the whole exercise; the audience determination is likely "general audience with risk."
[ ] Web surfaces with video content are the 18 U.S.C. § 2710 exposure.
[ ] Recommendation systems trained on all users include children's data; scope Phase 14 accordingly.
[ ] Direct messaging between adults and known minors is a safety issue before it is a privacy issue.

Connected device or toy.

[ ] Voice recordings of a child are personal information under 16 C.F.R. § 312.2.
[ ] The companion app and the device firmware transmit separately; capture both.
[ ] Verification method should be higher-rigor given the sensitivity of audio and video collection.
[ ] Retention of recordings is the highest-risk element and should default to deletion after processing.

Education product.

[ ] Ship a separate build with no advertising kits; do not rely on a runtime flag.
[ ] School consent covers educational purpose only, never commercial use.
[ ] Layer 20 U.S.C. § 1232g and state student-data statutes on top.
[ ] Deletion on contract termination must be real and confirmed to the district.

Health, fitness, or wellness product with minor users.

[ ] Health inference plus a known minor is the worst combination available; treat as sensitive in every state.
[ ] Advertising pixels on any symptom or condition surface should be removed rather than gated.

Retail or ecommerce with a kids' category.

[ ] The category page may be child-directed even where the site is not; the determination can be surface-by-surface.
[ ] Loyalty enrollment for a child account is collection requiring consent.

Phase 27. The ninety-day plan

[ ] Days 1-5. Traffic capture, cold launch first. Kit inventory reconciled. Unlisted kits removed.
[ ] Days 6-14. Child-directed modes enabled and verified by re-capture. Kits without such a mode scheduled for replacement.
[ ] Days 10-20. Audience determination memo drafted from the factors and the analytics. Actual knowledge searches run across support, analytics, marketing, and research.
[ ] Days 21-40. Age screen rebuilt — neutral, non-retryable, persisted — with the under-thirteen path defined and pre-screen data deletion implemented.
[ ] Days 30-55. Direct notice drafted. Verification method selected, with a universal fallback. Consent flow built and logged.
[ ] Days 40-70. Parent dashboard, including authenticated parent identity, which is the long pole.
[ ] Days 55-80. Retention rules per data element; automated deletion job; derived-data scoping and model training records.
[ ] Days 60-85. Vendor operator terms issued to every kit provider; contextual-only replacement completed.
[ ] Days 80-90. Teen cohort defaults set. Release checklist adopted. Owner named. Annual cycle calendared.

What is deliberately deferred. Full model retraining, complete design-code build-out, and safe harbor enrollment. None of them should delay the observable fixes, because the observable fixes are what a researcher or a regulator can document from outside.

Phase 28. Diligence questions for an acquisition

Ask for artifacts. A target with children among its users is a category of liability that does not appear on a standard litigation schedule.

[ ] Produce the audience determination memo. If none exists, assume the answer was never considered and price the remediation.
[ ] Produce a network traffic capture from the current release, or grant permission to run one during diligence.
[ ] Produce the software development kit inventory with child-directed configuration status per kit.
[ ] Produce the age screen as rendered, and describe how the answer is persisted.
[ ] Produce consent records for a sample of accounts identified as belonging to children.
[ ] Produce the retention schedule and evidence the deletion job runs.
[ ] Identify which models were trained on which datasets, since an order requiring deletion of a model trained on children's data is an existential remediation cost for some products.
[ ] Run the actual-knowledge searches on the target's support and analytics corpora, with access negotiated in the diligence protocol.
[ ] Identify regulatory correspondence, published research analyses, and app store enforcement in the last five years.
[ ] Confirm education deployments and produce district agreements, since those obligations transfer.

Then price three things. The build cost for what does not exist. The exposure from identifier transmission that has been running unmonitored, assessed per violation. And the possibility that the acquired product's monetization model is unavailable once the audience determination is made honestly — which is a valuation question rather than a compliance one, and it is the finding most often missed.

Outcome. The unlisted advertising kit was removed in week one and child-directed modes were enabled on two others, verified by re-capture; the third kit, which offered no such mode, was replaced with a contextual-only provider. The audience determination, made properly for the first time, concluded mixed audience rather than the general-audience position the company had assumed — bright palette, cartoon avatars, collectible mechanics, and analytics showing a meaningful under-thirteen cohort. A neutral, non-retryable age screen shipped in three weeks, with under-thirteen users routed into a payment-card consent flow and their pre-screen data deleted. The parent dashboard took six weeks, most of it building authenticated parent identity. Retention rules were written per data element and an automated deletion job shipped the following quarter, including derived segments. The revenue impact of moving the child cohort to contextual advertising was material and was presented in month one, which is why the project survived. When the inquiry arrived, the answer was a dated remediation record showing identifier transmission had stopped before the letter was sent.

Key Authorities at a Glance

| Authority | Proposition | |---|---| | 15 U.S.C. § 6501 | Definitions, including operator | | 15 U.S.C. § 6502 | Collection restrictions and consent | | 15 U.S.C. § 6505 | Enforcement | | 16 C.F.R. § 312.2 | Directed-to-children factors | | 16 C.F.R. § 312.2 | Personal information; persistent identifiers | | 16 C.F.R. § 312.3 | General requirements | | 16 C.F.R. § 312.4 | Direct and online notice | | 16 C.F.R. § 312.5 | Verifiable parental consent methods | | 16 C.F.R. § 312.5(c) | Exceptions; internal operations | | 16 C.F.R. § 312.6 | Parent's right to review and delete | | 16 C.F.R. § 312.7 | No conditioning participation | | 16 C.F.R. § 312.8 | Security | | 16 C.F.R. § 312.10 | Retention and deletion | | 16 C.F.R. § 312.11 | Safe harbor programs | | 15 U.S.C. § 45 | Unfair or deceptive practices | | Cal. Civ. Code § 1798.120 | Opt-in for minors under sixteen | | Cal. Civ. Code § 1798.99.31 | Design duties | | NetChoice v. Bonta | Design code partially enjoined | | Moody v. NetChoice | Curation as expressive activity | | 20 U.S.C. § 1232g | Education records | | Cal. Bus. & Prof. Code § 22584 | Student data restrictions | | Colo. Rev. Stat. § 6-1-1308 | Consent for known child data | | Va. Code § 59.1-577 | Children's data as sensitive | | 18 U.S.C. § 2710 | Video privacy on web surfaces | | 47 U.S.C. § 230 | No shield for the operator's own practices |

The five things people get wrong

Never making the audience determination. The decision is inconvenient, so nobody makes it, and the company then has no reasoning to defend. A regulator's first question is how the determination was made, and the worst possible answer is that it was not.

Trusting the vendor's child-directed mode without verifying it. Documentation is not evidence. Several kits suppress some fields and not others, and the only proof is a network capture — which is also the only proof a researcher or a regulator will have.

Treating a terms provision as an age control. A minimum-age clause in the terms prevents nothing, creates no defense against actual knowledge, and is routinely presented to counsel as though it were a compliance measure.

Building an age gate that leads or allows retry. Displaying the minimum age before the question teaches the user what to answer, and letting them go back and change the year makes the gate a formality — which undermines the very defense it was built to support.

Deleting source rows and keeping the derived data. Profiles, segments, and inferences built from a child's data are that child's data, and orders now reach models trained on it. A deletion project scoped to database rows has scoped the wrong thing.