Why Your Firebase Numbers Look Wrong

Firebase Analytics is a batched, aggregated reporting system, not a queryable database — and almost every complaint that "the numbers are wrong" dissolves once you hold that distinction. Events are collected on the device, sent in batches, processed on a schedule, and then presented through reports that have row limits and retention windows applied to them.

A database answers the question you asked, now, against every row. A reporting system answers an approximation of your question, later, against whatever it has retained and can fit in a table. Both are useful. Confusing one for the other produces a specific and predictable set of complaints:

• "I fired the event and it isn't there" — a timing question
• "My comparison only goes back two months" — a retention question
• "Half my values are in a row called (other)" — a cardinality question
• "Firebase says 8,400 installs and AppsFlyer says 6,900" — a definitional question

Not one of those is a bug. Each has a documented cause, and the fixes are entirely different — which is why "our analytics is broken" is an unhelpful ticket. In our portfolio, the teams that trust their data are not the ones with more sophisticated tooling. They are the ones who know which of these four things they are looking at.

Because standard reports are built on a processing schedule rather than in real time, and the only place designed to confirm an event fired is DebugView. Waiting and refreshing the dashboard is the wrong tool for the question you are asking.

Firebase's own documentation on logging events is candid about this: the dashboard updates periodically throughout the day, and for immediate verification it directs you to debug output rather than to reports. DebugView is the tool built for that job. That is the whole answer to "is my event working" — you should never be answering it from a standard report.

Two consequences follow. First, an instrumentation bug found by staring at a dashboard has usually already cost you days of collection — verify in DebugView before the release ships, not after. Second, a same-day number is never final, so a "yesterday versus today" comparison read at nine in the morning is comparing a complete day against a partial one.

There is one hard figure worth knowing if you export to BigQuery: per Firebase's BigQuery export documentation, Firebase updates the daily event tables with events for a given date for up to three days after that date. Late-arriving data is a documented behaviour, not a glitch, and any pipeline that reads a day's table the morning after will systematically undercount. Build a three-day settling window into anything automated.

Every exploration you might want to run against last year's data, because event data outside the retention window is deleted on a monthly basis and no setting change brings it back. This is the most consequential default in Firebase Analytics and by far the least discussed.

The options, per Google Analytics' data retention documentation, are two months or fourteen months for user-level data, and two, fourteen, twenty-six, thirty-eight or fifty months for event-level data — with the longer event-level options available only on 360 properties.

Now the part that is widely misreported, including in guidance we reviewed while researching this article. Increasing the retention period is applied to data you have already collected. Google's wording is explicit: when you increase the retention period it is applied to data you have already collected. So raising it is not purely forward-looking.

Two further details worth knowing. Reducing the retention period causes affected data to be deleted during the next monthly process, so a reduction is not instant but is equally permanent. And there is a short grace period after a change during which it can be reverted without data loss — which matters if someone lowers the setting by accident.

The practical consequence for a growth team is about the questions you will be able to ask later. Year-on-year seasonality, the retention curve of a cohort acquired nine months ago, whether last Diwali's campaign produced users who are still active — none of these can be answered from data that no longer exists. This is also the strongest single argument for exporting to BigQuery early, which we come back to below.

It is what a report shows when your data has more distinct values than the table can hold, and it is almost always caused by a parameter someone instrumented with an identifier in it. Once values fall into "(other)" they cannot be separated back out in that report.

The mechanism, per Google's documentation on high-cardinality dimensions, is straightforward: when a report exceeds its row limit, the rows are sorted from most to least common and the remainder are grouped together under "(other)". You keep the head of the distribution and lose the tail.

On what counts as high cardinality, the guidance is that any dimension with more than 500 values should be considered high-cardinality, because it significantly increases the cardinality of every table storing that dimension. Note the framing — Google states that the 500 figure is guidance rather than a hard limit, and that the actual limits vary by property type, by report and by how complex the query is. Multi-dimensional reports with filters are the most likely to trigger it.

In practice, the culprit is nearly always one of a short list:

• An identifier used as a parameter — order id, user id, session id, transaction reference. Every value is unique by definition, so cardinality equals your event volume.
• A free-text field — a search query, a note, a product title. Unbounded by design.
• A timestamp or a price sent as a raw value rather than bucketed into ranges.
• A URL or deep link with query parameters, where every variation counts as a distinct value.

This is the strongest practical argument for defining an event schema before instrumenting rather than after. Our guide to building funnels that answer product questions covers the taxonomy side, and the cardinality question is the one most often skipped when a plan is written by someone who has not hit "(other)" before.

Because all three are counting different events over different populations with different attribution rules, and there is no configuration in which they converge. Chasing agreement between them is one of the most reliable ways to waste an engineering month.

What each is actually measuring:

The single largest and most misunderstood gap is between an install and a first open. A download that is never opened is an install to the store and nothing at all to Firebase. On Android that gap is real and material, and it widens where devices are constrained or connectivity is intermittent — which is to say, exactly where a large part of an Indian install base sits.

Attribution adds a second layer of legitimate divergence. Different windows, different treatment of view-through, and different handling of platform privacy frameworks all produce different totals from the same underlying reality. Our comparison of the major MMPs covers where those rules differ, and the attribution guide covers why the totals cannot reconcile by design.

Pick one source per question, write down which, and never switch between them to tell a better story. The specific choice matters far less than the consistency, but there is a defensible default for each type of question.

1. Installs and store performance — Play Console and App Store Connect. These are the platforms' own numbers. When an investor or a partner checks, this is what they will see, and defending a different figure is a conversation you do not want.
2. Paid channel performance — your MMP. It is the only one applying consistent attribution rules across channels, which is what makes channels comparable. Use it to decide where budget goes.
3. Product behaviour, activation and funnels — Firebase. It is measuring what people did inside the app, which neither of the others sees at all.
4. Revenue — the stores and your billing system, never an analytics SDK. Client-reported purchase events are a product signal, not a financial one. Finance numbers come from the source of truth for money.

Then state the source on the slide. "Installs: Play Console + App Store Connect" in small type under the number removes an entire category of argument, and it stops the quiet drift where whichever tool shows the better figure becomes that month's source.

Across the 300+ apps we have managed since 2013, mixed sourcing in a single report is one of the most common causes of a board losing confidence in a growth team — not because any individual number was wrong, but because the set could not be reconciled when someone asked. A consistent, slightly conservative number defended calmly beats a flattering one that changes source between quarters.

When the question is about individual rows, arbitrary joins, or a period longer than your retention window — at which point the answer is BigQuery, not a better report. Recognising this early saves a great deal of time spent fighting the interface.

The console cannot help you when:

• The question needs row-level detail. "Which users did X then Y within ten minutes" is a query, not a report.
• The dimension is high cardinality. Anything that lands in "(other)" in the console is fully available in the export.
• You need to join to your own data — subscription state from your backend, support tickets, cost data from ad platforms.
• The period predates your retention window, assuming the export was running at the time.
• You need a custom attribution or cohort definition that the built-in reports do not express.

The strategic argument for turning the export on early is that it is the only durable copy. Retention settings govern what the console keeps; an export accumulates independently. A team that enabled BigQuery in month two can answer questions in year two that a team relying on console retention simply cannot, regardless of how much they are prepared to pay later.

Remember the three-day settling behaviour when you build on the export: daily tables receive late events for up to three days after the event date. Any scheduled query that treats yesterday's table as final will undercount, consistently and invisibly.

In under an hour, by checking six things in order — and the first two are settings rather than code, because those are the ones that are silently costing you data right now.

1. Data retention setting. If it is at the short default, change it. Every month at the default destroys another month of history permanently.
2. BigQuery export. On or off, and if on, since when. That date is the real start of your usable history.
3. The event list, read as a stranger would. Can you tell what each event means from its name alone? Are there near-duplicates from two different implementations — signup_complete and sign_up_completed — which is the classic signature of two developers instrumenting independently?
4. Any report showing "(other)". Find the parameter responsible. It is polluting history for as long as it stays in the build.
5. Which events are marked as key events. If everything is a conversion, nothing is. This is usually where you learn what the previous team actually cared about.
6. DebugView against the current build, walking the core journey. Compare what fires against what you expected. This is the only step that tells you whether the instrumentation still matches the product.

Step six regularly produces the biggest surprise, because instrumentation decays. A screen gets rebuilt and its event is not reimplemented. A parameter is renamed on one platform only. A funnel that has looked flat for months turns out to be missing its middle step entirely, and the drop-off everyone has been trying to fix is a measurement artefact.

Write the six answers down. It takes ten minutes and it is the document you will want the next time someone asks why two numbers disagree.

The ones that destroy data rather than misrepresent it — because a bad report can be rebuilt and deleted history cannot. Ranked by how permanent the damage is:

• Leaving retention at the short default. Irreversible. Every month costs a month, and no later change recovers what has been deleted.
• Not enabling the BigQuery export. Irreversible for the period it was off. The export does not backfill.
• Putting an identifier in an event parameter. Permanent for the affected history. You can fix the build; the polluted reports stay polluted.
• Inconsistent event naming across platforms. Fixable going forward, but the historical series is split and every cross-platform comparison before the fix stays unreliable.
• Marking everything as a key event. Fixable, and worth fixing, but it degrades every report while it persists.
• Reporting from whichever tool flatters the number. Fixable in a day, and the most damaging to trust while it continues.

The pattern is that the expensive mistakes are all decisions made in the first fortnight of a project by whoever set up the SDK, usually without knowing they were decisions at all. Retention and export are two toggles that nobody discusses in a kickoff and that determine what questions the business can answer two years later.

The idea worth carrying out of this article is that Firebase is not lying to you and neither is your MMP. They are different instruments pointed at different things, reporting on different schedules, through interfaces with limits that are documented but rarely read. Once you know which instrument answers which question, the numbers stop being contradictory and start being useful. If you would rather have your setup audited against these six checks than work through it yourself, send us your event list and we will start with the retention setting.