Google Play Data Safety Form, Field by Field
The Data safety form is public on the Play listing. For the same hiking app, on-device trails are not “collected,” and Google sign-in is.
Quick answer
How do you fill out the Google Play Data safety form?
In Play Console you say whether the app collects or shares user data, whether collected data is encrypted in transit, and whether users can request deletion. Collecting means transmitting data off the device. Trails that stay on the phone are not collected. Optional Google sign-in collects name and email. The answers are public on the store listing and must match the privacy policy. This is not Apple’s three privacy buckets.
On this page
Ridge Notes on Android is the same hike: a map, a trail saved on the phone, and an optional Google sign-in if the hiker wants an account. The Data safety section on the Play listing is where you say what that build does with user data. Shoppers read it before they install. Play does not let you hide the form behind a policy URL and hope nobody opens it. The URL still has to match.
The field list in this post comes from Play’s Data safety help article . Apple’s nutrition label is a different set of buckets. If you already filed location and iCloud on iOS, read App Privacy details for that store, then start this form from the Android binary. Do not copy “not linked” into Play. Play asks collected, shared, or both.
What the form actually asks
Open App content, Data safety, and start. First: is collected data encrypted in transit, and can users request deletion? Then select every data type collected or shared. For each type, say collected, shared, or both; whether processing is ephemeral; whether users can refuse; and the purposes for collection and for sharing.
There is no Apple-style tracking toggle on this form. Independent security review is optional on the same article. Do not invent extra badges. Optional Google sign-in means you do not qualify for the “we collect nothing” path.
Collected is not the same as shared
Collect means transmitting data off the user’s device. SDKs count, whoever owns the server. A webview your app controls counts. Open-web browsing in a webview does not. On-device processing is not collected. End-to-end encrypted data you cannot read is outside collection when it meets the rest of Play’s test. Pseudonymous data that can be tied back to a person still has to be disclosed.
Sharing means transferring collected user data to a third party: server to server, another app on the device, an SDK that sends it off device, or a webview you control. It does not include a service provider acting on your instructions, a specific legal demand, a transfer the user initiated and would expect, or data that is fully anonymized. A third party is anyone who is not you and not your service provider.
Ridge Notes, field by field
| Practice | Collected or shared? | What you tell the form |
|---|---|---|
| Trail file stored on the phone | Neither, if it never leaves the device | On-device processing is out of scope for collection. Do not list the file as collected. |
| Location used only to draw the map on device | Not collected, if coordinates are not transmitted | Same on-device rule. If a server receives the point, declare precise or approximate location. |
| Optional Google sign-in | Name and email are collected | The user can choose to sign in. Purposes include account management. Read the sharing exceptions before you mark the sign-in itself as shared. |
| Crash logs sent to your server | Collected | App diagnostics or interactions, purpose analytics, encrypted in transit. Declare sharing only if a third party receives them outside the service-provider rule. |
On-device trails are not collected. Optional Google sign-in collects name and email. Anything transmitted off the phone is collected, and it is shared only when a third party receives it outside Play’s exceptions.
Sign-in data versus the trail on the phone
If the trail never leaves the phone, do not declare it as collected. Precise location is a position inside an area smaller than 3 square kilometers, including the fine-location permission. Approximate location is a larger area, or a point inferred from an IP address. GPS that only draws the line on device is not collected. The moment a server or SDK receives the coordinate, declare the type you actually send.
Google sign-in sends name and email off the device. Those types are Personal info. Collection is optional if the map works without an account, and required if sign-in is mandatory. Account management fits creating the account. App functionality fits if a feature needs it. Do not select advertising or marketing for this build.
Is sign-in “shared”? Google is not you. The transfer happens because the hiker tapped Sign in, which is the shape of Play’s user-initiated exception: a specific action the user would reasonably expect. Read that exception against your implementation before you mark name and email as shared. If you later export the same email to a mailing-list vendor for promotions, that export is a separate share and needs the advertising or marketing purpose. Do not hide it inside the sign-in answer.
Encryption in transit and deletion
The security question is whether all user data the app collects is encrypted in transit. For Ridge Notes, sign-in and any crash upload need to travel over TLS. If one debug endpoint still uses cleartext, you cannot honestly answer yes for all collected data. Fix the endpoint, then answer. On-device trails do not change this answer, because they are not collected. The question is about data that leaves.
The next question is whether users can request deletion. A hiker with an account needs a way to ask you to delete the name, email, and anything else you stored. Put that path in the app or on a linked page, and say the same thing in the privacy policy. Do not tick the box for a control you have not built. The listing is public when the form is.
The policy and the other forms
Write the privacy policy so a hiker can find three sentences: trails stay on the device unless you upload them, sign-in is optional and collects name and email, and they can ask for the account data to be deleted. The privacy policy guide is the URL. If the policy says you sell location to advertisers, either the policy is wrong or the form is. Play can reject a listing for misleading metadata the same way a false screenshot fails review. That standard is discussed next to Apple’s version in the metadata rejection guide.
Content rating is the IARC questionnaire, not this form. File it from the content rating guide. A new personal account’s closed test does not waive Data safety. You should have the form ready before you ask strangers to opt in, because the listing they see can already show the section. AppGrowthKit can make the trail screenshot honest. It will not choose collected versus shared for you.
Complete Data safety for Ridge Notes
Answer from the Android build you will ship, including the sign-in SDK. Update the form when the practice changes. The section on the store listing is the public copy.
Trace what leaves the device
Install the release build and note every request: Google sign-in, crash upload, map tiles, anything else. Confirm whether trail coordinates are in those payloads. On-device files that never appear in a request are not collected. SDKs count even when the server is not yours. Write the list before you open the form so you are not clicking data types from memory.
Answer encryption and deletion first
If every collected payload uses encryption in transit, say yes. If one does not, fix it or say no. Then decide whether hikers can request deletion of the account data you store after sign-in. The control has to exist, and the privacy policy has to name it. These two answers are the security block at the start of the form. They are not optional flavor text under the data types.
Select types and mark collected or shared
Select name and email if sign-in can send them. Select precise or approximate location only if a coordinate is transmitted, including an inferred location from an IP address if that is how you use it. For each type, mark collected, shared, or both. Mark sign-in collection as something the user can choose if the map works without an account. Apply the user-initiated and service-provider exceptions only when they actually fit, and document why in your notes.
Set a purpose that matches the code
Account management fits creating the sign-in account. App functionality fits a feature that needs the data. Analytics fits crash logs you use to fix the map. Do not select advertising or marketing, personalization, or developer communications unless the build does those things. Purposes are chosen separately for collection and for sharing. A type you only collect still needs collection purposes. A type you also share needs sharing purposes too.
Compare the form to the policy and the listing
Read the privacy policy and the Data safety section side by side. The hiker should see the same story: local trails, optional sign-in, deletion request, no ads. Publish only when those match. If a closed test is still running, testers can already see listing assets, so do not leave a draft form that describes a different app. When you add a server backup of trails later, come back and declare that collection before the backup ships.
Key takeaways
- The Data safety section is public. Collect means data left the device. Share means a third party received it, outside Play’s exceptions.
- On-device trails and on-device map location are not collected. Optional Google sign-in collects name and email.
- Say whether collected data is encrypted in transit, and whether users can request deletion.
- Purposes include account management, app functionality, and analytics. Do not tick advertising if you do not advertise.
- The form has to match the privacy policy. Apple’s privacy buckets are a different filing.
Frequently asked questions
Do I declare trails that never leave the phone?
No. Play’s definition of collection is transmission off the device. Data the app only processes locally is out of scope. Ridge Notes’ trail file, and GPS used only to draw that line on the phone, are not collected if no SDK and no server receives them. You still declare name and email if Google sign-in can send them. If a later update uploads trails for backup, that upload is a new collection, often files and docs or precise location, and you update the form before users get the build. The on-device story is true only while it is true in the binary.
Is Google sign-in automatically “shared”?
It is collected, because the name and email are transmitted off the device. Sharing is a second question: transfer to a third party. Play excludes some transfers, including a service provider acting for you and a specific user-initiated action the person would reasonably expect. Tapping Sign in is that kind of action for the sign-in itself. If you then pass the email to an advertising network or a broker, that pass is sharing and needs a purpose such as advertising or marketing. Do not collapse both facts into one checkbox. Write down which servers receive the address.
What if I encrypt the database but not the network?
The form asks whether all user data the app collects is encrypted in transit. Encryption at rest on the phone does not answer that question. Sign-in tokens, crash logs, and any uploaded coordinate have to be protected on the wire if you want to answer yes. If any collected payload is cleartext, the honest answer is no until you fix it. On-device trails are not part of this question, because they are not collected. Do not mention a security practice the form does not ask for and call the section complete.
Does this replace the privacy policy?
No. The Data safety section is a structured summary on the store listing. The privacy policy is still required and has to describe the same practices in language the hiker can read, including how to request deletion if you told Play that path exists. A policy that lists advertising partners while the form says you do not share for advertising is a contradiction. Fix one of them before review. The iOS nutrition label is a third document. Keep the practices aligned even though the field names differ.
When do I update the form?
When collection or sharing changes: a new SDK, a trail backup, a crash tool that starts sending identifiers, or sign-in becoming mandatory. Play expects the section to stay accurate, and the listing shows it to everyone, including closed-test users who can see store listing assets. You do not wait for a starring review to notice. Content rating, if the hike is still the same non-social app, may not change in the same release. Data safety might. File the one that changed.
Keep reading
App Privacy Details: What to Declare
The nutrition label is three buckets you fill in App Store Connect. For a hiking app with on-device trails and optional iCloud, tracking stays empty unless you actually track.
Privacy Policy URL for App Store and Play
The policy has to name you, what you collect, why, and how to reach you. It has to match the nutrition label and the Data safety form.
Google Play Content Rating Questionnaire
The IARC questionnaire is how Play gets a rating. Answer for the chat app you ship, including user-generated messages. A low rating you did not earn can get the listing pulled.
App Store Metadata Rejection: What Triggers It
Guideline 2.3 is accurate metadata. A “#1 workout” line and a competitor’s name in the keyword field are the kind of thing that gets a fitness app sent back.
Google Play Closed Testing Before Production
A new personal Play account cannot ship a habit app to production until a closed test has at least 12 testers opted in for 14 days straight. An opt-out resets that tester.
Free tools that help here
Top App Store Apps
Track Apple App Store top charts across 30 countries. View top free and paid rankings for ASO research - updated from Apple's public RSS feed.
ASO Character Counter
Count characters for every App Store and Google Play metadata field against exact store limits. Live counts and over-limit warnings - nothing gets truncated at submission.
Screenshot Beautifier
Add polished backgrounds, padding, shadows, and rounded corners to any screenshot in seconds. Perfect for social posts, docs, and portfolios.
The listing should match the form
AppGrowthKit builds the Play screenshots from the real trail screen so the listing does not claim a data practice the Data safety section denies.
Try AppGrowthKit for Free