The Data safety section produces the card on your listing that says what the app collects. Google verifies it against the app's behaviour, and mismatches are enforced after launch as well as at review. For a website-based app the trap is conceptual: the form asks about "the app", and the honest answer is everything the website and its integrations do, because that is what runs inside the app.
The structure of the form
- Does your app collect or share any of the required user data types? For any site with analytics, the answer is yes.
- Is all collected data encrypted in transit? Yes if your site is fully HTTPS — which it must be.
- Do you provide a way for users to request deletion? Yes, via your privacy policy contact or an account-deletion page (see below).
- Data types: tick each category collected or shared.
- Per type: collected, shared, or both; ephemeral or not; required or optional; the purposes.
"Collected" means transmitted off the device — to you or to a third party on your behalf. "Shared" means transferred to a third party for their purposes (an ad network) rather than as your processor (your analytics vendor). Most website integrations are collected; ad networks are shared.
Mapping common website integrations
| Your site has | Data type(s) | Collected / shared | Purpose |
|---|---|---|---|
| Google Analytics, Plausible, Matomo, platform analytics (Shopify, Wix, Squarespace, Jetpack) | App activity (page views, in-app actions); Device or other IDs | Collected | Analytics |
| OneSignal push (enabled in the builder) | Device or other IDs | Collected | App functionality, Developer communications |
| Google AdSense on the pages, or AdMob in the app | Device or other IDs; App activity; approximate Location (if personalised) | Collected and shared | Advertising or marketing |
| Login / accounts | Personal info: Name, Email address; Other user IDs | Collected | Account management, App functionality |
| Checkout (WooCommerce, Shopify, etc.) | Personal info: Name, Email, Phone, Address; Financial info: Purchase history; Payment info (processed by gateway) | Collected; payment info shared with the processor | App functionality |
| Contact or newsletter form | Personal info: Name, Email; Messages: Other in-app messages | Collected (shared if it feeds Mailchimp etc.) | App functionality, Developer communications |
| Comments | Personal info: Name, Email; Messages | Collected | App functionality |
| Live chat (Tawk, Intercom) | Personal info: Name, Email; Messages | Collected, shared with the chat vendor | App functionality |
| Embedded maps | Approximate location (if the map requests it) | Collected | App functionality |
| Social pixels (Meta, TikTok) | Device IDs; App activity | Shared | Advertising or marketing |
If your site has none of these — a static HTML site with no analytics, no forms, no ads — you may honestly answer "no data collected". Very few sites qualify.
The questions that trip people
"Is this data collected ephemerally?"
Ephemeral means processed in memory and never stored, even briefly, by you or your processors. Analytics is not ephemeral. Push tokens are not. Leave it unticked unless you are certain.
"Is this data required or optional?"
Optional means the user can decline and still use the app. Analytics via cookie consent, push permission, and marketing pixels behind a consent banner are optional. Checkout details are required for purchasing.
Encryption in transit
Answer yes only if every request the app can make is HTTPS. One http:// image on a page technically breaks the claim; fix the site.
Deletion requests
Google requires a mechanism. For most website apps it is "email us at … and we will delete your data", stated in the privacy policy. If your app creates accounts, Google's account deletion requirement (in force since 2024) goes further: you must offer account deletion inside the app and via a web link you enter in the form — a page on your site where users can request deletion without installing the app. For a WebView app, an account settings page with a "Delete account" button on your website satisfies both if it is reachable in the app.
Consistency checks Google runs
- Declared data vs observed network traffic during review and in periodic scans. Undeclared analytics is the classic finding.
- Data safety vs privacy policy. If the policy mentions Google Analytics and the form says no data collected, expect a rejection.
- Data safety vs listing text. "Get notified" in the description with no device identifier declared is inconsistent.
- Permissions in the manifest vs declared data. The builder's template requests only what enabled features need; don't add any.
Keeping it current
Adding a pixel, a chat widget or a newsletter form to your website changes the app's data collection without any app update. Review the form whenever you add an integration to the site, and once a year alongside the target API rebuild. Changes to Data safety are published to the listing without a new bundle.
Fill the form from the table above, then make sure your privacy policy says the same things in sentences. Reviewers read both.