Data safety forms with zero declarations are getting caught: auditing 21 apps and fixing them with CSV and the API

A phone number the user types in by hand, belonging to someone else, still counts as "phone number collection" to Google. After one rejection I compared all 21 apps' data-safety declarations against their source: 11 were wrong, and 3 had declared nothing at all. Why ad-only apps cannot declare zero, and how to fix the form with CSV and the API instead of the five-step wizard.

One rejection

In early September 2026 an update to the pet-care app was rejected for a data-safety mismatch. The app has a field where you note a vet's phone number, and the form did not declare phone-number collection. No READ_PHONE_STATE permission, not the device's own number, a number typed by the user about someone else, and it still counts as phone-number collection under Google's definition.

While an app is rejected, other changes get bundled with it. Three store-listing edits for that app were stuck as pending because of the data-safety rejection. When you receive a rejection, check the number of pending changes in the publishing overview.

Auditing all 21

If one app is wrong, the rest are suspect. I exported each of the 21 apps' current declarations from the console as CSV and compared them with the source: permissions, SDKs, input fields. Eleven were wrong.

• Zero declarations: 3 (the error-code app, the lottery app, the sunrise/sunset app)
• Wrong items declared (address and phone rows copied over from another app): 1
• Ad SDK collection set missing: 1
• "Shared" not declared (the ad SDK does not just collect, it shares with third parties): 6

The three with zero declarations were ad-only apps, and I had assumed "they collect nothing". Wrong. The AdMob SDK collects approximate location (IP), app interactions, and device or other IDs, and shares them for advertising. Ad-only apps must declare those three. Miss them when registering a new app and it goes live with zero declarations.

That same evening, one of the three received a policy email for "device or other IDs not declared", with a two-week deadline. Enforcement has started, and the other two are a matter of time.

CSV instead of the five-step wizard

The console's data-safety wizard is five steps of clicking, and with 21 apps that is a day gone. At the top there are "Export to CSV" and "Import from CSV" buttons.

1. Export: the entire current declaration comes out as CSV (782 rows × 5 columns for one app). This doubles as the backup before any change.
2. Fill in Response value only on the rows you need.
3. Import → review → save → submit from the publishing overview.

Adding a phone number takes five rows, following the same pattern as the existing name (PSL_NAME) rows:

PSL_DATA_TYPES_PERSONAL | PSL_PHONE | true
PSL_DATA_USAGE_RESPONSES:PSL_PHONE:PSL_DATA_USAGE_COLLECTION_AND_SHARING | PSL_DATA_USAGE_ONLY_COLLECTED | true
PSL_DATA_USAGE_RESPONSES:PSL_PHONE:PSL_DATA_USAGE_EPHEMERAL | | false
PSL_DATA_USAGE_RESPONSES:PSL_PHONE:DATA_USAGE_USER_CONTROL | PSL_DATA_USAGE_USER_CONTROL_OPTIONAL | true
PSL_DATA_USAGE_RESPONSES:PSL_PHONE:DATA_USAGE_COLLECTION_PURPOSE | PSL_APP_FUNCTIONALITY | true

Save the CSV without a BOM, with CRLF line endings. In step 4 of the wizard, a button labeled "N unanswered questions" can sit next to a status cell that says "Completed"; the status cell is the truth. Do not refill it because of the label.

Writing works through the API too

I first wrote that there was no API, then corrected myself. The Android Publisher API has applications.dataSafety(packageName, body={"safetyLabels": <entire CSV as a string>}). Edit the exported CSV and post it there, and the wizard never needs to be opened. There is no export API, so the backup still comes from the console. I have the patches for all 21 apps in one JSON file, to be applied together with the next all-app update once account-side release blocking is resolved.

Summary

• A phone number the user types in about someone else is phone-number collection.
• Ad-only apps must still declare location (IP), app interactions and device IDs. Zero declarations get caught.
• A rejection bundles other pending changes. Check the pending count.
• Instead of the wizard: export CSV → edit rows → import, or write through the API.
• Put the three ad-SDK declarations on the new-app registration checklist.