Google Play Console and Store Listing Basics

Your app is built, signed and bundled (lesson 49). Now people have to find it, trust it and install it. That job is done by your store listing: the page on Google Play with your icon, name, screenshots and description. For many apps, the listing is the difference between 50 installs and 50,000.

This lesson is Module 1: Getting started with the basics of the Google Play Store Listing Certificate (https://playacademy.withgoogle.com/certificate), a free, self-paced course from Google Play Academy for developers and marketers. Lessons 51–53 cover the other three modules. Throughout, we teach the skills in our own words and with our own worked examples. We do not reproduce the course text, and we cannot see or share the exam, so always do the official course for the certificate.

Honesty note. Google Play Console changes its menus and wording often, and policy rules move. Where this lesson names a menu or a limit, check the current Play Console Help (https://support.google.com/googleplay/android-developer) before relying on it. Nobody can promise approval, ranking or install numbers, and neither does this lesson.

By the end you will be able to:

• Explain what Google Play Console is and who uses it.
• Create a developer account and understand identity verification, fees and account types.
• Create an app in the Console and complete the App content declarations.
• Fill in the main store listing: title, short description, full description, icon, feature graphic, screenshots and video.
• Meet the baseline requirements for every listing (accuracy, quality, policy).
• Create your first internal test release and understand the review process.
• Understand the three kinds of listing assets and the numbers you need.

Big idea: your listing is a promise to the user. Everything in it must be true, clear and quickly understood, because a visitor decides in seconds.

• A signed app bundle and release process (lesson 49).
• Application ID, version code, tracks (lesson 49).
• Basic image concepts: pixels, aspect ratio, PNG and JPEG.
• A Google account (a separate one for your business or organisation is recommended).

Google Play Console (https://play.google.com/console) is the website and app where developers publish and manage apps on Google Play. Different people use it in different ways:

The Console has areas such as Dashboard, Statistics, Release (testing and production tracks), Grow users (store listings, experiments, custom listings), Monitor and improve (Android vitals, ratings and reviews) and Policy and programmes (app content, policy status). The names and layout change, but these jobs stay the same.

How a user sees your listing

 Google Play search results         Your store listing page
 +-----------------------+         +---------------------------------------------+
 | [icon] App name       |  tap    | [feature graphic or video]                  |
 |  short description    | ----->  | [icon]  App name         [Install]          |
 |  4.5 star  1M+        |         |   Developer name          ratings, downloads|
 +-----------------------+         | [screenshot][screenshot][screenshot] ...    |
                                   | About this app (short + full description)   |
                                   | Data safety | Reviews | Developer contact   |
                                   +---------------------------------------------+

The user first sees only the icon, title and short description in search or on a list. Only a user who is interested continues to the listing page. So the first three items carry the most weight.

Account types

When you register, you choose between a personal and an organisation account. The best choice depends on who owns the app.

For a class project or a first app, personal is fine. For a business such as Techbase Consultant Services, an organisation account is the proper choice because the app is not "owned" by one person's account.

Registration steps (typical)

1. Sign in to Play Console with a Google account you will keep for years.
2. Pay the one-time registration fee (at the time of writing a small one-time amount in US dollars; check the current fee and accepted payment methods in your country).
3. Provide your developer name (shown to users), contact email and phone (verified), and website if you have one.
4. Complete identity verification with the documents Google asks for. This can take days. Do it early, before you plan to launch.
5. If you charge for apps or sell in-app items, set up a payments profile; Google needs bank details for payouts. Availability of paid apps and merchant accounts depends on your country.

Security first. Turn on 2-Step Verification for the account, use a password manager, and add teammates as users with limited permissions instead of sharing the owner's password. Never share the account credentials in chat.

1. In Play Console choose Create app.
2. Fill in: - App name (what users see; you can change it later). - Default language of your listing. - App or game. - Free or paid. Warning: a free app cannot be changed to paid later; a paid app can become free. Choose carefully.
3. Accept the Developer Program Policies and US export laws declarations.
4. Click Create app.

The Dashboard now shows a setup checklist (names vary: "Set up your app", "Finish setting up your app"). Typical tasks:

Privacy policy basics

If your app handles any personal data (and most do, even an email address or an advertising ID), you need a privacy policy at a public URL. It must say what you collect, why, how it is stored and shared, how long you keep it, and how a user can ask for deletion. Free generators exist, but you remain responsible for its accuracy; a policy that says "we collect nothing" while your app uses analytics is a policy violation. Write it from your real data flows.

The Data safety form

Think of this as a nutrition label for data. Walk through your app and libraries: analytics SDKs, crash reporting, ads, login, location, contacts, photos. For each data type declare collected, shared, purpose, and whether collection is optional. Honest, accurate answers matter. Google compares declarations with what it sees, and wrong answers can lead to rejection or removal. If a library collects data, you must declare it.

In the Console go to the Main store listing page (under Grow users → Store presence or similar; names vary). Fill in each field. We use the running example of an app called Class Register, a free attendance app for Nigerian teachers.

Text fields

Title. Use your brand name and, if it fits and is truthful, a short descriptor: Class Register: Attendance (26 characters). Policy forbids misleading names, emoji or symbols for decoration, ALL CAPS shouting, and claims such as "No.1", "best", "free" or price/promotion words in the title.

Short description. Lead with the main benefit in plain language:

Mark attendance in seconds, even offline, and share class reports.

That is 66 characters. A quick counting function lets you check your own text. It is a tiny program, and a good reminder that characters are not words:

fun checkLength(label: String, text: String, limit: Int) {
 val ok = text.length <= limit
 println("$label: ${text.length}/$limit ${if (ok) "OK" else "TOO LONG"}")
}
fun main() {
 checkLength("Title", "Class Register: Attendance", 30)
 checkLength(
 "Short",
 "Mark attendance in seconds, even offline, and share class reports.",
 80
 )
}

Output:
Title: 26/30 OK
Short: 66/80 OK

Full description. Structure it for people who skim:

Class Register helps teachers take attendance quickly, even without internet.

WHY TEACHERS LIKE IT
- Tap once per student: present, absent or late
- Works offline; syncs when you are online
- Weekly and termly reports you can share as PDF
- Free; no ads in the attendance screens

HOW IT WORKS
1. Add your classes and students
2. Mark the register each morning
3. Share a report with the head teacher or parents

DESIGNED FOR REAL CLASSROOMS
Large buttons, works on low-storage phones, supports large text and TalkBack.

Questions? support@yourdomain.ng

Principles for the full description:

1. First three lines matter most; they show before "Read more".
2. Say what the app does in plain words, then what benefit the user gets, then details.
3. Use short paragraphs and lists.
4. Include natural keywords a user would search for ("attendance", "register", "school"). Do not keyword-stuff: repeating words, listing unrelated apps or competitors' names breaks policy and reads badly.
5. Be accurate: do not describe features that do not exist, and do not claim endorsements or awards you do not have.
6. Mention important requirements (internet, account, in-app purchases).
7. Provide contact details.

Graphic assets

Always check the current numbers in the Console's upload dialogs (they list size and format requirements). Typical values at the time of writing:

A helpful tiny script checks screenshot sizes before you upload (it needs the Pillow library, installed with pip install pillow):

from pathlib import Path
from PIL import Image
for path in sorted(Path("screenshots").glob("*.png")):
w, h = Image.open(path).size
long_side, short_side = max(w, h), min(w, h)
ok = 320 <= short_side and long_side <= 3840 and long_side <= 2 * short_side
print(f"{path.name}: {w}x{h} {'OK' if ok else 'CHECK'}")

Localisation

You can add translated listings. Even a short, accurate translation into the languages of your market (Yoruba, Hausa, Igbo, French or Arabic, as appropriate) can help discovery and trust. Use professional or native-speaker review; poor machine translation harms trust. Lesson 52 covers this in depth.

Every listing is checked against Google Play policies. The principles are not complicated, and breaking them is the most common reason for rejection.

Accurate and not misleading

• The title, icon and screenshots must represent the app truthfully. Screenshots must show real in-app UI, not a mock-up of features that do not exist.
• No fake ratings, reviews or install counts, no text in the icon or title referring to rankings or promotions ("Top", "#1", "50% off").
• No claims of medical, financial or legal benefits you cannot substantiate.

Original and respectful of others' rights

• Do not copy another developer's name, icon or branding, or impersonate a well-known organisation.
• Do not use copyrighted images, music or text without a licence. (The stock photos, fonts and icons you use must allow commercial use.)

Appropriate

• Content must match the rating you declared.
• Policies cover user-generated content, ads, permissions, spam and minimum functionality, deceptive behaviour and families. A basic app that simply repackages a website or shows nothing useful may be rejected under minimum-functionality rules.

Safe

• Declare data practices truthfully (data safety form).
• Request only needed permissions; sensitive permissions get extra review.
• Include a visible way for users to delete their account and data if your app lets them create an account (Play requires this for apps that allow account creation).

Quality

• Fix crashes before publishing (lesson 49 pre-launch report). Google measures Android vitals (crash and ANR rates) and may reduce the visibility of apps with very bad ones.
• Use targetSdk at the current requirement.

Treat the policies as a checklist to run before each submission. Reading the Developer Program Policy Center pages once will save weeks of rejections.

1. Release → Testing → Internal testing, create a new release.
2. Upload the AAB (lesson 49). Play checks the signature, version code, target API, permissions and policy issues.
3. Enter release notes (what changed). Notes are per language.
4. Add testers (an email list) and share the opt-in link they receive.
5. Save, review and roll out. Internal tests are usually available within minutes.
6. When you are ready for wider testing, repeat in closed testing, and finally Production, where review typically takes from a few hours to several days. New developers and sensitive apps can wait longer. Plan buffer time before a launch date or an exam week.

What happens after you submit

 Upload bundle  ->  automated checks  ->  policy review (automated + human)
        |                                        |
   errors shown                         approved: goes live (or on your schedule)
   (fix, re-upload)                     rejected: email + Policy status page
                                         with the policy and what to change

If the app is rejected, read the exact reason on Policy status, fix all the problems mentioned (not only the first), and resubmit or appeal with a clear, respectful explanation. Repeated violations can put the whole developer account at risk, so do not "try again and see".

Managed publishing

You can turn on managed publishing so approved changes do not go live until you press Publish. This is useful for launching on a chosen day, or for releasing a code change together with new store text.

Mistake #1: Starting registration the week before launch. Symptom: verification delays. Fix: register early.

Mistake #2: Choosing "Free" without thinking. Symptom: cannot charge later. Fix: use in-app purchases or a second paid app if you might charge.

Mistake #3: Stuffing the title with keywords. Symptom: rejection or lower trust. Fix: brand plus a short truthful descriptor.

Mistake #4: Screenshots that show a mock-up, a device frame with fake features or tiny text. Fix: real UI, short captions, readable text.

Mistake #5: Copy-pasting a generic privacy policy. Symptom: mismatch with real data practices. Fix: write it from your actual data flows.

Mistake #6: Ignoring Data safety. Symptom: update blocked or app removed. Fix: audit every SDK.

Mistake #7: Using copyrighted images, music or competitors' logos. Fix: own or licensed assets only.

Mistake #8: Not testing the app access flow. Symptom: reviewer cannot log in, rejection. Fix: provide a working demo account.

Mistake #9: Fixing only one of several policy issues. Fix: read the whole message and fix everything.

Mistake #10: Promising results. Symptom: disappointed clients. Fix: never promise rankings or installs.

Question 1. What are the three listing items users see first in search results?

Question 2. Why must a free app be chosen carefully?

Question 3. What must screenshots show?

Question 4. What is the Data safety form for?

Question 5. Where do you send your first build for testing before production?

Go deeper: official resources

• Google Play Store Listing Certificate
• Google Play Console Help
• Publish your app (Android developers)
• Prepare your app for release, lesson 49 of this course