Google Play privacy policy URL, wrong game

My Google Play listings need a privacy policy URL before a game can be published, so the policy page always ships first. For my last two games, ASMR Logo Craft Block and Picture Word Connect, the /privacy/<game>/ page went live as a "coming soon" entry a few days before the game, the URL went into the listing, and then the game launched.

Both policies passed my build checks. Both had the controller, the legal basis for each processing, the Article 15–22 rights and the CNIL, which the build refuses to ship without. And both described a game that was not the one on the store.

How a privacy policy goes stale before launch

The ASMR Logo Craft Block policy was written on 2 October, and at the time every claim in it was checked against the game's code. That code had an optional Google or Apple sign-in through Firebase Authentication, and a cloud save in Firestore. So the policy described both, carefully: what the Firestore record holds, that the email address the sign-in passes on is never used, how to ask for the sign-in account to be deleted.

Between that day and launch, the sign-in came out of the game. Cloud save moved to a Play Games Saved Game with a silent Play Games sign-in, and there is no sign-in button anywhere. The policy did not move with it, because nothing connects a commit in the game's repo to a text file in the site's repo.

Picture Word Connect's policy, written on 10 October, started from the ASMR one and was adjusted where the two games differ. It got the Firebase part right, and inherited other claims that were wrong for it.

I had seen the copying problem once already. In September I asked for the Football Logo Quiz policy to be "exactly like" the Logo Quiz one, and writing it turned up that Logo Quiz declares Firebase Anonymous Auth and Firestore while the football game does not even have them as dependencies. That one was caught because the game's code was opened while the policy was written. The ASMR one was checked against code too, just code from a build that never reached the store.

The audit: every section against the shipped code

After launch I had Claude Code clone the game repo, plus the shared packages it pulls in, and go through the policy one section at a time, with a verdict and a file and line for each claim. For ASMR Logo Craft Block it read the code at the commit the store build came from; for Picture Word Connect, at the commit labelled store release 1.0.6.

The verdicts for ASMR Logo Craft Block:

§3  Personal information        PARTLY
§4  Consent choices             TRUE
§5  Optional sign-in & save     FALSE
§6  Leaderboard                 PARTLY
§7  Analytics                   PARTLY
§8  Crash and performance       PARTLY
§9  Ads                         PARTLY
§10 In-app purchases            TRUE
§11 Notifications, sharing      TRUE
§12 Children                    nothing in the code to check
§13 Offline use                 FALSE
§14 Who receives data           FALSE as written
§15 Retention                   PARTLY
§16 Legal bases                 PARTLY
§17 Your rights                 PARTLY

Three TRUEs out of fifteen. Section 5 was false end to end, and six other sections inherited the error, because a sign-in account turns up everywhere: in analytics ("these events are also labelled with your Firebase account identifier"), in crash reports, in the list of recipients, in retention, in the legal bases, in the delete button.

What was wrong, across the two games:

• A sign-in and a database that do not exist. No Firebase Authentication, no Firestore, no Google Sign-In, no Sign in with Apple. No account identifier on Analytics or Crashlytics, because there is no account to attach.
• "You can play offline." Section 13 said so in both policies. Both games cover everything with an offline screen the moment the network drops. The game's own source says so at the top of the file: The offline gate: the game may not be played offline.
• A share feature that does not exist. Picture Word Connect's policy described sharing a picture of a result. A search of the game's src/ for calls to the share function came back with 0.
• One leaderboard where there are two. Picture Word Connect has one per language.
• The delete button. In ASMR Logo Craft Block, "Delete My Data" deletes the Play Games save first, and if that fails it deletes nothing and says so. The policy said it deleted the Firestore record. In Picture Word Connect the row is called "delete data", not "Delete My Data", and it leaves the consent answer and the leaderboard scores.
• Things the policies left out. App-open ads, or the one at launch. A rewarded ad that gives a life once a day. A random install ID inside the cloud save. The cross-promo banner for my other games.
• iOS. Both policies described Game Center on iOS. Both games have it wired up, but the Game Center IDs are still placeholders, so on an iPhone none of it runs.

The audit also turned up nothing worse than the policy admitted. In ASMR Logo Craft Block it found no tracking-permission prompt on iOS, so no iOS advertising identifier, and the only Firebase plugins are Analytics, Crashlytics and Performance. A policy can be wrong in the safe direction, and these mostly were: they promised more processing than the game does. That is still a false statement in a legal document, and a reader deciding whether to sign in to something has a right to find out there is nothing to sign in to.

Before writing anything I checked the claims that changed the policy most against the code myself: the offline gate, the ad formats, the share calls. All of them matched the audit.

Changing the policy, not the Google Play privacy policy URL

The fix was to rewrite sections 3 to 18 of each policy and splice them in. The header and the closing block stayed byte-identical, because the build parses the policy text out of those exact lines. The controller, the Article 15–22 rights and the CNIL did not change, and the legal bases changed only where the processing under them had. "Effective Date" stayed; "Last Updated" moved to the day of the fix. The two diffs came out at 41 insertions and 42 deletions, and 44 and 41.

The URL did not move. That is the part that matters for the store. The Google Play privacy policy URL in each listing still points at /privacy/asmr-logo-craft-block/ and /privacy/picture-word-connect/, so there was nothing to change in the Google Play Console privacy policy URL field. The document behind the link changed; the link did not. A google play console update privacy policy url is only needed when the address moves.

Search for google play change privacy policy url and almost everything you find is about the opposite case, where the address itself moves. I went through that one when the policies left Blogger, and moving the URL without breaking it is a different job. Here, the Google Play privacy policy link was fine all along. What it pointed at was not.

Both fixes went out through a pull request each, with the same gate as everything else, and I checked the live site rather than the build output: version.json reported each fix's commit once it deployed, the live pages carried the new "Internet Connection Required" section, and neither mentioned Firestore any more.

Adding the privacy policy in Google Play Console comes first

The order that produced this problem is the order my releases run in. The listing needs a policy URL before I can publish, so the page has to exist while the game is still changing. The console side is short: the field lives under App content, and the earlier post walks through it.

What I do differently now is treat that first version as provisional. The page goes up early so the listing has a working Google Play store privacy policy URL. The audit happens after the release build exists, against the commit that build came from, and not against the previous policy or the code from the week it was written.

Apple Store and Google Play Store, one privacy policy URL

Each game has one policy at one URL, and it covers Android and iOS together. That is convenient, and it is also where the policy was most wrong. Neither game runs Game Center yet, so the iOS half described a leaderboard and a cloud save that do not exist on an iPhone. The rewrite says so directly: built, not switched on, and until it is, nothing about your progress leaves the device.

When the iOS side is switched on, that paragraph is wrong again, in the other direction. One URL for both stores means one document that has to be true of both builds at once.

The same claims lived elsewhere on the site

The policy was not the only text that described a game I had not shipped. Once both games were live:

• The share card for each game page had "No purchases" and "Plays offline" pills baked into the image script. Both were false for both games.
• The home page said none of the games had in-app purchases. These two sell coin packs and ad removal, though nothing in either is reachable only by paying.
• A parked blog post said the same thing about purchases.
• The game count was typed by hand into the headline, the About page, the share cards and my own repo notes, and went from six to seven to eight one file at a time.

Each of those was fixed in the same pull requests that promoted the games from "coming soon". None of them was caught by a check. They were found by searching the site for the claim once I knew it was false.

What I have not checked: the Data safety form

The policy is one of two documents Google holds me to. The other is the Data safety form in Play Console, which I fill in by hand, and which nothing in my repo can see.

If either form was filled in from the old policies, it may still declare an email address, account sign-in or cloud storage that the games do not have. I have not confirmed that it was updated. The policy is fixed and verified live; the form is still on my list, and until it is done the two documents may disagree with each other.

Takeaway

• A privacy policy written before launch describes a build, not a game. Audit it again against the commit the store build came from.
• Go section by section with a verdict per claim. "Looks right" is how three TRUEs out of fifteen got through.
• Change the document, keep the Google Play Console privacy policy link where it is.
• When a game stops doing something, search the whole site for the sentence that says it does.