Firebase Analytics and the Google Play Data safety form: what to declare

Why the SDK matters for a form about your app

Google Play's Data safety section asks what *your app* collects and shares. That includes data collected by every third-party SDK you bundle. A reviewer does not see your SDK list, but users see your Data safety label, and Google compares your declaration against your app's observed behaviour and your privacy policy. An analytics SDK that quietly ships event data is still your declaration to make.

This is why the factual half of this guide is generated from the same Service Profile that produces your Apple and Google answers inside an App Passport. The categories in the table are not our opinion about Firebase — they are the mapping the product uses, versioned and dated at the bottom of this page.

What Google Analytics for Firebase implies

Two things are worth separating.

App interaction events. Analytics SDKs exist to record what happens in your app: screen views, custom events, session starts. In Play's taxonomy that lands in App activity → App interactions. This one is close to unavoidable if the SDK is installed and initialised, which is why the table marks it as likely rather than configuration-dependent.

Identifiers. Analytics needs some way to distinguish one installation from another, and depending on platform and configuration that can involve device or instance identifiers. Play groups these under Device or other IDs. The table marks this as configuration-dependent on purpose: what gets collected varies with your SDK setup, and we would rather ask you than guess.

Advertising identifier collection is a separate question again. It is configuration- and platform-dependent, so an App Passport asks you to confirm whether your Firebase Analytics setup collects or uses the advertising identifier instead of inferring it. If you do use it, that affects both your Data safety answers and your tracking disclosures.

Custom events are entirely yours. If you attach an email address, a name, or an account identifier to an event parameter or user property, you have added a data type that no SDK documentation can tell you about. Declora asks about this directly, because it is one of the most common sources of an inaccurate label.

Collected, shared, or neither

The Data safety form asks two different questions about each data type and developers routinely conflate them.

Collected means the data leaves the device. If your app sends analytics events to Firebase, that data is collected.

Shared means you transfer it to a third party. Google's Data safety guidance carves out several situations that are not "sharing", including transfers to a service provider that processes data on your behalf. Whether Firebase is acting as your service provider depends on your configuration and your agreements, so read Google's definition of sharing against your own setup rather than copying another app's answer.

You also have to answer, per data type, whether collection is required or optional for users, whether the data is processed ephemerally, whether it is encrypted in transit, and whether users can request deletion. These are about your app as a whole, not about Firebase in isolation. An analytics event that your app sends automatically, with no user choice, is required collection.

Common mistake

The most frequent error is treating the Firebase console as the source of truth for the form. The console tells you what data Firebase has; it does not tell you how Play wants that data categorised, and it says nothing about the other SDKs in your build.

The second most frequent error is an inconsistency that reviewers do catch: declaring analytics data in the Data safety form while your published privacy policy never mentions analytics — or the reverse, a privacy policy listing data types your form omits. These two artefacts are read together. Declora's Consistency Check exists for exactly this class of mismatch, comparing your Data safety answers, your Apple answers, and your generated Public Pages against the same set of confirmed App Facts.

A third mistake is answering the form once and never revisiting it. Adding an SDK, enabling a new Firebase product, or starting to attach user properties to events all change the correct answer, and Play expects your declaration to stay accurate.

Why apps get rejected

Play enforcement around Data safety is usually about *mismatch*, not about collecting data. Collecting analytics data is ordinary. Declaring that you collect nothing while your app transmits event data is a policy problem, and it is the kind of thing that surfaces as a rejection or a warning in Play Console rather than as a friendly question.

The patterns that cause trouble:

• A Data safety declaration that omits a category an installed SDK plainly collects.
• A privacy policy URL that does not resolve, or that omits data types the form declares.
• Declaring that data cannot be deleted while offering account creation, which collides with Play's account deletion requirements.
• Marking data as processed ephemerally when it is retained for analytics reporting.

None of this requires a lawyer to spot. It requires one consistent list of facts, applied to every place you answer a question about data.

How Declora handles this

An App Passport starts from your service list. Selecting Google Analytics for Firebase pulls in the Service Profile behind this page, which suggests App Facts with a confidence level and a reason, and asks the follow-up questions the profile knows are configuration-dependent. Nothing is auto-confirmed — suggestions stay suggestions until you confirm them, because only you know your production configuration.

From those confirmed App Facts, the same source generates your Google Play answers, your Apple App Privacy answers, and your Public Pages, then runs the Consistency Check across all of them. When Apple or Google guidance changes, the catalog version moves and your answers can be regenerated instead of rebuilt from memory.

FAQ

Does installing Firebase Analytics mean I must declare data collection?

If the SDK is initialised and sending events, yes — app interaction data is leaving the device, and that is collection under Play's definition. What varies is which additional categories apply, particularly identifiers, and that depends on your configuration.

Is sending analytics data to Firebase "sharing" in the Data safety form?

Not necessarily. Google's guidance excludes several transfers from the definition of sharing, including data sent to a service provider that processes it on your behalf. Check Google's definition against your own configuration and agreements before answering, and keep the answer consistent with your privacy policy.

Do I have to declare the advertising identifier?

Only if your setup actually collects or uses it. This is platform- and configuration-dependent, so it is a question we ask rather than an assumption we make. If you do use it, expect it to affect your tracking-related disclosures as well.

What about custom event parameters and user properties?

They count. Custom payloads are developer-defined, so no SDK documentation covers them. If you attach personal details or account identifiers to events, declare those data types.

Will Declora guarantee my Data safety form is accepted?

No. Declora produces consistent, sourced answers from the App Facts you confirm, and flags contradictions between your store answers and your Public Pages. It is not a law firm, does not provide legal advice, and cannot guarantee approval by Apple, Google, or any regulatory authority.