Filling in app privacy and data-safety forms

By Abdalla Kamesh · Published September 25, 2026 · 5 min read

Apple calls it App Privacy. Google calls it the Data safety section. Both are questionnaires you must complete before your app can be distributed, both appear publicly on your listing, and both are places where a rushed or vague answer produces a rejection — or, worse, a policy problem later when the declaration does not match reality.

The good news: a WooCommerce store app collects a predictable set of things, and once you can name them the forms take twenty minutes.

What the two forms are asking

They are asking three questions about every category of data:

Do you collect it?
Is it linked to the user’s identity?
Do you use it for tracking or advertising across other companies’ apps and sites?

Question 3 is the one with consequences. On iOS, declaring tracking triggers the App Tracking Transparency prompt. If you are not doing cross-company tracking, say so — and then make sure nothing in your app quietly does.

What a store app actually collects

Work through this list against your own app; most of it will apply.

Contact information. Name, email, phone, shipping address. Collected because you are shipping physical goods to a person. Linked to identity, obviously. Not used for tracking.

Purchase history. Orders, items, amounts. Same status.

Identifiers. A device or push token so notifications can be delivered, and an account identifier. Linked. Not tracking — a push token used only to notify your own customers is not cross-app tracking.

Usage data. Screens viewed, products viewed, app opens. Whether this is linked depends on your analytics setup. If it is tied to a customer account, it is linked; if it is aggregate, it may not be.

Diagnostics. Crash logs and performance data, if you collect them.

Location — usually not. A store app typically does not need device location. If you do not request it, say you do not collect it. Requesting a permission you do not need is itself a rejection risk under the data-minimization guidelines.

Financial information — usually not, in the app. This is the one worth thinking through carefully. If the payment step runs on your store’s own checkout pages with your own gateways, the card data is collected by your store and your gateway, not by the app. That is a meaningful distinction and it is why the payment step belongs on the web. Declare what your app collects; your store’s own privacy policy covers what your store collects.

The collection people forget

Nearly every rejection or later correction in this area comes from the same place: something in the app collects data on your behalf and you did not count it.

Check for:

Your analytics provider. What does it collect, and is it linked to an identity?
Your push provider. Tokens, and possibly device information.
Crash reporting. Device model, OS version, sometimes user identifiers.
Any advertising SDK. If your app builder offers ad monetization and you enabled it, you are almost certainly in “tracking” territory, and that changes your ATT answer. This is a good reason to run a store app with no ad SDK in it at all.
Anything embedded from your store, including scripts on the checkout page you hand off to.

Ask your app vendor for a written list of what their SDKs collect. StoreToNative computes the data-safety answers from what your app actually has enabled — which removes the guesswork about our side, but does not remove your responsibility to read the answers and confirm they match what you know about your store.

Practical answering rules

Over-declare rather than under-declare. Declaring a category you collect minimally is safe. Failing to declare one you do collect is a policy violation.

“Linked” means it can be tied to an identity by anyone, not just by you deliberately. An email address attached to an order is linked.

Purpose matters as much as category. Both forms ask why. “App functionality,” “analytics,” “personalization” and “advertising” are very different answers with very different consequences. Be specific.

Your privacy policy must agree with the form. A reviewer can compare them. If your policy is a template that mentions cookies and web analytics but nothing about a mobile app, update it.

Data deletion. Google requires you to state whether users can request account and data deletion, and to provide a route. Have one, and make it findable — an email address in your account screen is acceptable if it is honoured.

The account-deletion requirement

Worth its own note because it catches people. If your app lets customers create an account, both platforms expect an in-app route to request account deletion, not merely a support email buried in a policy page. Decide now what deletion means for your store — order records usually must be retained for tax purposes, so “delete my account” typically means removing personal data and anonymizing historical orders. Write that down in your policy, and make sure whoever handles the request knows the process.

The twenty-minute pass

List every SDK in your app. Ask your vendor if you cannot see it.
List what each collects, in writing.
Answer the categories above, honestly, over-declaring where you are unsure.
Set tracking to “no” if you are not doing cross-company tracking — and verify no ad SDK is enabled.
Update your privacy policy so it describes the app, not only the website.
Add and test the account-deletion route.
Read your declaration back as a customer would. Would it surprise them?

Step 7 is the real test. The declaration appears on your store listing, next to your screenshots, and a customer deciding whether to install will occasionally read it.

When something changes

Both declarations must be kept current. If you turn on a new analytics tool, add a feature that requests a new permission, or change your push provider, revisit the forms. A declaration that was true at launch and false a year later is the same problem as one that was never true.

Related reading

This is a practical guide, not legal advice. Privacy requirements vary by jurisdiction and change; check Apple’s and Google’s current documentation and, where it matters, your own counsel.