Google Play data safety form: AdMob + Firebase

Picture Word Connect has no accounts, no sign-up and no server of mine. It still sends data to Google from five different SDKs, and the Google Play data safety form wants every one of them accounted for. I filled it in on 2026-10-10, one page at a time, pasting each page of the form into Claude Code and asking what to tick.

The useful decision came before the first page. I did not answer from the privacy policy. I answered from the build. That turned out to matter: the next day an audit of the game found that the privacy page bundled inside the app still said data "never leaves your device" and named ads as the only third-party service. A form filled in from that text would have declared almost nothing, and been wrong on every page.

Start from the build

The inventory is three greps. Which Capacitor plugins are compiled into the Android app, which native libraries those plugins pull in, and what the manifest asks for:

grep implementation android/app/capacitor.build.gradle
grep -h implementation node_modules/*/android/build.gradle   # the plugins' native deps
grep -o 'uses-permission[^>]*' android/app/src/main/AndroidManifest.xml

That gave five SDKs that send anything off the phone, at the versions in the build as I write this:

SDK	Version	Sends
Google Mobile Ads, Next-Gen (ads-mobile-sdk), with Google's consent prompt	1.5.0	advertising ID, IP-derived approximate location, ad interactions, diagnostics
Firebase Analytics (@capacitor-firebase/analytics)	8.5.x	screens and events, app-instance ID, purchase events
Firebase Crashlytics and Performance	8.5.x	crash logs, traces, installation ID
Play Billing	9.1.0	purchase records; card details stay with Google
Play Games Services v2 (play-services-games-v2)	22.1.0	player ID, leaderboard scores

Local notifications, preferences, share, haptics, filesystem and the in-app review sheet stay on the device and need no declaration.

The source manifest asks for one permission, INTERNET. That is not what ships. The merged manifest from a release build that week has fourteen, including these:

uses-permission android:name="com.google.android.gms.permission.AD_ID"
uses-permission android:name="com.android.vending.BILLING"
uses-permission android:name="android.permission.ACCESS_ADSERVICES_AD_ID"

Read the merged one under android/app/build/intermediates/ before you answer anything about identifiers in the Google Play Console data safety form. The AD_ID line is also why the separate Advertising ID declaration under App content has to say yes, for advertising and analytics. That page and the Data safety form are filled in on different screens, and nothing in Play Console makes them agree for you.

Step 2 of the data safety form in Google Play Console

Step 1 is an overview with nothing to fill in. Step 2 is five questions, and the answers followed from the table:

Question	Answer	Why
Does your app collect or share any of the required user data types?	Yes	ads, Analytics and Crashlytics all send data
Is all of the user data collected by your app encrypted in transit?	Yes	all five send to Google over HTTPS (I took that from the SDKs; I did not capture traffic)
Which of the following methods of account creation does your app support?	My app does not allow users to create an account	nobody signs up
Can users log in to your app with accounts created outside of the app?	No	there is no login screen
Independent security review, UPI payments verified	left blank	neither applies to a game

The login question is the one that made me hesitate. The game does use a Google account, through Play Games, which signs most players in quietly at launch. But the question is about a login the app itself offers, a screen where someone types in an account made elsewhere. Play services does that sign-in, and the game never owns, stores or manages the account. So the answer is no, and with no account the form never asks for a delete-account URL.

The deletion answer, and why not 90 days

The last question in Step 2 is optional: "Do you provide a way for users to request that their data is deleted?" There are three answers, and one of them is a trap.

• Yes, with a URL. The listing then shows that you can request deletion. The URL has to lead somewhere that says how. The game's privacy policy has that section now: an in-game "delete data" row that removes the saved game and everything on the device, plus what it does not delete and where Google keeps the rest.
• No. Allowed, because the question is optional.
• "No, but user data is automatically deleted within 90 days." Do not pick this one with Firebase in the build. Google Analytics keeps event data for two months or fourteen, depending on a setting in the Analytics property, and AdMob keeps its data under Google's own rules. Neither is a number I control from the app, and neither is 90 days.

Step 3: eight data types and no more

The data types page is a long list of categories, each opened with Show. I ticked eight boxes:

Category	Ticked	Left empty, and why
Location	Approximate location	Precise location: the game has no location permission. The rough one comes from the IP address, through ads.
Personal info	User IDs	Name, email and the rest. The ID is the Play Games player ID sent with each score.
Financial info	Purchase history	Payment info: Google Play handles the card.
App activity	App interactions, Other actions	Search history, installed apps, user-generated content
App info and performance	Crash logs, Diagnostics
Device or other IDs	Device or other IDs

Everything else stays empty. Sharing goes through the Android share sheet, which the app hands off to and does not collect.

Two of those eight are a judgement call. User IDs and Other actions come from Play Games, and there is a fair argument that Google's own game service is Google's collection, not mine. I ticked both anyway. My reasoning was that a type declared and arguably unneeded is a smaller problem than one left out, but I have no review outcome that proves it either way.

Does Firebase app data collection need to be declared on the form?

Yes, and it accounts for most of the form. Firebase is behind App interactions, Crash logs, Diagnostics and Device or other IDs, alongside the ads SDK for three of them, and it logs in_app_purchase events on Android without being told to, which puts it under Purchase history too.

What Firebase does not do in this game is carry a user ID. The only setUserId in the source is in a test mock. No player identifier of mine reaches Analytics, so the User IDs tick rests on Play Games alone.

The rule I used to split collected from shared: Firebase processes the data for me, as a service provider, so its types are collected. Google Mobile Ads also uses what it receives for its own ad network, so anything the ads SDK touches is collected and shared.

Step 4: collected, shared, required

Step 4 asks the same five questions of each type. These are the answers I planned, and the Preview confirmed the shared half of them:

Data type	Collected / shared	Required	Collected for
Approximate location	both	yes	advertising, analytics, fraud prevention
User IDs	collected	users can choose	app functionality
Purchase history	collected	yes	app functionality, analytics
App interactions	both	yes	analytics, advertising
Other actions	collected	yes	app functionality, analytics
Crash logs	collected	yes	analytics
Diagnostics	both	yes	analytics, advertising
Device or other IDs	both	yes	advertising, analytics, fraud prevention

Ephemeral is no for all eight, because Analytics, Crashlytics and the ads SDK all store what they receive. Most types are required because the game has no switch to turn off analytics, crash reports or ads. The consent prompt decides whether ads are personalised, and the data is collected either way. User IDs is the exception, since a player can decline Play Games sign-in and the game carries on without it.

Purposes I left unticked: developer communications (local notifications are scheduled on the phone, nothing is pushed from a server), personalization, and account management.

The preview, and what I don't know

The Preview page is what the Google Play Store data safety form will show on the listing. It listed four shared types, approximate location, diagnostics, app interactions and device or other IDs, which is the ads SDK's set and what I expected. It differed from my plan in one place. I had meant the sharing purpose to be advertising only. The saved form lists analytics as a sharing purpose on all four, and fraud prevention on location and device IDs as well. I left it.

That is where the record stops. The preview matched the plan; I have nothing from Google's review of it, positive or negative. If you came here with an invalid data safety form Google Play Console notice, this post cannot tell you how to clear one, because I have not had one for this game.

What the inventory missed

Writing this up, I read the game's code again and found something the inventory got only half right. It found Play Games, and I described Play Games as a leaderboard. Picture Word Connect also keeps a Saved Game in the player's Play Games account, so progress survives a new phone. Same library, so nothing new showed up in the greps.

The form as I filled it declares gameplay data under Other actions, collected for app functionality, which is a reasonable home for a saved game too. The draft deletion paragraph I wrote that day was the real casualty: it said game progress lives only on the device. The published policy says what the game actually does. The lesson for the next form is to grep for what the game uses, not only for what it links.

Reusing it for the next game

Filling in the data safety form, Google Play app by app, is mostly the same answers each time. The Data safety page has Export to CSV and Import from CSV buttons. Once a form is saved, export it. A new game on the same stack imports the CSV, and the only work left is the difference between the two builds:

• no ads: approximate location goes, the three ads-shared types become collected only, advertising leaves every purpose, and the Advertising ID declaration becomes no
• no in-app purchases: Purchase history goes
• no Play Games at all: User IDs and Other actions go

Then re-read the merged manifest, check the deletion URL names the right game, and look at the Preview before saving. The answers transfer between games. The inventory has to be run again every time.