On this page (6 sections)
Content rating questionnaire
Google is explicit about both the requirement and the risk: you must “fill out a rating questionnaire in Google Play Console” for new and existing apps, and “misrepresentation of your app's content may result in its removal or suspension.” You must also re-take the questionnaire for “all app updates where there has been a change to your content or features that would affect the responses”.
- Answer for what the app can show, including user-generated content, external links and web views — not only for the curated demo state.
- A rating authority can override your rating; if you disagree you re-take the questionnaire rather than argue.
- Several rating outcomes pull in other policies — ads to children, in-app purchases for younger audiences, data collection limits.
What each declaration commits you to
| Declaration | What it commits you to | Where the work usually is |
|---|---|---|
| Privacy policy URL | A reachable policy describing what the app and its SDKs handle | Rewriting a template policy to name real SDKs, purposes and deletion |
| Ads | Whether the app contains ads at all — mediation SDKs count | Removing an ads SDK that is no longer used, or declaring it and meeting the ads policy |
| App access | That a reviewer can reach every gated feature with the credentials you supply | A stable demo account, a bypass for OTP, region-independent access |
| Content rating | The content and features the app can display, now and after updates | Moderation for UGC; re-taking the questionnaire when features change |
| Target audience and content | The audience you design and market for | If children are included: Families policy, ads SDK self-certification, data limits |
| Data safety | Collection, sharing, purposes, encryption in transit, deletion — including SDKs | A real data-flow audit; account deletion in-app and on the web |
| Government apps | That you are authorised to act for the entity named | Documentation; this is not a declaration to guess at |
| Financial features | The specific financial features and any licensing behind them | Regional licence evidence; feature gating by country |
| Health apps | Health-related features, research or data handling | Consent flows, regional requirements, Health Connect permissions |
| News apps | That the app is a news publisher with the required transparency | Editorial contact details, ownership disclosure |
| Advertising ID | Whether the app uses AD_ID, consistently with Data safety | Removing the permission when no SDK needs it |
The mismatches that cause rejections
- Rating vs content: a UGC app rated for everyone, with no moderation or reporting path.
- Target audience vs design: selecting children (or “children and adults”) without the Families requirements — certified ads SDKs, no personalised ads, no cross-app tracking.
- Ads declaration vs build: “no ads” with a mediation SDK compiled in, or ads declared but the ads policy not met (disruptive interstitials, ads over system UI).
- Data safety vs behaviour: the most common of all — see Data safety rejections.
- App access vs reality: credentials that expired, or a login that needs an SMS code the reviewer cannot receive — see reviewer access.
- Category declarations skipped: financial, health, government and news declarations are not optional for apps in those categories.
Do not over-declare either
Declaring content, data or an audience you do not actually have pulls the app into stricter policies — Families requirements, health data rules, financial licensing — and each of those has its own review. Accuracy is the objective in both directions.
If children are part of the audience
Selecting a child audience changes the app's obligations: ads SDKs must be self-certified for Families, personalised advertising and cross-app tracking are restricted, the app must meet the Designed for Families requirements, and the content rating must match. Google's Policy Deadlines page also records expansions dated 26 August 2026 to the Families Policy Requirements, Child Safety Standards and Age-Restricted Content policies, aimed at anonymous and random chat apps targeting children. If that describes your app, treat the audience declaration as a product decision, not a form field.
How we work through it
- Inventory what the app actually contains and collects, including SDK behaviour and any user-generated or web content.
- Answer each declaration against that inventory, flagging answers that create obligations the build does not yet meet.
- Implement what the honest answer requires — moderation and reporting, account deletion, consent flows, ads configuration, feature gating by region or age.
- Re-check the store listing so the promoted features match the declared audience and content, and re-take the questionnaire when features change.
Checklist
- Content rating questionnaire completed for the current feature set, and re-taken after feature changes
- Target audience matches the design, the listing and the rating
- Ads declaration matches the SDKs in the merged build
- App access instructions tested on a clean device with a fresh account
- Data safety form matches observed behaviour, including SDKs, and account deletion exists
- Category declarations (financial, health, government, news) complete where they apply
- Advertising ID declaration consistent with the manifest and the Data safety answers
- Privacy policy names the real data types, purposes, third parties and deletion path
Submitting for the first time? Work through the Google Play submission checklist, and check the permissions separately on sensitive permissions.