# Google Play Families policy for child-targeted apps

> Google Play Families policy checks for target audiences, SDKs, data, ads, and child-facing app flows.
> By Dave · 2026-10-11
> Source: https://otf-kit.dev/blog/google-play-families-policy-children-apps

A children’s target-audience setting can change more than your store listing. On Google Play, if children are one of your app’s target audiences, the Families policy adds requirements for app content, data practices, APIs and SDKs, social features, ads, and other commercial content. A mixed-audience app has its own implementation questions: which experience does a child see, and can an SDK collect data before the app knows the user’s age?

Treat the Play Console declaration as the start of a release review, not a checkbox at the end. This guide turns the policy into engineering checks for the app, its dependencies, and the Play listing. It is an implementation checklist, not legal advice; the applicable rules can depend on your app and audience.

## Start with the audience you actually built for

Before publishing, Play Console asks you to choose the app’s target age groups. Google says to select multiple groups only when the app is designed for and appropriate to all of them. It can also assess the app’s imagery and terminology when reviewing whether the declared audience is accurate. A mismatch between the app and its answers can lead to removal or suspension.

Write down why each selected age group fits the product. Review the store listing, onboarding, screenshots, in-app language, and the content users can reach. If the audience changes later, update the Target Audience and Content section; Google notes that changes may be reviewed before an app update is submitted, and an app update is needed for the information to be reflected on the store.

That declaration influences technical decisions.

![Dex, Luna, Byte, and Nova review a child-appropriate app experience alongside its target-audience decision.](https://cdn.otf-kit.dev/blog/google-play-families-policy-children-apps/inbody-audience-policy-decision-20261011a.png)

 If children are included in the target audience, use the Families policy as a release requirement for the relevant flows. Do not assume that a broad age range makes child-specific handling optional.

## Map data collection across the whole app

The policy requires disclosure of personal and sensitive information collected from children, including information collected through APIs and SDKs the app calls or uses. Start an inventory that includes first-party code, analytics, crash reporting, advertising, sign-in, support, and embedded web experiences. For each data path, record what is collected, when collection begins, which users can trigger it, where it goes, and which Play Console answer describes it.

Then review persistent identifiers separately.

![The team audits SDK data, ad placements, and age-group handling against a policy checklist.](https://cdn.otf-kit.dev/blog/google-play-families-policy-children-apps/inbody-sdk-data-ad-audit-20261011a.png)

 Apps solely targeting children must not transmit the Android advertising ID and several other listed identifiers; the policy also says those apps should not request AD_ID permission when targeting API 33 or higher. Apps that target children and older audiences must not transmit the listed identifiers from children or users of unknown age. Do not treat a library’s manifest entry as proof that the app uses the identifier, or as proof that it does not. Trace the code and configuration, then align the result with your declaration. See the [Android advertising ID permission guide](/blog/android-advertising-id-ad-id-permission) for the Android-specific manifest and identifier checks.

A privacy policy should accurately explain the app’s collection and handling practices. Keep that document, the Play Console Data safety answers, and the behavior of the shipped build in sync. When a dependency changes, repeat the review: a new SDK version can alter collection or add permissions even if your own app code did not change.

## Decide how mixed-audience flows handle age

If an app serves children and older users, decide which SDKs and features are available to each audience. The Families policy says an API or SDK not approved for use in child-directed services must not be implemented in a mixed-audience app unless it is behind a neutral age screen or implemented so it does not collect data from children. The app also must not require children to access content through such an API or SDK.

A neutral age screen is not a decorative date-of-birth prompt. Its result needs to control the experience: which SDK initializes, which data is collected, and which content or social features become available. Avoid loading a restricted SDK before the screen simply because the app needs it later for adult users. Document what happens when the age is unknown, and test that path too.

Do not infer that a provider is approved from its popularity or from another app’s use. Check the current policy and the provider’s applicable terms. If the provider’s status or the app’s age-gating design is unclear, hold that integration from child-facing flows until the team verifies the requirements.

## Review ads, cross-promotion, and purchases

Families monetization rules cover more than third-party ad calls. Google includes ads, cross-promotions for your own or third-party apps, offers for in-app purchases, and other commercial content such as paid product placement. If ads are shown to children or users of unknown age, use only the relevant Google Play Families self-certified ad SDK versions, and ensure the ads are not interest-based or remarketed to those users. Also check that the content and format are suitable.

Review placements in context. The policy bars deceptive commercial content and designs likely to cause accidental clicks. It also restricts disruptive placements, including interstitials at app launch, multiple ad placements on a page, and offers that are difficult to distinguish from app content. A house ad for your own app is still a cross-promotion; a purchase offer is still commercial content. Include these surfaces in the same audit as the ad network integrations. The [Google Play “contains ads” declaration guide](/blog/google-play-contains-ads-declaration) covers how to inventory and declare ad placements.

For in-app purchases, check how virtual currency is presented and whether a child can understand the difference between virtual coins and real money. Do not rely on a code-level purchase test alone: inspect the screen, surrounding copy, and the sequence that leads to the purchase. Keep offers clearly distinct from ordinary app controls.

## Add social and augmented-reality checks where relevant

If users can share or exchange information, accurately disclose those features in the Play Console content-rating questionnaire. A social app that includes children must show an online-safety reminder before children exchange freeform media or information and require adult action before children share personal information. Apps with social features must also provide a way for adults to manage those features, such as enabling or disabling them or selecting a level of functionality.

Make the control part of the product, not just the policy document. Test the child account path, the adult control path, and what happens when an adult has not enabled the feature. Google says anonymous chat and chat with unknown people must not target children when that is the app’s main purpose.

If your app has an augmented-reality section, show its safety warning immediately when that section launches. Include parental supervision and awareness of physical hazards, and do not require a device Google says should not be used by children. These requirements are conditional: document whether the app has the feature, then test the branch that applies.

## Turn the policy into a release gate

A practical review can be owned by engineering and product together:

1. Compare selected age groups with the product, listing, visuals, and reachable content.
2. Inventory first-party and third-party data collection, including SDK initialization before sign-in or age screening.
3. Check identifier permissions and transmissions for child and unknown-age users.
4. Verify which APIs and SDKs are suitable for child-directed use, and gate mixed-audience flows accordingly.
5. Review ads, house promotions, purchase offers, social features, and AR screens in the built app.
6. Reconcile the result with Target Audience, Data safety, content rating, ads, and privacy-policy information in Play Console.
7. Test fresh install, upgrade, signed-out, age-unknown, child, and adult paths in the release variant.

Keep evidence with the release: SDK inventory, relevant configuration, test cases, screenshots of the actual flows, and the person who checked the Play Console answers. When a policy or SDK changes, rerun only the affected checks, but do not skip the overall consistency review before submission.

The useful question is not simply whether the app is “for kids.” It is whether the declared audience, the shipped experience, the data flows, and the Play Console answers agree. If they do not, fix the product or the declaration before release; do not hope a store review will resolve the mismatch for you.

## Sources

- [Google Play Families Policies](https://support.google.com/googleplay/android-developer/answer/9893335)