Why your App Store Connect and Google Play Console numbers never match (and never match your analytics)

Ahmed Ashour — Mon, 26 Oct 2026 00:23:53 +0000

I build a few apps on the side, and every morning I opened App Store Connect, Play Console and my analytics, and no two of them agreed.
While building my own dashboard I had to find out why, one number at a time. These are the reasons I found.

The store counts downloads, your analytics counts opens

The store counts a download when the app gets installed. Your analytics only sees someone after they open the app with your SDK running. Everyone who downloads and never opens it is in the store number and nowhere else.

So your analytics "new users" will be lower than store downloads, and that's normal.

"Downloads" means different things on each store

On the App Store, first-time downloads and redownloads are separate numbers. Someone who deletes the app and gets it again is a redownload, not a new download. Updates are counted on their own too. Check which one your chart shows before you compare it with anything.

On Google Play, users and devices are counted apart. A user is a Google account, a device is a phone or tablet. One person who installs on a phone and a tablet is one new user and two new devices. And the installed audience (devices that have the app right now) is a third thing again: it goes down when people uninstall, downloads never do.

Your analytics counts installs, not people

A reinstall, a second phone, or logging out and back in gives the app a new install id. Count by install id and each of those is a new user.

When I switched to counting signed-in people by account instead of by install, 8 of 114 people in one of my apps had been counted twice or more.

Background wake-ups do it too. A silent push that wakes the app to schedule reminders can look like a visit. On one day, 6 of 83 phones my SDK saw had only been woken by a push, nobody opened the app. Now I only count a session where the app was actually open.

Test phones look like real users

Google Play runs every build you upload on its own test phones for the pre-launch report. In my data that's a burst right after each upload: OnePlus 8 Pro on Android 11 (API 30), a US IP, random en-XX locales.

Apple's review opens your new version from a US iPhone, on a version that isn't on the App Store yet. And if your SDK runs in debug builds, simulators send events too. One day, 11 of one app's 28 "new people" were simulators, which was just me testing.

Across my apps these were about 1 in 10 new people. They also made purchase errors that no real person had, and made the "came back" rate look worse.

What I filter out now: emulators and simulators, the pre-launch devices, and any phone that only ever ran a version that isn't in the store yet.

Store data is late

Today never has downloads. Store numbers show up a day or two late, and downloads can take 2 to 5 days to arrive (Play is the slow one).

So if you put yesterday's store number next to yesterday's analytics, it almost always looks like a drop. Compare days that are a few days old, or compare today with a usual day at the same hour using your own events.

Everyone has a different midnight

Each tool ends the day at its own midnight, and it's not always yours.

My own dashboard had this bug. The Today page started the day at Berlin midnight and every other page at UTC midnight, which is 1 or 2 am here. Same day, different people on two pages. A sale at 00:30 showed up on the day before.

Daylight saving adds one more: the night the clocks go back, a day has 25 hours. That broke my "same time yesterday" math until I compared by clock time instead of by milliseconds since midnight.

Before you compare a day across tools, check which timezone each one uses.

Two analytics tools count the same person twice

If an app sends events to two tools (I had Mixpanel and my own SDK side by side for a while), never add their numbers. My per-day table counted a signed-in person twice when both tools saw them. Pick one source for each number.

Reviews: each store gives you a different half

Google Play's review export includes star-only ratings, but no country. You only get the reviewer's phone language, so "German" means a phone set to German, not a person in Germany.

The App Store API only returns reviews that have text, with the reviewer's country. Star-only ratings can't be fetched by any tool. So anything that lists your iOS reviews will show fewer than your rating count.

App Store usage numbers are a sample

Sessions, active devices and crashes in App Store Connect only come from people who agreed to share analytics with developers. They're a sample, so they'll be lower than what your SDK sees.

Money: what they paid vs what you get

Apple's sales reports have both the customer price and your proceeds after Apple's cut. If one tool shows one and another shows the other, they'll never match. Check which one you're looking at.

What I do now

Downloads come from the stores, people come from my own events. I never subtract one from the other.
People are counted by account, and only when the app is open.
Test phones are out: pre-launch devices, simulators, unreleased versions.
Store days only after they've settled. For today I compare with a usual day at the same hour.
One midnight for everything.

I got tired of this enough that I built apparent.fyi, simple analytics that celebrates your app's small wins.

DEV Community: Ahmed Ashour