Firebase Analytics and Apple App Privacy: review analytics data

Begin with your event design

Firebase Analytics can measure product interactions, but the data sent by an analytics integration depends on your SDK settings and the events, parameters, and user properties that your team defines. Start with a production event inventory. Include automatically collected events, events you add in code, default parameters, user properties, and any consent or collection controls that change behavior.

Do not treat the Firebase product name as a complete description of your data. An event called purchase might contain only a broad event signal, or it might carry values and identifiers that your team added. A screen-view event might be harmless in one app and reveal a sensitive workflow in another. Review the actual payload and the purpose of each field.

The same exercise should cover SDK initialization and collection switches. Check whether Analytics collection is disabled until consent, whether collection is limited in certain regions, and whether the production build uses a different configuration file from development. Your App Privacy review should describe the app that users download, not the configuration that is easiest to inspect locally.

Use App Facts without turning suggestions into answers

Declora’s App Passport uses the Firebase Analytics profile to suggest App Facts for analytics purposes and product interaction data. It also marks device identifiers as possible because collection depends on platform and configuration. These suggestions organize the questions you need to answer; they do not settle the answers for you.

Open each App Fact and compare its reason with your event inventory. Confirm the facts that match your release behavior, correct the ones that do not, and leave uncertain items for investigation. The developer confirms the facts because only your team knows which events, parameters, user properties, and collection controls are active.

The Apple mapping separates product interaction from device ID review. That separation prevents a common shortcut: accepting a broad analytics answer while overlooking an identifier that changes linkage or tracking analysis. It also gives you a place to explain configuration-dependent behavior before it becomes a store-facing answer.

Decide whether data is linked to you

Apple’s questions about data linked to the user require more than asking whether Firebase has an account. Review your own identifiers and the way events are associated with a person or device. Consider user IDs, installation or app instance identifiers, account state, and any server-side join your app performs.

Custom event design is central here. Avoid sending email addresses, names, phone numbers, or other direct identifiers as event parameters unless your design and review support that use. If an event or user property contains personal details, treat it as a deliberate data-flow decision and confirm the corresponding App Fact. If you changed the event schema recently, review historical and current payloads rather than assuming the new code erased the old behavior.

Linkage can also vary by user state. A signed-in experience may connect events to an account while a signed-out experience does not. Document those branches, then use the production behavior that the store review should represent. Do not select a universal answer because one test account produced a convenient result.

Treat tracking as a separate question

Analytics is not automatically tracking under Apple’s definition. Review whether your app or an analytics-related feature uses an advertising identifier, links data with data from other companies’ apps or websites, or uses the data for a purpose that falls within Apple’s tracking concept. A product analytics event by itself does not answer that question.

The profile describes tracking potential as configuration-dependent. Check advertising identifier settings, consent state, linked advertising products, and any SDKs that participate in measurement. Keep analytics collection and tracking analysis as separate work items so a “yes” to one does not silently determine the other.

Build a review trail

Use this sequence for each App Fact:

1. Identify the source field, event, identifier, or setting in the production build.
2. Record whether collection occurs before or after the user’s consent choice.
3. Determine whether the value is linked to the user and which purpose applies.
4. Confirm whether any cross-company or cross-app use changes the tracking analysis.
5. Confirm or correct the App Fact, then review the resulting App Privacy output.

Safe Mode lets you inspect uncertain results while keeping tentative facts from being treated as settled. After the review, run Consistency Check against your privacy policy, consent screen, analytics documentation, and Public Pages. Public Pages should not describe an idealized event schema while the release build sends something different.

Avoid recurring Firebase Analytics errors

Do not review only the events your product team named in a dashboard. Automatic collection, default parameters, user properties, and remote configuration can add behavior outside that list. Do not assume that turning off one collection switch removes data sent by another analytics or advertising component.

Do not copy an answer from an Android release into an iOS submission. The catalog maps platform-specific store taxonomies, and your iOS SDK configuration may differ. Also avoid promising that a consent banner solves every disclosure issue. Consent affects collection behavior, but it does not replace an accurate review of the data flow.

Declora is not a law firm, and it cannot guarantee store approval. It helps you organize App Facts, inspect catalog-derived guidance, and compare outputs; your team must confirm the implementation and submit the final details.

FAQ

Does Firebase Analytics always collect the same data on every iOS app?

No. Automatic collection, custom events, user properties, device identifiers, consent controls, and other configuration choices can change the data path. Review the production configuration and payloads for your app instead of treating the SDK name as the answer.

Should every custom event be listed as a separate App Privacy category?

Not necessarily. Review what the event represents, what parameters it contains, how it is linked, and which purpose applies. Several events may map to one store data type, while one event with added identifiers may require a broader review.

Does analytics data count as tracking?

Not automatically. Determine whether your app links data with data from other companies’ apps or websites, uses an advertising identifier, or otherwise falls within Apple’s tracking definition. Keep that analysis separate from the question of whether analytics data is collected.

What if the answer changes by consent region?

Document the behavior in each relevant state and review the production defaults. Confirm the App Facts that describe the app’s actual collection behavior, then make sure the App Privacy details and Public Pages do not imply that every user sees the same data flow when they do not.