Getting started
How to Use Firebase Analytics DebugView
Updated 2026-09-043 min read
Short answer
Put one device into debug mode, open DebugView, and use the app. Events appear within seconds. If they do not, the problem is in your SDK setup rather than in reporting.
Every other Analytics screen makes you wait or guess. DebugView does neither: it shows the events from a single device you have marked, as they arrive, in order. When you want a yes-or-no answer to "is my app sending anything at all", this is the screen that gives it.
What DebugView is for
DebugView is a development tool, not a reporting one. It exists to answer three questions quickly: is the SDK sending, is it sending the event names you expect, and are the parameters attached correctly. It is not a place to read user numbers.
| Screen | Scope | Use it to |
|---|---|---|
| DebugView | One device you marked | Verify setup and event shape |
| Realtime | All users, recent window | See whether anyone is active now |
| Standard reports | All users, processed | Read trends over days and weeks |
Turning on debug mode
A device does not appear in DebugView by default. You mark it as a debug device, and the exact method depends on the platform you are building for. Firebase publishes the current instructions for each; the important part is understanding what marking does rather than memorising the flag.
Mark the device
Follow the platform instructions so your test device reports itself as being in debug mode.
Open DebugView
In the Firebase console, under Analytics. It will list debug devices it has seen recently.
Select your device
If more than one is listed, pick yours. An empty list means no device is currently reporting as a debug device.
Use the app deliberately
Move between screens and trigger the specific event you are testing. Watch the stream fill.
Tip: Test one thing at a time. Tapping through five screens at once produces a stream you cannot read; performing one action and watching what arrives tells you exactly which action produced which event.
Reading what you see
Events arrive with their names and parameters. Three things are worth checking beyond the mere presence of an entry.
- The event name matches what you intended to send, exactly — names are case sensitive and typos ship silently
- Automatically collected events appear alongside yours, which confirms the SDK is fully wired rather than partially
- Parameters carry the values you expect, not empty strings or placeholders left from development
Careful: Debug traffic is separated from ordinary reporting so your testing does not distort your numbers. That separation is the point, but it also means a device left in debug mode is missing from the reports you actually read. Turn it off when you are done.
What DebugView cannot tell you
It confirms events left the device and were accepted. It says nothing about how those events will look once processed into reports — a working DebugView and an empty report a day later usually means processing delay, not a second bug.
How this fits with Appnaly
Appnaly reads processed Google Analytics data, which means DebugView sits upstream of it entirely. If DebugView is empty, nothing downstream can show anything, and there is no configuration inside Appnaly that would change that. Conversely, once DebugView shows your events, you know the pipeline starts correctly and any remaining emptiness is about linking, permissions, or processing time.
That is why it is the first thing worth checking when an app looks silent: it is the only screen that separates "the app is not sending" from every other possible cause.
Setting Firebase up for the first time? The setup guide walks through what has to be in place before any of these numbers appear.
Firebase Analytics setup guide