Child-directed traffic is not a tag setting you forget

Product flags

Meta and Google both have child-directed or restricted data processing switches. They exist because the default pixel is the wrong default. Set them in the product, not only in a comment in GTM. The adult pixel id on a kids' thank-you page will still accept PageView. Acceptance is not permission.

COPPA cares whether the site or app is directed to children under 13, or whether you actually know the user is a child. That decision is not a GTM trigger on a path regex you wrote after launch. Use the restricted configuration the vendor named, or do not fire the ads tag. Pixellint will lint the URL shape. It will not know the user is nine.

https://www.facebook.com/tr?id=1234567890123456&ev=PageView

Mixed audience

A content site with some kids programming is still in scope for those pages. Per-page tags, not a global pixel with a hope. A mixed audience product (a parent account with a child profile) has to split events. The adult logged in on the same device does not make the child session fair game.

Do not send email, phone, or a durable external_id for a child to match into an ads graph. Hashing does not fix that. Hashing is how you match. The restriction is not to match that person for ads. GA4 and Meta CAPI will happily ingest the fields. Your obligation is not to put them on the wire.

Hashing does not help

vendor.meta.pii.unhashed_email and vendor.meta-conversions-api.body.unhashed_email catch a raw email on a pixel or CAPI body. They do not catch a hashed email you should not have collected. A 64-character digest of a child's address is still a matching key. COPPA is not a hashing tutorial.

Floodlight tags historically grew tfua and tag_for_child_directed_treatment style fields. Filling them on a template and then firing the adult conversion cat on a kids property is still the adult conversion. Read the vendor's restricted-data docs for the product you actually use. Do not invent a Pixellint COPPA code.

https://ad.doubleclick.net/ddm/activity/src=1234567;type=conv0;cat=purch0;dc_rdid=;tfua=;npa=;gdpr=;gdpr_consent=;ord=8675309?

Analytics

GA4 has data-collection controls for ads signals. Turning on Google signals on a child-directed property is a product decision with legal, not a growth hack. Even if you strip the live tag, HAR files, MMP raw exports, and CAPI retry queues may still hold identifiers from the period you were wrong.

Measurement Protocol will accept a purchase payload with hashed or raw user data depending on what you send. vendor.google-analytics.body.purchase_requires_ecommerce_fields cares about currency, value, transaction_id, and items. It does not care that the buyer is a child. Gate the event before the POST.

QA and retention

QA with a production pixel id on a kids' staging build is how this ships. Use a void destination, or no ads SDK, until counsel and the vendor settings are in place. A test_event_code is still your real pixel with a filter, not a COPPA sandbox. Retention is part of the exposure.

Child-directed, GDPR erasure, and CCPA delete have to hit these logs too. A warehouse that is append-only will fail that. Plan the delete path when you add the CAPI queue, not when the first request arrives. See data retention. The kids property is where infinite BigQuery hurts most.

Check the artifact

Paste the pixel URL or JSON body into the playground. Same engine as pixellint validate. Nothing leaves the tab.