Mapping App Data to Google Play's Data Safety Taxonomy

In short: every Android app on Google Play has to declare its data collection against roughly 14 fixed categories that Google defines, not categories the app's own team chose. That declaration is, structurally, an ontology-mapping problem — an internal data model has to be mapped onto someone else's category scheme, kept current as SDKs and schemas change, and re-checked every time the taxonomy itself shifts.

Most engineering teams treat the Data Safety section as a one-time form to fill in before a release ships, then forget about it. That framing misses what the form actually asks for. It is not asking "what does your privacy policy say" — it is asking for a precise, category-by-category mapping between every data type an app (and every SDK bolted onto it) touches and a closed set of labels that Google owns and periodically revises. Treating that mapping as paperwork, done once, is exactly how it drifts out of sync with what the app actually does.

That drift is not hypothetical. Google tightened the Data Safety requirements through 2025 and into 2026, reclassifying how Android ID handling is declared, sharpening the definition of what counts as "sharing," and adding automated pre-review checks that compare declared data types against what the app's code actually does. None of that is "set once and forget" — it is a taxonomy that moves, and a mapping that has to move with it. For teams building apps with non-trivial data flows — field-service tools with GPS and photo evidence, logistics apps with partner syncing, health and fintech apps with regulated data — that mapping work is closer to schema and architecture design than it is to filling in a legal checkbox, which is where our engineering team typically gets pulled into the conversation alongside the data-model work itself.

What Is the Google Play Data Safety Section, and Why Does It Need a Taxonomy?

Every app published on Google Play must complete a Data Safety section, a structured form that asks developers to declare, for each of roughly 14 fixed categories, whether the app collects or shares that type of data. The categories span Location, Personal info, Financial info, Health and fitness, Messages, Photos and videos, Audio files, Files and docs, Calendar, Contacts, App activity, Web browsing, App info and performance, and Device or other IDs. These labels are not negotiable per app — they are Google's taxonomy, fixed across every listing on the Play Store, and every developer has to translate their own data model into it rather than describing their data in whatever terms their own schema uses.

That translation step is the taxonomy-mapping problem in miniature. An app's internal schema might track a user_location_ping table, a crash_report object, and a payment_token field — none of which are category names Google recognizes. Someone on the team has to decide which Play category each of those internal entities belongs to, and that decision has to stay correct as the schema evolves. Filling the form in once, without a durable record of how each decision was made, means the next person who touches the schema has no way to know what has already been mapped and what hasn't.

None of the 14 categories were designed around any individual app's schema. They were designed to be general enough to cover every app on the Play Store, from a single-purpose flashlight utility to a multi-tenant enterprise field-service platform, which means every app's mapping is a compression exercise: a rich internal data model has to be reduced to a handful of standardized labels without losing the distinctions that actually matter for a user deciding whether to trust the app. Getting that compression right once is tractable for a small team with a simple schema. Keeping it right as the schema grows, as SDKs get added and swapped, and as the categories themselves get revised, is the part that most teams underestimate.

"Collected" vs. "Shared": Two Different Questions, One Form

The single most common point of confusion across developer guides to this form is the distinction between data that is collected and data that is shared. Collected means the data is transmitted off the user's device to a server at all — the app's own backend, an analytics endpoint, a crash-reporting service. Shared means that data, once collected, is also transferred to a separate company that is not acting purely as the app's own service provider. A single data type can be collected without being shared, such as crash logs sent only to the developer's own monitoring backend. The same data type can be both collected and shared, such as advertising identifiers sent to both the app's analytics vendor and a third-party ad network.

The form also asks whether each declared data type is optional or required for the app's core functionality, and whether it is processed ephemerally or persisted. These are four separate axes — collected, shared, required, persisted — applied to each of 14 categories, which is why a careless first pass at the form so often produces declarations that are technically filled in but substantively wrong. Getting the collected/shared distinction right for every data type an app touches is not a legal nuance; it is the central factual content of the entire form.

Where Declarations Drift: SDKs, App Updates, and Ownership Gaps

Almost no modern Android app collects data only through code its own team wrote. Firebase Analytics, Crashlytics, AdMob, Google Sign-In, Play Billing, and a long list of third-party analytics and attribution SDKs each carry their own data collection behavior, and each has to be declared in the same form as the app's first-party data flows. Google's policy makes the publishing developer responsible for declaring everything an installed SDK does, not just what the app's own code does — ignorance of what a bundled SDK collects is not a defense against an inaccurate declaration.

The practical problem is ownership. On most teams, no single engineer has a complete, current view of every SDK's data behavior, every schema field that persists off-device, and every app update that adds a new data flow. A feature team ships a new in-app chat feature that happens to log message metadata to an analytics SDK; nobody revisits the Data Safety form, because the form is associated with "the release process," not with "the feature that just shipped." Multiply that across a few release cycles and the gap between declared and actual behavior widens quietly.

This is a documented problem, not a theoretical risk. Independent audits of top Play Store apps — the kind of methodology used in Mozilla-style privacy research and echoed across multiple developer guides to the Data Safety form — have found that declared labels on a meaningful share of popular apps do not match the apps' own stated privacy-policy behavior. That gap exists precisely because the declaration is treated as a point-in-time form submission rather than a maintained artifact that tracks the app's actual, evolving data flows.

Building an Internal Data Ontology That Maps Cleanly to Play's Categories

The fix is not a better one-time audit — audits go stale the moment the next SDK or schema change ships. The more durable fix is a small, versioned internal mapping: a lightweight ontology that names every data entity the app persists or transmits, and states, as a standing fact rather than a one-off judgment call, which Play Data Safety category it belongs to and whether it is collected, shared, and required.

This does not need to be a formal ontology in the OWL sense to do its job. It needs to be an explicit, reviewable artifact — a table, a schema annotation, a small internal registry — that every new data field or SDK addition gets checked against before a release, instead of the form being re-derived from scratch by whoever happens to own that release.

A Minimal Entity-to-Category Mapping Table

A workable starting point lists every distinct internal data entity alongside its Play category, its collected/shared status, and its declared purpose. For example:

Internal data entity	Play category	Collected / shared	Purpose
UserLocationPing	Location	Collected only	App functionality
CrashReport	App info and performance	Collected only	Analytics / crash reporting
PaymentToken	Financial info	Collected and shared	Payment processing (shared with payment SDK)
PhotoAttachment	Photos and videos	Collected only	App functionality
AdvertisingId	Device or other IDs	Collected and shared	Advertising or marketing (shared with ad network)

This table is the actual ontology artifact: a small, named set of entities, each formally tied to one of Google's categories, maintained as code or documentation rather than reconstructed from memory every time the form needs an update. Every new SDK or schema field gets a row before it ships, not a retroactive guess after an app update is already live.

Versioning the Mapping as the Taxonomy Changes

The mapping also has to carry a version, because Google's own taxonomy is not static. The 2025–2026 reclassification of how Android ID is declared is a concrete example: apps that had correctly mapped Android ID under one set of rules needed their declarations revisited once Google tightened the definition, not because the app's own data flows changed, but because the category definition underneath them shifted. A mapping table with a version number and a change log catches that kind of event explicitly — a taxonomy revision becomes a trigger to re-check every row that touches the affected category, rather than something that gets noticed only if someone happens to re-read the whole form.

A Worked Example: Mapping a Field-Service App's Data Model to the Form

Consider a field-service app used by technicians to log site visits: it records GPS pings when a job starts and ends, attaches photos as proof of completed work, reports crash telemetry through Crashlytics, and processes customer payments through a billing SDK.

Using the mapping table pattern above, the GPS pings map to Location, collected only, required for the app's core job-tracking function. The photo attachments map to Photos and videos, collected only, required. The Crashlytics telemetry maps to App info and performance, collected only, optional, since the app functions without it. The payment SDK's token handling maps to Financial info, collected and shared with the billing provider, required for the payment feature specifically rather than the whole app. Walking through each entity this way, instead of trying to describe the app's behavior holistically, is what keeps the Data Safety form's category-by-category structure matched to the app's actual, itemized data flows.

Notice that "required" in this example is scoped per entity, not applied uniformly to the whole app. The payment token is required only for the subset of functionality it supports — processing a payment — while a technician who never initiates a payment inside the app never triggers that data flow at all. A mapping that tracks required/optional per entity, rather than treating the whole app as either a data-collecting app or not, produces a more accurate form than one built by asking "does this app collect financial data" as a single yes/no question. The same granularity matters for the shared column: the payment token is shared with exactly one named processor, not with an undifferentiated list of "third parties," and the form rewards that specificity because Google's own review tooling checks declared sharing against what the bundled SDKs actually transmit.

What Happens When the Form and the Code Disagree

A Data Safety declaration that does not match an app's actual behavior is a policy violation, not a cosmetic inconsistency. Google's enforcement for mismatched declarations ranges from a policy warning requiring a correction, to app listing removal, to account-level enforcement for repeated or severe violations. Beyond the direct enforcement risk, the kind of label-accuracy gap documented in independent audits of popular apps carries a reputational cost once it becomes public: users and researchers increasingly treat a mismatched Data Safety label as evidence the developer either doesn't know or doesn't disclose what their own app does, which is a harder problem to repair than a corrected form submission.

The cost of a mismatch is also uneven across categories. A stale declaration on a low-sensitivity category such as App info and performance is unlikely to draw scrutiny on its own. A stale declaration on Financial info, Health and fitness, or Location — categories that regulators and platform reviewers treat as higher-risk by default — is far more likely to trigger a manual review, and far more costly to explain after the fact, because the gap looks less like an oversight and more like an attempt to understate a sensitive collection practice. Prioritizing the mapping's accuracy by category sensitivity, rather than treating all 14 categories as equally low-stakes to get right, is a reasonable way to spend limited review time when a full audit of every data flow is not realistic before every release.

Keeping the Mapping Current as Your App Evolves

Because the mapping drifts for identifiable reasons, it can be re-checked on identifiable triggers rather than on a calendar guess. The concrete events worth treating as mandatory re-check triggers are:

• A new SDK is added to the app, even for an unrelated feature — every new SDK is a new, unaudited source of potential data collection.
• A new field is persisted or transmitted by the app's own code, including fields added for debugging or internal analytics that were never meant to be user-facing.
• Google revises the taxonomy itself, as happened with the Android ID reclassification — a taxonomy change can make a previously correct mapping wrong without any change to the app's own code.
• A major feature ships new data flows, such as adding chat, file sharing, or a new payment method, each of which typically introduces at least one new entity that needs a category assignment.

Tying the mapping's review to these triggers, rather than to a release-calendar reminder that competes for attention with every other release-checklist item, is what keeps the gap between declared and actual behavior from reopening every few release cycles.

Frequently Asked Questions

Does every app need a Data Safety section, even ones that collect no data?

Yes. Every app on Google Play must complete the Data Safety section, including apps that genuinely collect no user data. In that case, the declaration states that no data is collected or shared, but the form itself is still a required part of the listing, and Google Play Console will not allow a publish to proceed with the section left blank.

What's the difference between a data type being "optional" and being "required"?

Required data is necessary for the app's core functionality to work at all, such as location data for a navigation app. Optional data is collected for a secondary purpose, such as analytics or personalized ads, and the app can still function if a user declines it. The form asks developers to mark each declared data type one way or the other, and that distinction maps directly onto whether a data flow is mandatory or elective in the underlying data model.

Do I have to declare data collected by third-party SDKs I didn't write?

Yes. Google's policy holds the app, not the SDK vendor, responsible for every data collection event that happens inside the installed app, regardless of which party wrote the code that collects it. An SDK's own privacy documentation is the starting point for finding out what it collects, but the declaration obligation sits with the publishing developer.

What counts as "encrypted in transit" for the security-practices questions?

Data is considered encrypted in transit when it travels between the app and any server over a secure, encrypted connection, such as TLS, for every network request that carries it. If any code path sends the same data type over an unencrypted channel, even occasionally, the accurate answer is that the data is not consistently encrypted in transit, and the form should reflect the weaker case rather than the typical one.

How often does the Data Safety form need to be reviewed, not just filled in once?

There is no fixed calendar interval set by Google, but the form needs review at every point where the underlying data flows could have changed: a new SDK is added, a new field gets persisted, a feature release introduces a new data flow, or Google revises the taxonomy itself, as it did with Android ID handling. Treating those events as triggers, rather than reviewing on a schedule, catches drift closer to when it is introduced.

Does an internal data ontology replace the need for a privacy policy?

No. A privacy policy is a legal document aimed at end users and regulators; an internal data ontology is an engineering artifact aimed at the team maintaining the app. The ontology makes it easier to keep the privacy policy, the Data Safety form, and the app's actual behavior consistent with each other, but it does not substitute for the legal document itself.

For a worked SDK-by-SDK declaration walkthrough, see The IOn Project's guide to the Google Play Data Safety section.