Your first Google Play submission: every App content declaration, explained
The game was finished, so I assumed publishing would take an evening. It didn't. Between a signed Android App Bundle and a live listing sits the App content section of the Play Console: about a dozen questionnaires, each one something Google can hold you to later. This post goes through what I declared for Word Search, my first game on the new engine, and why. If you're about to publish your first Android game, this should save you some guessing.
Start with the pages Google will check
Two URLs need to exist before you start: a privacy policy and a delete your data page. Mine live on this site at uyllii.com/<game>/privacy and uyllii.com/<game>/delete-data. The delete page lists the steps first, then what gets deleted and what is kept.
Make sure those pages describe the right game. I reuse a template, and twice a copied privacy page described the game it was copied from. Now I read every privacy page in full before I submit anything.
The URL in the console also has to keep working. One of my games was rejected for an "Invalid Privacy policy" because months earlier I had pointed the console at a subdomain that no longer resolved. The field wasn't empty, so nothing looked wrong. Now a check confirms that the console URL is exactly the one I expect and that it returns a 200.
Ads, app access, and the boring ones
- Ads: Yes. A banner during play, an interstitial between puzzles, and an optional rewarded video.
- App access: everything is available without a login. There are no accounts.
- Government, financial and health apps: No, No, No.
- Notifications: only a local daily-puzzle reminder, and the game asks for permission after the second solved puzzle, not on first launch.
Data safety: say what the SDKs collect, not just what you wrote
This is the form people get wrong, because you're declaring what your libraries collect as well as your own code. With AdMob, Firebase Analytics and a purchases SDK on board, my honest answers were:
- Collected and shared: the advertising ID (for ads and analytics), app interactions (game events), and purchase history.
- Not collected: location, personal info, messages, photos, files, contacts.
- Encrypted in transit: yes. Accounts: none. Deletion requests: yes, through the delete-data page.
I keep the answers in a file in the repo, with one rule written at the top: if the code changes (a new SDK, a server), the file changes in the same commit. The Advertising ID declaration also has to match the AD_ID permission in your manifest. Mine once didn't, and the pre-review check flagged it.
The content rating (IARC)
The rating questionnaire asks about violence, fear, sexuality, language, drugs, crude humour, gambling, user-generated content and location sharing. For a word search all of those should be "no", but that's only true if the word lists are clean. So I scrubbed every theme of alcohol, sexual and violent words before answering. Word Search came out as Everyone and PEGI 3.
Answer this one honestly, and read the rating you actually got afterwards. Later in the year a video poker game of mine was rated PEGI 3 because a gambling question was answered with a default. I'll write that one up separately.
Target audience: why I tick only 18+
This is the declaration with the biggest effect on revenue. If you include any age band under 13, the app joins the Designed for Families programme: no advertising ID, restricted ad formats, and from what I've read, eCPMs roughly halved. The 13–17 bands bring their own teen ad protections.
Word search players skew 35 and over, and the game has no mascots and nothing aimed at kids, so I tick 18 and over only and answer "Appeals to children unintentionally: No". That's an honest answer for a plain letter grid. It wouldn't be for a cartoon game, and the policy team does look.
Countries, testing and review
- Countries: all of them by default. You only narrow the list if the content is banned somewhere, which is a lesson I learned later with that video poker game.
- Internal testing first: I upload the same bundle to the internal track for a few family testers, then to production as a draft. "Send changes for review" makes production live on approval, so there's nothing to promote afterwards.
- Review times: my first two games were approved the same day. Later new apps took four or five days. Google says a first review can take up to seven.
One rule cost me two restarted reviews before I learned it: don't touch an app while its review is pending. No new tester rollouts, no listing edits. Any change can cancel the review and put you back at the end of the queue.
The store listing itself
Keep the description factual. My FreeCell listing was rejected for "EVERY DEAL NUMBERED, #1 TO #32000" and "just like the Windows game". To a reviewer, "#1" reads as a ranking claim and Windows is someone else's trademark. Now a pre-check refuses # before a number, other companies' product names, and phrases like "best game" or "award-winning" in any language.
Doing all this by hand the first time took me most of a day. By the third game I'd automated nearly all of it, which is a story for another post.