Child-Directed Ad SDK and COPPA Signal Review

The most common finding is a correctly declared app with an unwired signal. The store listing says child-directed, the app sits inside the Families programme, and the bid request still leaves the device with the COPPA flag absent and an advertising identifier attached, because the mediation adapter was initialised before the child-directed setting was applied. We read the wire, not the declaration. What gets inspected: SDK initialisation order in your actual build, checking that the child-directed treatment and under-age-of-consent settings are applied before any ad request is made, and that every adapter in the mediation waterfall honours them rather than only the primary network. The outbound bid requests themselves, captured from a provisioned device, checked for the COPPA flag, the privacy string and its applicable sections, advertising identifier presence, and any device or location field finer than the rule permits. The flow shown to a user who declares an age below the threshold, which is 13 in the United States, 14 in Spain, and up to 16 elsewhere in the Union under Article 8 GDPR. The creative rules that apply once you are inside a families programme, including the interstitial placement rules that get apps removed rather than warned. On iOS, the Kids Category rules, which are stricter than COPPA and where third-party analytics is the usual violation. The three failures we find most: An attribution or analytics SDK that a partner bundled inside their own SDK, undeclared by anybody, still collecting a persistent identifier. Mixed audience treated as a targeting decision rather than an age screen, with no neutral gate and a screen that nudges toward the adult path. A parental consent flow that collects the parent's email address and stops there, which is notice, not consent. The 2026 date: The amended COPPA Rule carries a full compliance date of 22 April 2026, and the parts that change engineering rather than paperwork are the separate consent required before disclosing a child's data to third parties, the retention policy that has to be written and published, and the written children's data security programme. If your monetisation depends on third-party targeting inside a child-directed surface, that separate consent is the item to plan around now rather than in the quarter it lands. Not included: We do not select or integrate a parental consent vendor for you, though we will say which of the approved methods fits your funnel and which will cost you half your installs. We do not handle store appeals or takedowns. We do not review content for age appropriateness; that is a different discipline and we are not it. We turn this down when: Your product is adult and the ask is a memo saying children do not use it. If a meaningful share of your users are under age, that memo will not survive an inquiry and writing it would be the worst thing we could sell you. We also decline work where the brief is to find the minimum change that keeps behavioural targeting running on a child-directed surface. There is not one. Who does the work: A single reviewer with the build in hand and your mobile engineer available for two sessions. This is not a document exercise. If we cannot instrument the app we cannot do the review, and we say so before invoicing rather than after.