A campaign report shows installs, Play Console shows acquisitions, and Firebase shows fewer first opens. Before assigning the gap to poor traffic or a broken app, establish what each row actually counts. A button click, an installation and an observed launch are different events. Even two reports labeled “first opens” can have different populations.
Google Play installs and Firebase firstopen events are not interchangeable. Installation precedes use; Firebase records firstopen when an app is first launched after installation or reinstallation. Play Console also has its own first-open metrics, distinct from the SDK event. Compare definitions, counting units, collection coverage and reporting periods before interpreting a gap as abandoned installs or changing acquisition spend. Google Analytics event definitions.
This guide is for Android growth teams deciding whether a discrepancy belongs with media, product, engineering or reporting. It provides an investigation sequence and a worked economic example. It does not diagnose an account from its totals or recommend a universal install-to-open benchmark.
Google Play installs vs. first opens: which report are you comparing?
Start by naming the product and metric, rather than writing “installs” above a combined spreadsheet column.
Observation What must be identified What it cannot establish alone --- --- --- Store listing Install click The selected listing report and its click definition A completed installation or launch Play acquisition or install metric User, device or event unit; new/returning scope; acquisition surface Product activation or paid-campaign credit Play first opens Exact Play report, unit and inclusion rules Equality with Firebase collection Firebase firstopen Android stream, SDK collection and installation/reinstallation scope A unique new customer or completed onboarding Google Ads app conversion Conversion action, source, attribution and campaign usage All-store acquisition or incremental growth
Google's Play Statistics definitions distinguish install events, device acquisitions, users and first opens. An event count is not automatically a unique-person count. A user with multiple devices makes that distinction commercially relevant even when every report is functioning correctly.
The table is a comparison checklist, not a claim that these observations form one joinable funnel. If the report cannot establish membership in the same population, its totals cannot establish how many particular people moved between stages.
An Install button click is not necessarily an acquisition
Check the current Play report before reusing an old dashboard definition. Google's store listing performance documentation now describes listing performance through unique Install, Open and Pre-register clicks. It places completed-acquisition data in other views, including Grow users, Statistics and downloadable reports.
A listing interaction can therefore answer “did the visitor express intent?” without answering “did the installation complete?” Keep those questions separate in the chart title and calculation. Also distinguish the listing's Open button from a person's first use after installation. Clicking Open is an interaction with a store surface; it is not the Firebase event definition.
For an agency report, request the actual export and metric description behind any historical “store conversion” label. Record whether the definition changed during the comparison period. A newly selected click metric can create a break in a time series even if creative and audience behavior have not changed.
Do not silently stitch the series together or rename the new metric to preserve a familiar dashboard. Show the break, retain the original exports and agree on a comparable period. A report owner should be able to explain which buyer decision remains valid across that change.
Play first opens and Firebase firstopen need separate definitions
The existence of a Play first-open report does not mean it is the same feed as Firebase. Google's Grow overview documentation describes user/device views and first opens including new and returning acquisitions. Firebase's automatically collected event is defined around launch after installation or reinstallation. These are separate measurement descriptions, not evidence of identical coverage.
There is also a documentation limitation worth preserving. The current Grow overview and Statistics help pages describe different first-open inclusion periods. Verify the exact view and its current tooltip or support clarification before applying a cutoff. This article deliberately does not turn either period into a universal Play rule. Grow overview, Statistics.
The practical consequence is to compare within the same reporting system first, using compatible metrics where available. Then investigate the SDK observation separately. That does not make Play the authority for every business question; it reduces the number of changing definitions in the first comparison.
A first launch also does not prove that the user understood the proposition, completed onboarding or returned. Once entry is understood, the onboarding optimization framework addresses the next product decision. Keep that later-stage question out of an installation diagnosis until there is evidence to connect them.
Build an observation contract before calculating a gap
For each export, write a short contract that another analyst can reproduce. Five boundaries are enough to expose many invalid comparisons:
Identity and unit: package, app, data stream, app version, and whether the row counts events, devices or users.
Population: markets, installation sources, new/returning status, selected traffic categories and any collection restrictions.
Clock: reporting timezone, event-date basis, acquisition period, observation cutoff and the time the export was taken.
Collection and processing: which system observes the action, relevant configuration changes, freshness and known coverage limits.
Decision: the spend or product action the comparison could authorize, its owner and the evidence needed first.
Attach the report settings, not just the exported values. Preserve an untouched copy before producing an adjusted comparison. An analyst should be able to recreate each filter without relying on a colleague's memory.
Use explicit labels such as “Play device acquisitions, selected markets, acquisition period A” and “Firebase Android firstopen events, event period B.” The long labels can live in a data dictionary, but the distinction must remain visible to anyone approving spend.
If the necessary membership or date relationship is unavailable, mark the comparison directional. A ratio of two independently aggregated reports may be useful as an alert. Calling it a measured launch rate requires stronger evidence.
Diagnose in sequence: definition, observation, then credit
1. Check the store-side journey without assigning a cause
Compare the relevant Play acquisition and first-open views with consistent filters and units. Document differences that the interface cannot eliminate. Look for where the pattern changes: one market, device segment, version or release boundary may deserve a focused investigation.
Those patterns generate hypotheses. They do not prove that file size, a crash or weak acquisition quality caused the difference. Ask the product team for corroborating release and reliability evidence before commissioning a campaign overhaul. Similarly, a new creative promise may be worth investigating without concluding that every unobserved launch represents misled users.
Choose the smallest next check that could change the decision. A suspected version-specific problem calls for a bounded release investigation. An unexplained cross-report definition calls for an analyst. Neither begins with a bid increase.
2. Establish whether the SDK could observe the launch
Review the actual Android collection configuration with its owner. Firebase supports disabling Analytics collection, including configurations used before consent is obtained. Its Android collection controls distinguish collection from advertising-personalization controls. Treat each setting according to its documented meaning; do not assume one switch explains every missing event.
Record release versions and the relevant configuration state. Do not fill a reporting gap by enabling collection contrary to the user's choice or the app's obligations. A smaller observable population can be an intended limitation rather than an instrumentation defect.
Use a supported development test to validate a permitted journey. Firebase DebugView exposes development-device event data for instrumentation checks. Observe an appropriate first-launch scenario in a disposable test context, identify the correct stream and record what arrived. Do not reset a customer's data to manufacture a fresh install.
A successful test establishes that tested path. It does not establish universal production coverage, the behavior of every version or equality with store reports. Keep the result alongside its app version and conditions.
3. Allow for processing without inventing a deadline
Use exports taken at an agreed maturity and retain their extraction times. Google's Analytics freshness documentation describes different processing intervals and reports that can change as data is processed. Offline collection also affects timing, with specific first-open handling described in that documentation.
Re-export the same bounded period when the relevant processing stage should be more complete. Explain what changed. Do not treat “wait longer” as a diagnosis if a collection defect or incompatible metric remains unresolved. Conversely, do not declare data lost solely because a recent report is incomplete.
4. Investigate advertising credit only after the observations are clear
Google Ads has a further boundary: the conversion action's source and attribution configuration. Google explicitly cautions against comparing Play installs directly with first opens because they happen at different stages. Its app-conversion comparison guide also discusses settings and reinstall differences for conversion actions within Ads. That guide does not claim to reconcile every external MMP dashboard.
Identify the exact actions used in the campaign and distinguish observation from bidding. Google's Play conversion setup documents primary/secondary choices and conversion settings. Do not change them merely to make two totals agree. Review the campaign's intended optimization job and the consequences with its operator; the Google App campaign goals guide covers that separate choice.
Also avoid treating Play's “Paid and direct” category as a paid-only campaign export. Its current Grow overview definition includes ads, referrals and branded Play searches. A store-category total cannot automatically be assigned to the advertising invoice. Google's traffic-source definitions.
A fictional cost comparison: the residual is still unknown
Suppose an Android team spends $6,000 in a hypothetical test and exports the following. These invented numbers illustrate denominator choices, not benchmarks or expected results.
Reported item Illustrative count What the analyst knows --- --- --- Selected Play device acquisitions 2,000 Store-side total under recorded filters Selected Firebase firstopen events 1,400 SDK events under a separately recorded definition Ads-attributed install conversions 1,200 Campaign credit for the selected action Ads-attributed activated outcomes 300 Selected activation definition and credit
The difference between 2,000 and 1,400 is 600. It is not yet a measured count of people who installed but never opened. The units, traffic populations, returning installations, event dates and collection coverage have not been joined. Even if the periods have matching labels, the records may not describe identical cohorts.
The campaign calculation can still be useful within its stated scope:
Cost per attributed install = $6,000 ÷ 1,200 = $5.
Cost per attributed activated outcome = $6,000 ÷ 300 = $20.
Those figures answer different questions. They do not establish incremental acquisition, profitability or the lifetime value of the acquired users. The CPI vs. CPA framework explains which outcome can authorize a particular spending decision.
Now imagine a report claims that the 600-count residual represents $3,000 of wasted spend by multiplying it by $5. That combines an unassigned store/SDK difference with an Ads-attributed unit cost. The arithmetic works; the population claim does not. Do not approve a media cut from that calculation.
If a valid same-population measurement becomes available, quantify the supported difference at a stated cutoff. If it does not, retain separate observations and describe the uncertainty. It is better to commission a specific collection or product check than to present a precise loss estimate that the data cannot own.
Give each finding an owner and an acceptance condition
Close the investigation with a decision record rather than a repaired-looking chart.
Finding Appropriate next owner Evidence before closure --- --- --- Click metric presented as completed acquisition Reporting owner Corrected definition and clearly marked series break Version-specific collection failure reproduced Engineering and analytics Tested fix and bounded production observation Intended collection limitation Privacy/product and analytics owners Approved coverage description and reporting constraint Observation exists but Ads action differs Acquisition and measurement owners Source/settings record and agreed campaign decision Residual remains unassignable Growth decision owner Explicit uncertainty and a proportionate next check
Define materiality from the action at risk. A discrepancy is material when it can change the proposed spend commitment or product intervention, not when it crosses an invented standard percentage. Record whether the team can proceed within a constrained scope or must defer the affected decision.
For an agency handoff, request the original exports, observation contracts, release timeline, representative test evidence, unresolved gaps and proposed next check. Ask what would disprove the current explanation. A credible review should preserve inconvenient uncertainty rather than make the systems appear identical.
Keep the wider mobile app reporting contract responsible for ongoing governance. This diagnostic resolves a specific entry-stage disagreement; it does not replace cohort value, retention or financial review.
Bring the evidence behind the install report
Sharply Labs' mobile app growth work covers paid acquisition, store conversion and measurement review. For Android founders and growth owners facing an install/open discrepancy, start a scoped conversation with redacted exports, the selected metric descriptions, relevant app-version changes and the spending decision being considered.
The initial conversation provides a prioritized agenda of evidence gaps, likely ownership and the next validation needed. Engineering changes, implementation and a deeper account audit require a separately agreed scope within the relevant growth services. No complete measurement, confirmed root cause, approval, or improvement in CPI, CPA or ROAS is promised. The useful next step is an investigation the responsible team can actually verify.