Provide information for Google Play's Data safety section

This video takes you through all the resources and steps required to complete the Data safety form.

"Collect" means transmitting data from your app off a user’s device. Please note the following guidelines:

• Libraries and SDKs: This includes user data transmitted off device from your app by libraries and/or SDKs used in your app, irrespective of whether data is transmitted to you or a third-party server.
• Webview: It also includes user data collected from a webview which has been opened from your app, if your app is in control of the code/behavior delivered through that webview.
  • You do not need to declare data collection from a webview in which users are navigating the open web.
• Ephemeral processing: User data transmitted off device that is processed ephemerally needs to be included in your form response, but if it meets the standard below, it will not be disclosed in your app’s Data safety section on Google Play.
  • Processing data "ephemerally" means accessing and using it while the data is only stored in memory and retained for no longer than necessary to service the specific request in real-time.
  • For example, a weather app that transmits user location off the device to fetch the current weather at the user's location but only uses location data in memory and does not store that data once the request has been fulfilled, can treat its transient use of location as ephemeral. However, using data to build advertising profiles or other user profiles cannot be treated as ephemeral and must be declared as collection or sharing for the relevant purposes.
• Pseudonymous data: User data collected pseudonymously must be disclosed. For example, data that can reasonably be re-associated with a user must be disclosed.

Not in scope for data collection

The following use cases do not need to be disclosed as collected:

• On-device access/processing: User data accessed by your app that is only processed locally on the user’s device and not sent off device does not need to be disclosed.
• End-to-end encryption: User data that is sent off device, but that is unreadable by you or anyone other than the sender and recipient as a result of end-to-end encryption does not need to be disclosed.
  • The encrypted data must not be readable by any intermediary entity, including the developer, and only sender and recipient may have necessary keys.

"Sharing" refers to transferring user data collected from your app to a third party. This includes user data transferred:

• Off-device, such as server to server transfers. For example, if you transfer user data collected from your app from your server to a third-party server.
• On-device transfer to another app. Transferring user data from your app to another app directly on the device. In this case, you must disclose data sharing in your Data safety section declarations even if your app does not transmit the data off the user’s device.
• From your app libraries and SDKs. Transferring data collected from your app off a user’s device directly to a third party via libraries and/or SDKs included in your app.
• From webview which has been opened through your app. Transferring user data to a third party via a webview which has been opened from your app, if your app is in control of code/behavior delivered through that webview.
  • You do not need to declare data sharing from a webview in which users are navigating the open web.

The following types of data transfers do not need to be disclosed as "sharing":

• Service providers. Transferring user data to a "service provider" that processes it on behalf of the developer.
  • "Service provider" means an entity that processes user data on behalf of the developer and based on the developer’s instructions.
• Legal purposes. Transferring user data for specific legal purposes, such as in response to a legal obligation or government requests.
• User-initiated action or prominent disclosure and user consent. Transferring user data to a third party based on a specific user-initiated action, where the user reasonably expects the data to be shared, or based on a prominent in-app disclosure and consent that meets the requirements described in our User Data policy.
• Anonymous data. Transferring user data that has been fully anonymized so that it can no longer be associated with an individual user.

First and third parties.

• "First party" means the primary organization responsible for processing data collected by the app, which is typically the organization publishing the app on Google Play and appearing on the store listing.
  • The first party has an obligation to make reasonably clear to users which organization is primarily responsible for processing data collected by the app.
• "Third party" means any organization other than the first party or its service providers.

You can also disclose whether each data type collected by your app is "optional" or "required." "Optional" includes the ability to opt into or opt out of data collection. For example, you can declare a data type as "optional" where a user has control over its collection and can use the app without providing it; or where a user chooses whether to manually provide that data type. If your app’s primary functionality requires the data type, you should declare that data as "required."

You can declare that your app collects certain data optionally only if all users – regardless of device or region – can either optionally provide information, opt-out, or opt-in to have the data collected.

Examples of optional data collection include:

• A social media app that asks for a user's birthday for marketing communication, but that info is not required – the user can still sign up without providing that information.
• User data that is only collected when a user signs in where users have the ability to engage with the app without being signed-in.

The Data safety section is also an opportunity for you to showcase your app’s privacy and security practices to your users. For example, you can highlight the following information:

• Encryption in transit: Is data collected or shared by your app using encryption in transit to protect the flow of user data from the end user’s device to the server.
  • Some apps are designed to let users transfer data to another site or service. For example, a messaging app may give users an option to send an SMS message through their mobile services provider, which maintains different encryption practices. These apps may declare in their Data safety section that data is transferred over a secure connection as long as they use best industry standards to safely encrypt data while it travels between a user’s device and the app’s servers.
• Deletion request mechanism: Does your app provide a way for users to request deletion of their data?

Apps that have children as a target audience must follow Google Play's Families policy requirements. If your app falls in this category and you’ve reviewed its compliance with the Families policy requirements, you can choose to display a badge on your Data safety section stating that you have "Committed to follow the Play Families Policy."

To display the badge, go to the "Security practices" section of your Data safety form and click Go to Target audience and content to opt-in

You may choose to declare in your Data safety form that your app has been independently validated against a global security standard. This is an optional review undertaken and paid for by developers. Through MASA (Mobile Application Security Assessment) developers can work directly with a Google Authorized Lab to have their apps evaluated against OWASP’s MASVS (Mobile Application Security Verification Standard). The third-party organizations performing the reviews are doing so on the developer’s behalf.

If you're interested in participating, you can contact a Google Authorized Lab directly to initiate the testing process. Once the lab has verified your app satisfies all security requirements, you can choose to display a badge on your Data safety section stating that you have completed the "Independent Security Review."

Authorized Labs have a dedicated practice area around mobile app security and provide comprehensive security testing capabilities and experience. These labs also comply with ISO 17025 or an equivalent industry-recognized standard. If you meet this criteria and are interested in becoming a lab partner, please complete and submit this form with your company details.

Important: This independent review may not be scoped to verify the accuracy and completeness of your Data safety declarations. Even if you use third-party tools to diagnose your app’s security controls, you remain solely responsible for making complete and accurate declarations in your app’s store listing on Google Play.

The Unified Payments Interface (UPI) is an instant money transfer system, developed by the National Payments Corporation of India (NPCI), a RBI-regulated entity. If you currently utilize this payments transfer system, you can choose to declare so in your Data safety form. If you are interested in participating or have questions, you can contact NCPI directly for eligibility criteria on how to have your app accredited. Apps with this accreditation may be eligible to display a badge on their Play Store listing verifying that NPCI has validated this app’s implementation of UPI. The badge will read "Offers Payments through UPI," and will not appear to users unless you indicate so by opting in within the Data safety form in Play Console. The badge is only visible to Google Play users based in India.

Developers will be asked to provide collection, sharing, and other practices for a range of user data types, as well as the purposes for which you use that data.

The CSV contains one row per response. Responses for multiple choice and single choice questions span multiple rows, matching the number of available choices. To respond to a question, enter TRUE or FALSE in the corresponding cell in the "Response value" column, or you can leave the cell blank if the question is optional or you're responding to a multiple choice question. The column "Answer requirement" indicates whether or not a response is mandatory, and can contain the following values:

• OPTIONAL: Not required — can be left blank.
• REQUIRED: Mandatory — you must provide a response value
• MULTIPLE_CHOICE: You can provide a response value of TRUE to at least one of the response choices for the corresponding question ID. You can leave other responses blank.
• SINGLE_CHOICE: You can provide a response value of TRUE to one of the response choices for the corresponding question ID. You can leave other responses blank.
• MAYBE_REQUIRED: You only required when certain conditions are met, e.g. based on the answer to a previous question

The table below provides an example for the “Name” and “Approximate location” sections of the Data safety form. It contains:

• A multiple choice question
• A required question
• An optional question

1. Open Play Console and go to the App content page (Policy > App content).
2. Under "Data safety," select Start.
3. Near the top right of the page, select Export to CSV.

Important: Answers already entered into your form will be overwritten when you import a CSV.

1. Open Play Console and go to the App content page (Policy > App content).
2. Under "Data safety," select Start.
3. Near the top right of the page, select Import to CSV.

We opened Play Console in October for Data safety form submissions and will provide a grace period until July 20, 2022, which should be ample lead time. At this point, we have no plans to grant extensions.

In short, yes. You should provide accurate information that reflects your app’s data collection and handling practices. You are accountable for the information you provide. Google Play reviews apps across all policy requirements; however we cannot make determinations on behalf of the developers as to how they handle user data. Only you possess all the information required to complete the Data safety form.

If we find that you have misrepresented the data you've provided and are in violation of the policy, we will require you to fix it. Apps that don’t become compliant are subject to policy enforcement, like blocked updates or removal from Google Play.

After you submit a new app or an update to an existing app on your Play Console, it can take some time for your app to be processed for standard publishing on Google Play. Certain apps may be subject to expanded reviews, which may result in review times of up to 7 days or longer in exceptional cases.

App updates and new submissions must comply with Google Play's Developer Program policiesPolicy. You can go to the Publishing overview page in Play Console to check if your app submission is still pending review.

If your latest update is ready, and you are still not seeing the Data safety section form on Google Play, you can check if managed publishing is turned on in Play Console. If managed publishing is turned on, your release won't be made available until you publish it. You can roll out the release from the Publishing overview page. The approved submission will then be published and available on Google Play shortly afterwards.

If you updated the Data safety section content, but are not seeing the latest on Google Play, try refreshing the app page. Note that, due to device connectivity and varying server load, it may take several days (in some cases up to 7 days) for app updates to reach all devices. We kindly request your patience while Google Play registers and delivers your app update.

It’s great that you have a good handle on your app’s data practices. The Data safety form asks for additional and different information that you may not have used previously, so we want you to expect that this requires effort for your team. The taxonomy and framework of the Data safety section on Google Play may differ materially from those used in other app stores.

Similar to a privacy policy, or app details like screenshots and descriptions, developers are responsible for the information disclosed in their Data safety section. Google Play’s User Data policy requires developers to provide accurate information. If we find that a developer has misrepresented the data they’ve provided and is in violation of the policy, we require the developer to fix it. Apps that don’t become compliant are subject to policy enforcement.

Google Play users should feel confident that their data is safe. We continuously launch new features and policies to protect user privacy and keep Google Play a trusted place for everyone. Some of Google Play’s new features and policies have enhanced user controls and transparency. Others help ensure that developers only access personal data when it’s needed for the primary use of the app. Existing Google Play Developer Program policies like these contain a number of requirements around data transparency and control. Apps that don’t comply with Google Play Developer Program policies are subject to policy enforcement.

You should update your Data safety section when there are relevant changes to the data practices of the app. Your Data safety form responses must remain accurate and complete at all times.

The Data safety section can help people make the right decision for themselves about which apps to download. It also helps developers build trust and get more engaged users who feel confident that their data will be treated responsibly. Developers have shared that they want clearer ways to communicate with their users about their data practices.

Google Play has one global Data safety form and Data safety section in the Google Play store listing per package name that is agnostic to usage, app version, region, and user age. In other words, if any of the collection, uses, or linkages are present in any version of the app presently distributed on Google Play, anywhere in the world, you must indicate such on the form. Therefore, your Data safety section describes the sum of your app’s data collection and sharing across all its versions currently distributed on Google Play. You can use the “About this app” section to share version-specific information with your users.

At this time, we reflect the global representation of your data practices per app. Your Data safety section describes the sum of your app’s data collection and sharing across all its versions currently distributed on Google Play. You can use the “About this app” section to share version-specific information with your users. The Data safety section includes a clarification for Google Play users that an app’s data collection and security practices may vary based on a number of factors such as the region.

No, the Data safety section is only presented on your app's store listing on Google Play; there is no new disclosure in the user app install process, and there is no new user consent related to this feature. Developers that collect personal and sensitive user data must implement in-app disclosures and consent where required by the existing Google Play User Data policy.

Your Data safety section describes the sum of your app’s data collection and sharing across all its versions currently distributed on Google Play. If any version of your app requires the collection of certain data, you must declare its collection as required for the Data safety section. You should not describe collection as optional if it is required for any of your app’s users. You can use the “About this app” section to share version-specific information with your users.

You do not need to declare collection or sharing unless data is actually collected and/or shared. Your app must comply with all Google Play Developer Program policies, including our policy for Permissions and APIs that Access Sensitive Information.

If you are purposefully collecting a data type during the collection of another data type, you should disclose both. For example, if you collect user photos and use them to determine users’ characteristics (such as ethnicity or race) you should also disclose the collection of ethnicity and race.

The Data safety section provides a surface for you to share if you provide a mechanism to receive data deletion requests from your users. As part of completing the Data safety form, you are required to indicate if you provide such a mechanism.

There is no prescribed mechanism, however as best practice the request mechanism should be easily discoverable and accessible by users. Common examples of mechanisms that clearly indicate a path by which users can request data deletion may include but are not limited to: in-app features, contact forms, or a dedicated email alias.

You may select the deletion request mechanism badge in Data safety form if you:

• provide users with a mechanism to request data deletion; or
• automatically initiate deletion or anonymization of collected data within 90 days of collection.

You may select the deletion request mechanism badge even if you need to retain certain data for legitimate reasons such as legal compliance or abuse prevention.

Google Play provides one global Data safety form and Data safety section in the Google Play store listing per package name that should cover data practices based on any usage, app version, region, and user age. In other words, if any of the data practices are present in any version of the app presently distributed on Google Play, anywhere in the world, you must indicate these practices on the form. Therefore, your Data safety section will describe the sum of your app’s data collection and sharing across all its versions currently distributed on Google Play.

There are a variety of potential methods to anonymize data such that it cannot be associated with an individual user. You should consult with your privacy and security experts to identify the methods applicable to your use case. As an example, this page discusses some of the data anonymization methods used by Google, such as differential privacy.

As with other data types, you should disclose your collection, use and sharing of IP addresses based on their particular usage and practices. For example, where developers use IP addresses as a means to determine location, then that data type should be declared.

As with other data types, you should disclose your collection, use and sharing of different kinds of identifiers based on your particular usage and practices. For example, the collection of an account name associated with an identifiable person should be declared as a “Personal identifier,” and the collection of a user’s Android Advertising ID should be declared as “Device or other identifiers.” As another example, an identifier related to a specific in-app event, but that does not reasonably relate to an individual device, browser or app, would not need to be disclosed as “Device or other identifiers.”

As noted above, the collection of data pseudonymously should be disclosed on your survey under the relevant data type. For example, if you collect diagnostic information with a device identifier, you should still disclose the collection of “Diagnostics” in your Data safety form.

A service provider may only process user data on your behalf. For example, an analytics provider that processes user data from your app solely on your behalf, or a cloud provider hosting user data from your app for your use, will typically qualify as “service providers.” On the other hand, if an SDK provider is building advertising profiles across multiple customers based on your app data, that would not be considered “service provider” activity for purposes of the Data safety section, and would need to be disclosed as "sharing" in your Data safety form.

It depends on the nature of your integration with the payment service. If your app uses a payment service such as PayPal, Google Pay, Google Play's billing system, or similar services to complete payment transactions, you don’t need to declare collection of the data that the payment service collects in connection with its processing of financial transactions, such as a credit card number, if the following conditions are met:

• Your app never accesses this information; and
• The payment service collects this information directly from the user, and collection is governed by that service’s terms.

You should review your integration with the payment service closely to ensure that your app’s Data safety section declares any relevant data collection and sharing that does not meet these conditions. You should also consider whether your app collects other financial information, like purchase history, and whether your app receives any relevant data from the payments service, for example for risk and anti-fraud purposes.

It depends on the particular implementation. If the user chooses to upload their data directly to their own external drive or cloud storage account (such as Google Drive, Dropbox, or similar services) and this upload is governed by the external drive or cloud storage provider's terms of service and privacy policy, and your app never collects or accesses the data in question, then your app does not need to declare the collection of this data.

You should follow best industry standards to safely encrypt your app’s data in transit. Common encryption protocols include TLS (Transport Layer Security) and HTTPS.

You should declare the collection of this data for account management, denoting (if applicable) where collection is optional for the user.

In addition, as with any data types collected by your app, you should disclose this data for the purpose(s) for which your app uses it. For example, if your app allows a user to add a birthday to their account and also uses that data to send timely push notifications, your app should also declare this purpose in addition to account management.

Account management can be used to cover general uses of account data that are not specific to the particular app. For example, if you use account information for fraud prevention, advertising, marketing, or developer communications across your services, and this use is not specific to your app, or activities in your app, declaring “account management” as the purpose of collecting this account data will be sufficient to cover those general uses in your Data safety section. However, your app must always declare all purposes for which the app itself uses the data. As a best practice, we recommend disclosing how your app handles user data for account services as part of your account-level documentation and sign-up process.

System services are pre-installed software that support core system functionality. System services can apply for an exemption from completing the Data safety form.

You can check the status of your submission on the App content page (Policy > App content) in Play Console. If your submission is compliant, you will see a green check mark in the “Data safety” section.

Note: Our policies are enforced through systems and processes that are continuously improved over time. Additionally, changes and updates to our policies can result in apps which were approved earlier to be enforced upon at a later time following initial submission due to non-compliance.

Google Play will notify developers regarding any updates. You can check our User Data policy and this Help Center article to make sure you are aware of the most up to date guidance.

If this use is ephemeral, you do not need to include it in your form response. However, you must declare any use of that user data beyond the ephemeral processing, including any purposes for which you use the user data that you log. Please review the definition of ephemeral processing in the Data collection section above.

Google gathers information for the permissions list based on the install-time permissions that an app declares in its manifest.

The Data safety section shares what data the app collects and shares with third parties.

In the What developers need to disclose in the Data safety form section, we added a new section (Unified Payments Interface Badge (UPI)).

We updated the Which developers need to complete the Data safety form in Play Console? section to provide updated information regarding internal testing and Data safety section requirements. We also removed a passage of text relating to this from the August 24, 2022 change log entry, as that information is no longer applicable and we do not want to confuse developers seeking information about this issue.

We have edited the article throughout to remove references to specific dates; these references were initially included (and periodically updated) before, during, and after the launch of the Data safety section in Play Console to help developers understand what the requirements were at each point in time. As the Data safety section is now live across Google Play, we have removed the original timeline and references to specific dates.

We added additional information to the data type "App interactions" (this now includes "screenshots taken").

We updated the Which developers need to complete the Data safety form in Play Console? section to reflect that, effective October 24th, 2022, tracks that are active on internal testing tracks are exempt from inclusion in the data safety section. Apps that are exclusively active on this track do not need to complete the declaration.

We updated the Timeline information details in the "Getting your information ready" section to explain that non-compliant new app submissions and app updates will receive warnings that submissions and app updates will be rejected in Play Console if there are unresolved issues with the form. We also updated this section with details of what will happen after this warning period ends on August 22, 2022.

In the What developers need to disclose in the Data safety form section, we made the following changes in the Independent security review (now available to all apps) subsection:

• We changed the title from "Independent security review (beta starting March 2022, with general availability coming soon) " to "Independent security review (now available to all developers)," as this feature is now available to all apps.
• We updated the subsection to include information for developers who are interested in participating in an independent security review.

We made the following changes to the Frequently asked questions section:

• We updated the answer to the question, "Am I required to provide a deletion mechanism? Must it be for any and all user data?"
• Directly below this question, we also added three new questions and answers that provide more detailed information about data deletion mechanisms and the Data safety form.
• We added one new question about the difference between the permissions list and an app's Data safety section. We removed a question about apps that target old versions of Android.

In the Overview section, we added a line encouraging developers to check Google Play SDK Index to see if their provider has provided a link to their guidance. You can read the Make informed choices with Google Play SDK Index Help Center article to learn more.

In the Getting your information ready section, we added a recommendation to watch the Google Play PolicyBytes Data safety form walkthrough video, which takes you through all the resources and steps required to complete the Data safety form.

In the Overview section, we added a line encouraging certain developers to refer to their SDK providers’ published data safety information for details, like Firebase and AdMob.

We updated the Timeline information details in the "Getting your information ready" section with a reference to the message users would see on Google Play in the July 2022 entry (previously, this read "No data available," which has been updated to "No info available")

In the FAQs section, we made the following changes:

• We added a new question and answer about System services.
• We added a new question and answer about troubleshooting options if you can't see your latest Data safety updates on Google Play.
• We updated existing answers relating to how long it takes for Data safety updates to be shown on Google Play and account management.

On April 8, 2022, we corrected the name of the data type "Photos and videos" (this was previously listed as "Photos or videos").

On February 24, 2022, we made a number of changes to this article, which are described below.

Timeline information changes

We updated the Timeline information details in the "Getting your information ready" section as follows:

• Previously, we said that from February 2022, the Data safety section will be available on Google Play to all users. This date has been updated to late April, 2022.
• Previously, we said that from April 2022, new app submissions and app updates will be rejected in Play Console if there are unresolved issues with the form. This date has been updated to July 20, 2022.
• Previously, we said that from April 2022, non-compliant apps may face additional enforcement actions in the future. This date has been updated to after July 20, 2022.

We updated other references to dates in the article to be consistent with the revised dates above.

Clarifications regarding what developers need to disclose across data types

In the "What developers need to disclose in the Data safety form" section, we made the following changes in the "What developers need to disclose across data types" subsection:

• We added instructions to explain how that developers with apps that are committed to follow the Families Policy can to opt-in to display the Families badge beginning March 1, 2022.  
• In Other app and data disclosures, "Deletion mechanism" was renamed "Deletion request mechanism."
• We also updated the Independent security review section with more detailed information about this feature.

Data types and purposes updates

We made minor naming changes to our data types:

• The "Personal identifiers" data type was renamed "User IDs."
• The "Credit card, debit card, or bank account number" data type was renamed "User payment info."
• The "Credit info" data type was renamed "Credit score."
• We added the example of user salary or debts to the "Other financial info" data type.
• The "Health information" data type was renamed "Health info."
• The "Fitness information" data type was renamed "Fitness info."
• The "SMS or MMS messages" data type was renamed "SMS or MMS."
• The "Page views and taps in app" data type was renamed "App interactions," and its description was updated.
• The descriptions of the "Other user-generated content" and "Other actions" data types were updated.
• The "Other personal info" data type was renamed "Other info."
• The "Device or other identifiers" category was renamed "Device or other IDs."

We made clarifications to our data purposes:

• The “Developer communications” example was updated.
• The "Advertising or marketing" example was updated.
• The "Account management" example was updated.

Other changes

In the Overview section, we added additional images to show what users will see if your app doesn't share any user data.

We added new FAQs including topics relating to account management, user-initiated actions, use of payments platforms, and encryption.

We updated the definition for ephemeral processing in the Data collection section and added a new FAQ regarding this topic.

On December 14, 2021, we updated the data type that was originally named "Sexual orientation and gender identity."  This data type is now named "Sexual orientation" and refers to only sexual orientation.

We also updated the "Other personal info" data type to include gender identity as an example of other personal information.