The data safety form and privacy labels

What does the form ask?

Which user data your app collects, whether that data is shared with third parties, whether it is encrypted in transit, and whether the user can request deletion. The answers are shown to users in the “Data safety” section of the store page.

The critical point is scope: the form asks about the whole app, not the code you wrote. If the analytics, crash reporting, advertising and authentication libraries you added also collect data, that data is part of your declaration. This is the most common reason for rejection.

What is the difference between “collection” and “sharing”?

Collection is data leaving the user's device for your server or someone else's. Sharing is data transferred to a third party. An app can collect and never share; but if it uses a third-party library it is probably doing both.

A common mistake is treating on-device processing as “not collected”. The test is not where processing happens but whether the data leaves the device. Even in a flow processed on device where only the result is sent, a declaration is required if that result can be linked to the user.

The account deletion requirement

If user accounts can be created in your app, two things are required: a path inside the app leading to deletion of the account and its associated data, and a web link the user can reach without installing the app. The second is what most teams miss; during review the link is opened and checked from outside the app.

On a deletion request, the user data associated with the account is expected to be deleted. Limited exceptions exist for security, fraud prevention and legal retention; but “we deactivate the account” is not a deletion implementation, and declaring it as one creates an inconsistency.

What does an inaccurate declaration cost?

Inconsistent or inaccurate answers can lead to a rejected release and, on repetition, to the app being removed. The risk here is not technical but institutional: the form is a declaration, and a declaration is expected to match the app's behaviour. Forgetting a library is not intent, but it arrives at the same door.

In Türkiye these declarations have a data-protection counterpart: the disclosure obligation requires telling the user which data is processed for which purpose, independently of the store form. The two texts have to agree — data declared in one and absent from the other is a problem in either direction.

How to fill the form correctly, once

Start from an inventory. List every request the app sends: which endpoint, which data, which library, which purpose. The reliable way to produce that list is measurement rather than recall — run the app behind a proxy and watch the traffic.

Once the inventory exists, both stores' forms can be filled from it and the privacy policy written from the same source. Keeping the inventory current alongside release notes is the maintenance step most often skipped: when a new library is added, the declaration has to change too.