Cloud Firestore and Google Play account deletion: plan data removal

Define what an account owns

Cloud Firestore is a document database, not a fixed account schema. Your app decides whether documents contain a user ID, profile fields, posts, notes, uploads, preferences, purchase-related records, or other content. Begin with the production data model and list every collection, subcollection, cache, export, and queue that can contain account-linked information.

Trace ownership through document paths and security rules. A user document may be easy to find while nested comments, shared records, or activity entries use a different key. Check whether a document is owned by one user, shared with a group, or needed by another account. Deletion needs a deliberate result for each case; a broad query that misses a subcollection can leave the user with an incomplete outcome.

Also identify the account system that triggers the request. Cloud Firestore does not automatically define sign-in or account deletion. Your app may use Firebase Authentication, another identity provider, or a custom backend. Connect the account identifier used by that system to the Firestore records you intend to remove or handle.

Review the App Facts without guessing

The Cloud Firestore profile suggests App Facts for app functionality and flags user IDs as possible because documents are developer-defined. It also asks you to confirm user-generated content and personal details such as email, name, or phone. Treat these as review prompts, not final answers.

The developer confirms each App Fact after inspecting the fields actually written in production. If your app stores posts or uploads, review user-generated content. If documents include contact details, confirm those fields and their purpose. If Firestore stores only an internal key, do not describe the database as holding every possible personal detail merely because the service could store it.

Use the App Passport to connect each suggested fact to a collection, field, or code path. Keep the evidence current when your schema changes. This is especially important for account deletion because a new profile field can affect both the store review and the deletion workflow.

Design a complete deletion request

Put an account-deletion entry point where an authenticated user can find it in the app. Explain what will happen before the final confirmation, including whether the request is immediate or processed asynchronously. Make the result understandable if some shared records are retained, anonymized, or transferred to another owner under your product design.

When the request reaches your backend, verify that it is authorized for the correct account. Avoid accepting an arbitrary user ID from the client as the deletion target. Use server-side rules and an authenticated request, and handle reauthentication or recent-login requirements in a way that gives the user a clear next step.

Design for retries and partial failure. A deletion job may remove one collection and fail before another. Give the job an idempotent state, record what remains to be processed, and prevent a retry from damaging another user's shared data. Test network interruption, duplicate requests, expired credentials, and a user who signs in again while the request is pending.

Review related systems too. Firestore deletion may not remove identity records, files in Cloud Storage, analytics identifiers, subscriptions, support tickets, notification tokens, or backups. Your explanation should match the actual boundaries of your process. Do not promise instant removal if the workflow is queued or if a narrow retention step applies.

Keep Public Pages reachable

When Google Play requires a web destination for account-deletion requests, publish a stable Public Pages URL outside the installed app. Explain who can use it, what information is needed to locate an account, how you verify the request, what happens to Firestore data, and how the user can learn about status or completion.

Test the page signed out, on a phone, and without the app installed. Confirm that instructions do not depend on an authenticated session that the user cannot access after deleting the account. If the page submits a request into a queue, show the expected next step and avoid exposing document IDs, tokens, or other sensitive details.

Keep the Public Pages wording aligned with the in-app flow and the backend. If the app says deletion is immediate but the page says it can take time, resolve the difference before release. If the page covers only the Firebase Authentication record while Firestore data remains, make the scope explicit and revisit whether the user experience meets your intended policy requirements.

Use Safe Mode and Consistency Check

Safe Mode is useful while you are still confirming collection ownership, shared documents, personal fields, and deletion jobs. It prevents an unverified catalog suggestion from looking like a completed decision. Move to final confirmation only after you have tested the release build and the backend workflow.

Run Consistency Check after changing your schema, account provider, deletion endpoint, or Public Pages. Compare the App Facts with Firestore rules, collection paths, queue workers, privacy copy, support instructions, and the store submission. Check old documents and migration code, not only the newest schema.

Declora is not a law firm, and it cannot guarantee store approval. It helps organize App Facts, Public Pages, Safe Mode review, and consistency signals, but you remain responsible for confirming your implementation and submitting accurate information.

Common mistakes

Deleting a top-level user document while leaving subcollections is a frequent failure mode. Another is removing Firestore data while retaining the identity record or uploaded files. Teams also forget shared documents, offline caches, scheduled jobs, exports, and records written by an older app version.

Avoid using a support email as the only deletion mechanism when your product needs a self-service path. Avoid an endpoint that trusts a client-provided account ID. Finally, do not copy a deletion promise into the page until you have tested success, retry, failure, and delayed-processing states.

FAQ

Does Cloud Firestore delete an account automatically?

No. Firestore stores documents; your app and backend decide how those documents relate to an account and how they are removed or handled. Connect the deletion request to the identity system and test every relevant collection and subcollection.

What if one Firestore document is shared by several users?

Define the ownership result before deleting it. You may need to remove only the requesting user's relationship, anonymize a contribution, or retain a shared record for another owner. Make the behavior match the user-facing explanation and your actual implementation.

Do I need a Public Pages URL?

That depends on the applicable Google Play account-deletion requirements and your account experience. When a web destination is required, make it stable, reachable without the installed app, and clear about how a request covers Firestore and related data.

How can I test the flow before submission?

Use a release-like build and test authenticated, expired-session, duplicate-request, partial-failure, shared-data, and retry cases. Verify collection paths, backend jobs, identity records, Public Pages, App Facts, and store copy, then run Consistency Check.