Troubleshooting
Why Firebase first_open Is Higher Than App Store Downloads
Updated 2026-09-145 min read
Short answer
first_open is logged the first time an installation of your app is launched, including reinstalls, extra devices and test builds. App Store Connect counts a first-time download when an Apple Account gets the app for the first time. They measure different moments, so first_open is usually higher — and a gap that stays stable from week to week is normal.
It usually surfaces in launch week. Firebase reports 1,240 new users, App Store Connect reports 860 first-time downloads, and someone asks which one is wrong. Neither is. They count different events, and once you know which, the gap stops being alarming and becomes a useful check on your data.
What looks wrong
App Store Connect — first-time downloads 860 App Store Connect — redownloads 190 Firebase — first_open (iOS stream) 1,240 first_open is 44% above first-time downloads, and still 18% above all downloads combined.
Two counters for two different moments
Apple counts at the store. A first-time download is counted when an Apple Account gets the app for the first time; when the same account downloads it again — after deleting it, or onto another device — Apple records a redownload. Firebase counts on the device: first_open is logged the first time the app is launched after being installed or re-installed, and nothing is logged at download time.
| App Store Connect | Firebase first_open | |
|---|---|---|
| Counted when | Someone taps to download | The installed app is launched for the first time |
| Reinstall on the same phone | A redownload | Another first_open |
| One person, iPhone and iPad | One first-time download and one redownload | Two first_open events |
| TestFlight or Xcode build | Not counted | Counted, if the build sends Analytics |
| Downloaded but never opened | Counted | Not counted |
Why first_open runs ahead
- Reinstalls: every delete and reinstall produces a new first_open, while Apple files it as a redownload
- More than one device: someone with an iPhone and an iPad launches two installations
- Test builds: TestFlight, Xcode runs and internal builds send first_open to the same Firebase app unless you separate them, and App Store Connect never sees those installs
- Automated testing: test devices and device farms launch the app the way a person does
- Another platform in the same property: an Android stream's first_open added to a figure you are comparing with the App Store
- Day boundaries: GA4 assigns events to days in your property's reporting time zone, which may not match the dates in Apple's reports, so launches near midnight can land on different days
The gap can also run the other way. Downloads that are never opened, installs that fail, and launches where Analytics collection is switched off — for example until someone answers a consent prompt — all push first_open below the store figure.
How to check which cause applies
Line up the same days and one platform
Compare complete days only, with the GA4 figure filtered to your iOS stream. A property that also contains Android or web data will never match App Store numbers.
Add redownloads to the comparison
If first_open lands close to first-time downloads plus redownloads, reinstalls and extra devices explain most of the gap.
Break first_open down by app version
Launches on a version that was never released on the App Store are test builds. A burst on a TestFlight-only version is the clearest sign there is.
Look at device model and location
Test traffic clusters: a few device models, your own city, activity during working hours around a release.
Track the ratio week by week
A ratio that holds steady is a difference in definitions. A ratio that jumps means a new source of first_open — a beta group, a device farm, a second platform — and the week it jumped tells you when it started.
Tip: Write down the ratio for an ordinary week. When it moves, look for a new source of first_open before celebrating growth or worrying about a drop.
What goes wrong if you misread it
- Reading first_open as downloads overstates acquisition, and every rate built on top of it — cost per install, trial conversion — looks better than it is
- Using store downloads as the base for retention mixes definitions: Analytics can only follow installations that opened the app, not downloads
- Calling the gap "tracking loss" and adding a custom install event on top creates duplicates instead of fixing anything
- Removing test builds from a spreadsheet each week keeps every past date in the property wrong
A comparison that holds up
Use each number for the question it answers. App Store Connect tells you how many people the store turned into downloads. first_open tells you how many installations actually started — the right starting point for retention and funnels in Analytics. Compare the two as a ratio per platform and per week, and never subtract one from the other and call the difference lost users.
Note: If test builds inflate first_open, fix it where it starts: a separate Firebase app for development builds, or Analytics collection switched off in debug builds. The guide on separating test users from real users walks through both.
How this looks in Appnaly
Where both App Store Connect and Firebase are connected, Appnaly keeps the two sources side by side instead of merging them, and compares their direction rather than their raw counts. One of its checks looks for new downloads holding steady while first-use records fall — a pattern that usually points at measurement rather than at demand — and it only runs when both sources have enough data in complete weeks.