Google Play Families policy rejection: target audience, ads and child-appealing content

Google has decided your app is directed at children, or that your own answers say it is, and something that follows from that is not in place. In practice it is nearly always one of three things: the Target audience and content answers, the ads stack, or a store listing that looks like it is for kids even though you said it is not.

How the rejection is worded

This one usually arrives as a policy email rather than a line in the release notes, sent to the account owner and to any user with the relevant Play Console permission. The same issue is mirrored in Play Console under Policy → App content, and on the app's Policy status page.

The wording tends to look like:

"Your app is currently targeting children, or children and adults, but does not comply with the Families policy requirements."

"We found that your app's store listing is likely to appeal to children, but the target audience you selected does not include children."

"Your app serves ads to children using an ads SDK that is not self-certified as compliant with Google Play Families policies."

What it means

Play Console makes you answer a Target audience and content questionnaire under App content, where you tick the age bands the app is aimed at. Ticking any band under 13 makes the app child-directed as far as Play is concerned, and a specific set of rules switches on: ads must come from an SDK in the Families self-certified ads SDK programme, advertising to children cannot be personalised or use remarketing, persistent identifiers such as the Android Advertising ID must not be collected from children, the content rating must match, and the listing itself must be appropriate for the audience you claimed.

Here is the part that catches people. Your answer is a claim, not a ruling. Google reads the icon, the screenshots, the title and the app itself, and if all of that reads as a children's app, it will be treated as one regardless of which box you ticked. Cartoon characters, primary colours, "for kids" phrasing, nursery rhymes, colouring, simple animal games, any of it can flip the assessment.

The reverse also happens: an app that genuinely is for children, declared as such, then fails on ads or identifiers because a mediation network in the chain was never checked.

Why it happens

• The listing appeals to children while the questionnaire says 13+. The most common version by a distance, and the one developers argue with hardest.
• An ads SDK is not on the self-certified list: or it is, but the app is still requesting personalised ads. Mediation matters too: every network that can fill an impression has to qualify, not just the SDK you integrated directly.
• Persistent identifiers are collected from children. The advertising ID is the usual one, but device and hardware identifiers count as well.
• The content rating questionnaire contradicts the audience. An IARC rating that permits mature themes alongside a declared under-13 audience is an obvious mismatch.
• No neutral age screen on a mixed-audience app, so children reach content or features meant for adults.
• Open exits: web views, outbound links, chat, user-generated content, that let a child leave your supervised experience.
• The privacy policy does not address children's data at all, or is missing from the app itself.

How to fix it

1. Decide honestly who the app is for, then make everything agree. This is a product decision before it is a compliance one. If children are genuinely not the audience, the icon, screenshots, title, short description and in-app art all have to say so, not just the questionnaire.
2. If children are in scope, fix the ads first. Switch to an SDK in the self-certified programme, turn off personalised advertising and remarketing for child users, and walk the full mediation chain. Then confirm what actually gets served on a real device rather than what the dashboard says should be served.
3. Stop sending identifiers. Audit the network traffic from a clean install, not the SDK docs. Analytics libraries collect the advertising ID by default more often than developers expect.
4. Add a neutral age screen if the audience is mixed. Neutral means it does not hint at the answer, an open date-of-birth entry rather than "Are you over 13? Yes / No", and the result should persist so children are not simply re-asked until they get it right.
5. Redo the content rating questionnaire so the rating, the audience and the actual content line up.
6. Publish a privacy policy that covers children specifically, and link it both in the listing and inside the app.
7. Close the exits. Any link, web view or social feature reachable by a child has to be either removed, gated behind the age screen, or made safe.
8. Look at your own store listing as a stranger would. If a parent browsing Play would assume it is a kids' app, Google will too.

Appeal, or fix and resubmit?

Play's mechanism is not Apple's Resolution Center, and the right move depends on what actually happened to the app:

• Rejected: a new app or an update was not published. There is nothing to argue with unless Google got the facts wrong: fix it and upload a new release. An appeal here usually just spends a review cycle.
• Removed: the app is off Play but existing installs keep working. Correct the violation and submit an update; appeal only if you believe the finding is wrong.
• Suspended: the app is off Play and the enforcement is recorded against your developer account. This is the case where an appeal matters, because getting it reversed matters beyond this one app.

Appeals go through the appeal form linked in the policy email, or from the app's Policy status page in Play Console.

Appeal when Google has misread the audience and you can show it, describe who the app is for, what the analytics say about who uses it, and why the artwork is not child-directed. But be honest with yourself first: if a reviewer looked at your listing and saw a children's app, some of your users are seeing the same thing.

Do not shrug off a Families finding and try again with a cosmetic change. Repeated violations of the same policy escalate from the app to the account, and a terminated Play account takes every app you have published with it.

What to send

The target audience selection has been corrected to [ages], and the store listing artwork, icon and description have been updated so they no longer appeal to children. Advertising is now served only through [SDK], which is self-certified under the Families programme, with personalised advertising and remarketing disabled for all users in the affected age bands. The app no longer transmits the advertising ID or any persistent device identifier. The content rating questionnaire has been resubmitted and the privacy policy now describes our handling of children's data.

Adapt it to what you actually changed. A claim in an appeal that a reviewer can disprove in thirty seconds costs you far more than it saves.

If you would rather not read the policy email cold, AppSubmit's rejection explainer takes the pasted text and returns the specific requirement being cited plus an ordered action plan, and tells you plainly when a reply will not help and only a new build will.