Choosing the Right Target Audience and Content Rating in Play Console

Target audience and content rating look similar in Play Console, and many developers fill them in as if they were one form. They are not. Mixing them up is one of the easier ways to end up with a policy warning, a rating you did not expect, or extra requirements you did not plan for.

This post explains what each form is for, how to choose your answers, and which mistakes to avoid. Google changes these forms from time to time, so treat the details here as a guide and check Play Console Help for the current wording.

The short version

• Target audience answers: who is this app designed for? You choose age groups.
• Content rating answers: what does this app contain? You complete a questionnaire about violence, user-generated content, and similar topics, and you receive ratings in return.

Both live in the App content area of Play Console. You need both completed before you can move to production, so it is better to settle them during your closed test than on release day.

Target audience: who the app is for

Play Console asks you to select the age groups your app targets. The options are age brackets, ranging from young children through to adults. The choice affects which policies apply to your app.

Why the choice matters

If your selected groups include children, Google's policies for apps aimed at kids may apply. These can cover things like which ad SDKs you can use, how you handle data, and what the app can ask users to do. The exact requirements are in Play Console Help and the Developer Program Policies, and they change, so read the current version before you decide.

If you target only older teens and adults, those child-specific requirements generally do not apply. That is a big difference in workload, and it is why this form deserves a real decision.

How to choose

1. Start from your actual product. Think about who you built it for, who you market it to, and who realistically uses it. A budgeting app or a developer tool is not for eight-year-olds, even though an eight-year-old could download it.
2. Do not tick every box for reach. Selecting all age groups "just in case" can pull in the strictest rules. It will not make the app more discoverable in any way we can promise.
3. Be consistent with your store listing. Cartoon mascots, bright toy-like art, and kid-friendly wording can make an app look child-oriented, whatever you selected. Play Console also asks whether your app might appeal to children, so answer that question with your real listing in mind.
4. Check your SDKs. If you do target children, confirm that every ad, analytics, or crash-reporting library you ship is acceptable under the current rules.

If you are genuinely building for kids

That is a legitimate choice, but plan for extra work: a stricter review of your dependencies, careful data handling, and a Data safety form that reflects it. Do not pick a children's age group casually, and do not avoid it dishonestly if your app really is for them.

Content rating: what the app contains

The content rating is based on a questionnaire. As far as we know, it is run through the International Age Rating Coalition (IARC), and the result is a set of ratings for different regions. The questions are about the app's content and features, not your intentions.

Typical topics include:

• Violence, blood, or frightening content
• Sexual content or nudity
• Language and references to drugs, alcohol, or gambling
• User-generated content, chat, or social features
• Sharing of user location
• Digital purchases

Answer for the whole app, not the best case

Answer about what a user can actually encounter. A few places where developers under-report:

• User-generated content. If users can post text, images, or usernames that other users see, say so. It does not matter that you plan to moderate.
• Web content. If your app opens a WebView or links out to content you do not control, think about what can appear there.
• In-app purchases and random rewards. If the app sells items or has loot-box-style mechanics, the questionnaire may ask about them directly.
• Placeholder or test content. Content in your closed-test build should reflect what you will ship. If you plan to add a chat feature later, update the rating before you ship it.

Do not try to game it

Understating your content to get a lower rating is not worth it. Ratings can be reviewed, and a mismatch between your answers and your app can lead to enforcement, which is much worse than a higher rating. If you are unsure how to answer a question, Play Console Help explains the intent behind each one.

How the two forms should line up

The forms are independent, but they should tell a coherent story. Run a quick sanity check:

• If you target young children, your content rating should be consistent with child-appropriate content. A game with heavy violence aimed at young kids is a conflict.
• If you target adults, do not pick a young age group just because your rating came out low.
• If your rating is high because of user-generated content, check that your target audience and your moderation or reporting tools fit that.
• Confirm your Data safety form matches both. A child-directed app that declares unrestricted ad tracking is a red flag.

Where this fits in your closed test

The 14-day closed test is a good time to confirm these answers. Your testers use the real build, so what they see is a better check than your memory of what you coded. Ask them one specific question in your feedback form: Did you see anything in the app that surprised you or that seemed inappropriate for its stated audience? That is cheap, and it can catch things like an ad network serving unsuitable ads or a text field you forgot is public.

If you use TesterMob, testers use your app on their own Android phones for about 20 minutes a day and write feedback, so you can use that feedback to check these points. See the developer page for how it works, or pricing if you want the cost up front. TesterMob is not affiliated with Google and cannot guarantee production approval, and these two forms are your responsibility either way.

A short checklist

1. Write one sentence describing who the app is for, and pick target age groups that match it.
2. Check your store listing art and text against those age groups.
3. List every third-party SDK and confirm it is acceptable for your audience.
4. Complete the content rating questionnaire based on everything a user can see, including user-generated and web content.
5. Review the resulting ratings. If they surprise you, check your answers rather than trying to change the result.
6. Cross-check against your Data safety form.
7. Re-do the questionnaire whenever you add chat, purchases, or other features that change your content.

Final note

These forms are quick to fill in and slow to untangle once they are wrong. Spend ten minutes on them now, answer honestly, and revisit them when the app changes. For wording that may have changed since this post, check Play Console Help, and see our FAQ if you have questions about closed testing itself.