How to Fill Out the Google Play Data Safety Form Without Rejection

You probably landed here after a warning in Play Console, a blocked update, or a moment of doubt before your first release. Don't panic. Start with these five steps:

1. List every piece of data your app sends off the device, including traffic to third party services.
2. Open the data safety guidance of every SDK (software development kit) in your build and add it to the list.
3. Check that your privacy policy says exactly the same thing as that list.
4. If users can create an account, prepare an in-app deletion path and a web deletion link.
5. Fill out the form from these documents and read the preview before you submit.

In this guide, Talha Aslan and team walk you through the whole process. We checked the rules against the official Play Console Help article on the Data safety section. However, Google updates questions and scope from time to time, so always confirm the current wording on the official page.

Which apps must complete the form?

According to the official help page, every developer with an app published on Google Play must complete the form. In addition, the scope goes beyond production. Apps on closed testing and open testing tracks need a completed form too. The same goes for preinstalled apps that update through Google Play.

That said, a few exemptions exist. Apps that are only active on the internal testing track do not need the form. In other words, you can skip it while your own team tests early builds. However, the obligation starts the moment you move to closed testing. For that reason, we always prepare the form before a closed test begins. New personal accounts also face a long closed testing phase, so our guide to the Google Play closed testing requirement is worth a read.

In addition, system services and private apps fall outside the requirement. If you distribute an app only inside your own organization, check the official page to confirm whether this exemption covers your case.

Does an app that collects no data still need the form?

Yes, it does. Google states this clearly: developers whose apps collect no user data must still complete the form and provide a privacy policy link. The difference is that you then skip most of the form. In the first section, you simply declare that you neither collect nor share data.

However, many developers make one common mistake here. Their reasoning goes like this: "We have no server, so we don't collect anything." Yet if an ad SDK, an analytics library, or a crash reporting tool sends data off the device, that counts as your collection. For example, a fully offline calculator can honestly say "no data." Once you add ads to the same app, though, device identifiers and app interactions will most likely belong in the form.

In short, review the dependency list in your build file line by line before you answer "no data." If you have any doubt, check the guidance that each SDK provider publishes.

What exactly does Google mean by "collecting" data?

The official definition is simple. Collection means transmitting data from your app off the user's device. So if data leaves the device and reaches your server, a cloud service, or an SDK provider, Google treats it as collected. Likewise, data that your app gathers through a webview it controls counts too.

Still, two situations fall outside this definition:

• Data that your app processes only on the device and never sends anywhere.
• Data that uses end to end encryption so that no intermediary, including you, can read it.

Pay attention to pseudonymous data as well. Google says you must declare pseudonymous data if someone could reasonably link it back to a user. For example, a random user ID contains no name on its own. If it can match your account records, though, you must declare it. Therefore, ask whether a piece of data can join another record before you claim it carries no identity.

What counts as "sharing," and which transfers are exempt?

Sharing means transferring user data that your app collected to a third party. In practice, the transfer can happen server to server, on the device to another app, through an SDK, or through a webview you control. A third party is any organization other than you and your service providers.

The official page also lists transfers that you do not need to declare as sharing:

• Transfers to service providers that process data on your behalf and follow your instructions.
• Transfers for specific legal obligations or government requests.
• Transfers that the user starts and reasonably expects, or that follow a prominent in-app disclosure and consent.
• Data that you fully anonymize so that nobody can link it to an individual user anymore.

The service provider exemption causes the most mistakes. According to Google's FAQ, an SDK that builds advertising profiles across several customers does not qualify. As a result, calling an ad network "our service provider" to avoid a sharing declaration is usually wrong.

What is ephemeral processing, and how do you declare it?

Ephemeral processing means you keep data only in memory and hold it no longer than you need to serve one specific request in real time. The official example is a weather app. The app uses location only to fetch the current forecast and does not store it.

So do you still declare that data? Yes. You include ephemerally processed data in your form answers. If it meets the definition, however, Google does not show it to users on the store listing. In other words, you never hide it in the form; you simply mark it as ephemeral.

On the other hand, Google draws a firm line. Data that you use for advertising or user profiles cannot qualify as ephemeral. Consider an example scenario with a food ordering app. If you use location only to find the nearest branch at that moment, it may count as ephemeral. If you store the same location to target promotions, it no longer qualifies and needs a full declaration.

Which data types does the Google Play data safety form cover?

First, note that Google groups data types into categories. In the form, you mark which subtypes you collect and which you share for each category. The categories on the official page include the following:

• Location: approximate location and precise location.
• Personal info: name, email address, user IDs, address, phone number, and other personal info, including sensitive categories.
• Financial info: payment info, purchase history, and other financial info.
• Messages, photos and videos, audio: in-app messages, photos, videos, and voice recordings.
• Files, calendar, and contacts: documents, calendar events, and contact lists.
• App activity and web browsing: app interactions, in-app search history, installed apps, and browsing history.
• App info and performance: crash logs and diagnostics.
• Device or other IDs.

Don't overlook crash logs. If you use a tool such as Crashlytics, you collect app performance data. We cover how these tools relate to store quality in our article on app crash rate and store thresholds.

How do you declare data that your SDKs collect?

The official rule is clear. You must declare data that third party libraries and SDKs in your app collect or share. It makes no difference whether the data goes to you or straight to the SDK provider. Google also states that you are responsible for making sure this code complies with Play policies.

That is why we build an SDK inventory on every project. The process looks like this:

1. List every dependency in your build file, including transitive libraries.
2. Find the data safety guidance that each SDK provider publishes.
3. Where possible, check the Google Play SDK Index for known data behavior.
4. Note which settings make each SDK send which data. For example, write it down if you turned off advertising ID collection.
5. Move the inventory into the form and update it with every release.

As an example scenario, picture an app with three SDKs for analytics, ads, and crash reporting. Even if your own server only stores an email address, the form must also cover device IDs, app interactions, and diagnostics.

How do you choose data usage purposes?

For each data type, you select why you collect it and why you share it. Collection purposes and sharing purposes are independent, so they can differ for the same data. The official list of purposes looks like this:

• App functionality.
• Analytics.
• Developer communications.
• Advertising or marketing.
• Fraud prevention, security, and compliance.
• Personalization.
• Account management.

Above all, base your choices on real use. For instance, if you use an email address for login and also for a newsletter, select "Developer communications" next to "Account management." On the other hand, ticking every purpose "just in case" is also a mistake. It shows users a bloated summary and may contradict your privacy policy.

In practice, fill out the purpose section together with your developers while the code and your vendor contracts sit in front of you.

How do you decide between required and optional data?

The form asks you to label each collected data type as required or optional. Optional means users can choose whether to provide the data or can turn its collection on and off.

However, Google sets a strict condition for this label. You can only mark data as optional if all users, regardless of device or region, can opt out, opt in, or skip it. If any version of your app requires the data, your declaration must say required.

Here is an example scenario. A fitness app lets phone users skip the profile photo, but its tablet version demands a photo during signup. In that case, you cannot label the photo optional. Therefore, test each signup flow separately if your platforms differ. We add this check to our prerelease test list. That way, a label in the form never contradicts a hidden difference in the product.

How should you answer the encryption in transit question?

In the security practices part of the form, Google asks whether you encrypt data in transit. Google expects you to follow industry best practices for encrypting data in transit and mentions TLS and HTTPS as common examples.

Still, one detail matters a lot. You can only answer "yes" if encryption applies to all user data that your app and its SDKs collect and transmit. So even if your main API uses HTTPS, an old endpoint that sends images or logs over plain HTTP makes your answer inaccurate.

That is why we recommend these checks:

• Monitor the network traffic of your app on a test device and look for unencrypted requests.
• Ask your developer whether the network security configuration permits cleartext traffic.
• Make sure every page that opens inside a webview also uses HTTPS.

If you want the web side of this topic, our guide on SSL certificates and HTTPS security is a good starting point.

Why does the data deletion question matter so much?

The form asks whether users can request that you delete their data. The official page does not prescribe one mechanism. Instead, it says users should find the request path easily and access it without friction. Google lists an in-app feature, a contact form, or a dedicated email alias as examples.

In addition, your answer turns into information that users see on the store listing. You can select the relevant option if you offer a deletion request mechanism, or if you automatically delete or anonymize data within the period Google defines. Keeping some data for legal compliance or abuse prevention does not disqualify you.

Still, the mechanism you declare has to work. For example, if nobody reads the inbox you point users to, your declaration only exists on paper. For that reason, we suggest a simple workflow that logs every deletion request and a privacy policy that explains how you respond. Check the official page for current timelines and conditions.

How do you prepare the account deletion link?

If your app lets users create an account from within the app, Google asks for two things. We confirmed these rules on the official Play Console Help page on account deletion requirements:

1. An in-app path where users can delete their account and associated data, ideally in a visible place such as account settings.
2. A link to a web resource where users can request account and data deletion without reinstalling the app.
3. That web link entered in the matching field of the data safety form.

The web page has to work, users must find it easily, and it must reference the app or developer name that appears on Google Play. If users need extra steps first, such as canceling a subscription, explain those steps clearly. Also, if you retain some data for security, fraud prevention, or regulatory reasons, tell users plainly, for example in your privacy policy.

The rule also applies when you send users to an account creation flow outside the app. So "signup happens on our website" does not release you from this obligation.

Why must your privacy policy match the form exactly?

Under the Google Play User Data policy, every app must add a privacy policy link in the designated Play Console field. The app must also offer a link to that policy or its text inside the app. We confirmed these points on the official User Data policy page.

In addition, the policy has its own conditions. It must sit on an active, public, non-geofenced URL that nobody can edit, and Google does not accept PDFs. It must cover developer information, a privacy contact, the data types you access and collect, the parties you share with, your secure handling practices, and your retention and deletion policy.

So why does consistency matter? Because reviewers and users notice quickly when the policy and the form disagree. For example, a policy that says "we share data with advertising partners" next to a form that declares no sharing is a direct contradiction. We cover notices, consent, and permissions in our article on mobile app privacy compliance. This guide is not legal advice; prepare your policy with your legal counsel.

How do you fill out the Google Play data safety form step by step?

According to the official flow, the form lives on the App content page in Play Console. Menu names can change over time, so use the search box in Play Console if you cannot find the right section. The flow looks like this:

1. Open your app in Play Console and go to the App content page.
2. Under Data safety, select Start and read the overview.
3. In the data collection and security step, state whether you collect or share any of the required data types; if so, answer the encryption and deletion questions.
4. Next, select the data types that you collect and share.
5. For each type, enter the purposes and mark it as required or optional.
6. Read the store listing preview to see how users will see your answers.
7. Finally, submit the form or save it as a draft.

Also, don't skip the preview. The summary that users see is a plain translation of your technical answers. If a line there looks odd to you, you probably chose a wrong answer somewhere. After that, Google reviews the form as part of the app review.

What is the CSV import and export option for?

According to the official page, you can export the form to a CSV file and import answers from a CSV file on the Data safety page. Google also offers a sample CSV for offline completion. Each row holds one response, and you enter TRUE or FALSE in the response value column.

This option also helps in a few situations:

• If several of your apps share the same stack, you can start from a common template.
• If your legal or security team must approve the answers, you can send them the spreadsheet.
• If you archive a copy with every release, you can track what changed and when.

Be careful, though. An import overwrites the answers already in the form. Therefore, always export and back up the current form before you import. That way, you can restore your earlier answers if you upload the wrong file. We name each file with the release number and keep it in the project folder.

What do the optional badges mean?

The security practices part of the form also contains a few optional declarations. They can appear as extra information on the store listing, but they do not suit every app.

The first is the independent security review. According to the official page, this review is optional and the developer pays for it. A Google authorized lab runs it under the Mobile Application Security Assessment (MASA) framework against the OWASP MASVS standard. However, Google also notes that the review may not cover the accuracy and completeness of your form declarations. In other words, the badge does not remove your duty to answer correctly. For the general security picture, see our OWASP Top 10 guide.

The second is the Families policy commitment. Eligible apps that target children can show their commitment to the Play Families Policy in this section. If children are part of your audience, read every requirement of the Families policy separately.

What happens if your declaration is inaccurate?

Google states plainly that developers alone are responsible for complete and accurate declarations. It also notes that its review does not aim to verify the accuracy of every declaration. That does not mean nobody looks, though. Google can detect discrepancies and take enforcement action.

According to the FAQ on the official page, Google asks the developer of an app with an inaccurate declaration to fix it. Apps that do not become compliant face policy enforcement, and Google names blocked updates and removal from Google Play as examples.

As a result, a wrong declaration can cost you a lot. If Google removed your app, we explain the appeal process step by step in our article on Google Play policy violations and appeals. No method guarantees a successful appeal. Opening a new developer account to dodge enforcement also counts as an attempt to evade the rules and makes things worse.

We also collected other frequent store problems in our article on the most common app rejection reasons.

What could the form look like for an ordering app?

The table below is purely an example scenario; your own answers will depend on your data flows. In this scenario, users create an account, place orders, find the nearest branch by location, and the app uses an analytics SDK and a crash reporting SDK.

We left card details out of this scenario on purpose. If a payment provider handles card data on its own screen, check that provider's guidance on how to declare it. In short, the table is not a template; it shows a way of thinking.

Which checklist should you use before you submit?

We go through the table below line by line before we submit a form. If you cannot answer "yes" on a line, save the form as a draft and close the gap first.

Run this list again with every release. Above all, revisit it whenever you add an SDK or remove a feature, because the form changes with it.

When should you update the Google Play data safety form?

The official page says your answers must stay accurate and complete at all times. So the form is not a document you fill out once and forget. When the data behavior of your app changes, you update the form.

Review the form again in these situations:

• When you add a new SDK or upgrade an existing one.
• When a new feature collects a new data type, for example photo uploads or chat.
• If you start to use data for a new purpose, such as marketing.
• Also after any change to your privacy policy.

The official page also notes that a form update can take several days to reach devices. Therefore, plan the change well ahead of a release rather than right before it. On iOS, you handle the same task with privacy labels, which we explain in our guide on how to prepare App Store privacy labels.

Should you fill out the form yourself or get a team involved?

If your app has no server and no SDKs, you can fill out the form yourself with this guide. However, an app with accounts, payments, ads, or several SDKs needs someone who knows the code. Every answer in the form depends on what the code really does.

At Talha Aslan and team, we treat the data inventory, the SDK list, the privacy policy draft, and the account deletion flow as part of every app project from day one. We build your app and take it to the stores, and we prepare the data safety form as part of that process. To describe your project and request a quote, visit our mobile app development service page.

If an existing app is stuck because of the form, we can also review the situation with you. We audit your codebase, map the data flows, and align the form and privacy text with what really happens. For that, use the quote form on our mobile app development page. No service can guarantee store approval. That said, an accurate declaration lowers the chance of trouble considerably.