The Data safety section on a Play Store listing looks like a privacy nutrition label, and most teams treat it like one: a page of answers about what their code does. The form's actual scope is wider. Google's requirement, verbatim: "This includes data collected and handled through any third-party libraries or SDKs used in their apps." Your analytics SDK's behavior is your declaration, signed by you, on your listing.
The form has been mandatory since July 20, 2022, for every new app and every update, on every track (closed, open, and production; apps exclusively on internal testing tracks are exempt). Even an app that collects nothing must file the form and a privacy policy. This post covers what the form asks, where the SDK clause actually bites, and the carve-outs that are narrower than they look.
What the form asks
For every applicable data type (fourteen categories, from Location and Personal info through App activity to Device or other IDs), the form asks the same four questions: is this data collected, shared, or both; is it processed ephemerally; is collection required or can users choose; and for what purposes, picked from a fixed list of seven (app functionality, analytics, developer communications, advertising or marketing, fraud prevention, personalization, account management).
"Collected" is defined broadly: "transmitting data from your app off a user's device." On-device-only processing does not need to be disclosed, and neither does end-to-end encrypted data no intermediary can read. Everything else that leaves the phone is in scope.
Where the SDK clause bites
The form's own definition makes the coverage mechanical: any user data transmitted off device by the libraries and SDKs in your app counts, "irrespective of whether data is transmitted to you or a third-party server." Read that twice. If your crash reporter sends device IDs to its own servers, you declare it. If an ad SDK exfiltrates identifiers you never touch, you still declare it. The escape hatch is not "we don't see the data," because you do see the SDK's published guidance: Google explicitly points you to "your SDK providers' published Data safety information" and maintains the Google Play SDK Index for it.
Webviews follow the same rule: data collected from a webview your app controls counts; users "navigating the open web" in a webview does not.
The encryption question is all-or-nothing: "Is all of the user data collected by your app encrypted in transit?" One SDK sending plaintext anywhere and the honest answer is No, and that No is on your listing next to everything else.
The carve-outs are narrower than they look
Three exclusions exist and each has a fence. Ephemeral processing means data "only stored in memory and retained for no longer than necessary to service the specific request in real-time." A weather lookup qualifies; anything feeding a profile does not. Sharing exemptions cover service providers processing on your instructions, transfers for legal purposes, transfers the user initiates or that rest on a prominent in-app disclosure with consent, and fully anonymized data. And pseudonymous data must be disclosed: "data that can reasonably be re-associated with a user" does not count as anonymous. A Firebase installation ID is the form's own example of a device ID.
The newer additions: the form now carries the account-deletion questions too, including the web link every account-creating app must publish, which we covered in the account deletion post.
Enforcement is a comparison test
Google reviews the form in app review but does not complete or guarantee it for you: "You alone are responsible for making complete and accurate declarations in your app's store listing on Google Play." And it reserves the right to compare declaration to reality: "When Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action." The concrete consequence Google states plainly: rejected forms "prevent you from publishing new app updates." The declaration is also a policy document: the User Data policy independently requires you to "protect all user data with appropriate security measures, including modern cryptography for data in transit," so the form's answers can fail you on two fronts at once.
Apple's version is the same shape with different axes. App Store privacy details are also self-reported, also required for every submission, and also cover "the practices of third-party partners whose code you integrate into your app." Apple slices the data by linkage and tracking; Play slices by collected vs shared and surfaces security practices (encrypted in transit, deletion requests, independent review) on the listing itself.
Our position
Do the inventory before the form, not during it. List every SDK in the build, pull each provider's Data safety guidance from the SDK Index or their docs, and map each one to the fourteen categories before anyone touches Play Console. The form punishes the honest-sounding shortcut: "we don't collect personal data" is only true if every SDK in the binary agrees, and the listing does not care whose server received it.
The takeaway
Run this before your next submission:
your app controls; recipient does not matter
and true e2e data stay out of scope
google's sdk index links the big ones
optional, and up to seven fixed purposes
transit" is a no on the listing
never qualify; pseudonymous data always counts
publish a web deletion link
enforcement when behavior and declaration diverge
Data declarations like this are scope we price into custom software work, and the same inventory we keep for CashTaq. If your SDK list and your Data safety form have drifted apart, send us the listing.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
