From Legal Text to Product Decisions—and the TikTok Reality Check

The subject of this chapter is a practical product decision: how should a service evaluate an age-assurance flow without treating the age gate as the end of its privacy obligations? The focus is the order of judgment—scope, age question, input, accuracy, sharing, security, retention, deletion, consent, and necessity. The result should be usable by an operator or informed reader assessing a proposed design, while remaining honest about what the selected sources can and cannot prove.

A useful way to make the problem concrete is to imagine a mixed-audience service that offers creative tools to adults but includes a child-directed area with interactive features. The operator wants to determine whether a visitor is under 13 before allowing access to that area. It is considering a simple age declaration, a third-party age signal, or a process that asks for a photograph or other biometric input. None of these labels settles the legal question. Each creates a different data flow, accuracy question, and exposure pattern.

Start with the service, not the vendor

The first design decision is not which provider to buy. It is how the service and the relevant portion of it are classified. The amended COPPA Rule asks whether the service or portion is directed to children, whether children are its primary audience, and what the operator actually knows about the information it collects. A mixed-audience classification is available only after the service is found to be directed to children but not primarily aimed at them. A general-audience label does not erase a child-directed portion or actual knowledge that a collection comes from a child.

For the hypothetical creative service, that means examining the child-oriented area on its own terms. Its subject matter, visual design, activities, language, incentives, marketing, and audience evidence may all matter. The service cannot point to its large adult user base and stop there. Nor can it treat a particular percentage of child users as a legal safe line. The FTC declined to create an audience-composition exemption based on a specified percentage because data can be manipulated, audiences change, age methods may be unreliable, and a percentage would not replace the rule’s multi-factor inquiry.

If the child-oriented area is mixed audience, the age-screening option comes next. The operator may use age information or another method reasonably calculated, in light of available technology, to determine whether a visitor is a child. The method must be neutral: it cannot default to an age selected by the operator or encourage visitors to falsify their age. Before the determination, the operator generally cannot collect other personal information from the visitor except for the limited purposes allowed by the rule’s exceptions to prior parental consent.

The order is important because it limits what the age gate can do. It can help distinguish visitors within the mixed-audience branch. It cannot manufacture that branch, convert a primarily child-directed service into a general-audience service, or justify collecting a profile before the service knows which visitor-level path applies. If the visitor is identified as under 13, the operator must follow the applicable COPPA notice and parental-consent requirements before collecting, using, or disclosing the child’s personal information.

This first step also prevents a common procurement mistake. A vendor may describe its service as an age-verification solution, but the operator remains responsible for connecting the method to the operator’s own service, audience, and collection practice. The FTC’s policy statement refers to products, services, methods, and third parties that are likely to produce reasonably accurate results. It does not say that purchasing one of them transfers the operator’s classification judgment to the vendor.

The next step is to define the age question precisely. Does the service need to know whether the visitor is under 13, or does it need an exact age? Does it need to make one access decision, or will it reuse the result across unrelated features? The supplied sources do not establish a universal answer to those product questions. They do establish that the narrower the purpose and output, the easier it is to test whether the collected input has acquired an unrelated job. A design that asks for an exact date, keeps a reusable identity record, and shares it across products should not be treated as equivalent to a design that seeks only the minimum age decision for one service interaction.

Compare methods by the risks they create

A lower-data method is not automatically compliant, but it may change the risk questions.