Separate accepted push requests from displayed and opened messages

Give each event its own name

Firebase distinguishes sends, Android receipt, eligible Android notification impressions and background-notification opens in its console reporting. Sends can represent queueing or transfer to another service rather than device display. Coverage differs by metric and platform, and many statistics may be delayed by up to 24 hours. Those definitions were checked on 7 November 2026.

Write a reporting dictionary before calculating rates. For each stage, identify the producing system, the event it actually observes and the population it covers. Keep provider acceptance separate from app receipt, display, open and any later business outcome. A message may be accepted without being shown, and an open does not prove that its full wording was read. Do not rename technical events to more persuasive audience claims.

Keep denominators within comparable populations

Choose the denominator for each question explicitly. A display rate among a covered Android notification population is not the same as display divided by all campaign requests across Android, Apple and web. Mixing them can manufacture a gap that is really an instrumentation difference. Record exclusions and unavailable stages instead of filling missing observations with zero.

Firebase's Data API reports aggregated Android transport information; its accepted count excludes devices with relevant usage and diagnostic collection disabled, and reported outcome percentages need not account for every case. Use it to investigate broad transport patterns, not to certify every recipient's experience. Do not combine its aggregate count with a differently scoped console open count simply because both reports share a campaign label. First establish that the populations, dates and semantics align.

Troubleshoot the first unexplained transition

When a campaign looks weak, find the earliest transition for which evidence is missing or unexpectedly different. A request-validation error belongs to sender acceptance. A visible notification with an incorrect tap destination belongs later. A low open count alone does not show that delivery failed. Use controlled test observations to distinguish these paths before changing creative or send volume.

Compare mature reporting windows rather than a fresh send with yesterday's completed data. Record when each extract was taken, its date range and timezone, plus any known collection or SDK constraints. If enabling additional measurement would change data collection, route that decision through the appropriate privacy and product owners; do not turn instrumentation on merely to improve a dashboard. An honest unknown is more useful than unauthorized measurement or invented certainty.

Report a bounded conclusion and next check

Write conclusions in the language of the observed stage. For example, requests were accepted, while display evidence is available only for the stated Android subset. Separate that technical finding from the editorial hypothesis that the message may have been uninteresting. The report should identify what evidence would distinguish competing explanations, such as a controlled display test or a destination-path check.

Use synthetic records when demonstrating the reporting workflow. Preserve only the identifiers necessary to join authorized operational records, and avoid exposing registration identifiers in a public worksheet. Do not add stage counts as if they were separate people, and do not infer a person count from installation-level events without a justified method. The deliverable is a defensible account of what the systems observed, including what they did not observe.

Make the reasoning concrete.

A fictional ticket app reports a large number of accepted campaign requests but a smaller Android impression count. Its first draft labels the difference as failed delivery across the entire mixed-platform audience.

The team compares mature, matching subsets and tests the first unexplained transition. It does not call an accepted request a read notification or classify missing coverage as a failure.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Stage

   What exact event does this metric observe?

2. Population

   Which platform, payload and implementation are covered?

3. Denominator

   Does the comparison use the same eligible population?

4. Timing

   When was the data extracted and how mature is it?

5. Conclusion

   What can this evidence establish, and what remains unknown?

Watch for the wrong conclusion.

• Calling provider acceptance end-user delivery.
• Mixing platform-specific numerators with all-platform denominators.
• Treating missing measurements as zero outcomes.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.

• Firebase: Understanding message delivery →Primary platform documentation · Supports: Supports narrowly summarized metric stages, platform coverage, delays and aggregate Data API limitations; reporting and investigation framework is editorial.