I wanted to use ratings as a metric. Stars feed directly into store conversion, and across a fleet of 43 apps, per-app rating trends looked useful for prioritization.
I went looking for ratings in the App Store Connect API. They aren't there.
First, a question: do you treat your app rating as a lever or as an outcome metric? I treated it as a lever. That's the twist in this post.
The official API has no ratings
The ASC API exposes average rating and rating count nowhere — not on the app resource, not on the version resource. All you get is customerReviews, and that's a different thing: only reviews with written text. The majority who leave a star and move on are excluded by construction. The story of trusting that endpoint and being badly wrong is its own post → I reported the reviews were gone. Twice.
So the number actually displayed on the product page is unobtainable via the official API. The only source is the public, unauthenticated lookup endpoint.
curl -s "https://itunes.apple.com/lookup?id=<appId>&country=us"
# averageUserRating / userRatingCount43 apps × 3 storefronts
The result was the real twist.
kr + us + jp total 77
of which KR 77
US 0 · JP 0 — across all 43 appsThe US is this fleet's largest install market (390 installs over 110 days, more than Korea's 347). And there is not one US rating across 43 apps. Japan is also zero (157 installs).
The revenue-earning apps are the worst off. The tinnitus tracker, gut log, recovery routine, word chain and pixel puzzle all have zero ratings. The median app has 1–2. At that level, the product page effectively shows no stars at all.
My first hypothesis was wrong
I assumed "I probably never wired the in-app rating request." Wrong. Nearly the whole fleet already has an SKStoreReviewController-based request — there's even a record of back-porting it to 22 apps two months ago.
So why doesn't it fire? The gate. I tightened it to avoid nagging:
3 days since install ∧ 1 core task completed ∧ 14-day cooldown ∧ ≤3 per year ∧ score ≥ thresholdThat's good design. The problem is that non-Korean users never reach the gate. Other fleet metrics say why: 12–15% uninstall rate, 66–84 second sessions, 5–6 daily active devices. Almost nobody outside Korea stays three days and finishes a core task once.
What would you fix here? Loosen the gate so the prompt fires more often, or fix whatever makes people leave before day three? The first is doable this week; the second takes months. But loosening it just shows a prompt to nobody.
So zero ratings is not a prompt problem. It's a retention problem. I had been treating ratings as something you attach. They're an outcome metric of retention.
The two different zeros your tool must separate
r = requests.get("https://itunes.apple.com/lookup",
params={"id": app_id, "country": cc}, timeout=20)
if not r.json().get("resultCount"):
return None # "app absent in this storefront" is not "zero ratings"resultCount == 0 and userRatingCount == 0 are different states. The first means the app isn't in that country; the second means it is and has no ratings. Put them in the same cell and the next person misreads it.
The tool takes a storefront as an argument and writes results to dated JSON, with a short sleep between requests — it's an unauthenticated endpoint and shouldn't be hammered.
apps with any rating 37 / 43 · total 77 · all KR
median 1–2 · max 5 · several top-revenue apps at 0Three things to check right now
- How many ratings does your app have in your largest install market? The public lookup answers that in 30 seconds.
- Write down your rating-prompt gate conditions, then count what fraction of users actually reach them. Near zero means the problem is retention, not the gate.
- Does your collection code distinguish "app not in that country" from "zero ratings"?
The honest part
I mistook ratings for a lever. I was thinking "add the prompt → ratings rise → conversion rises," but the first arrow requires people to still be there on day three. I had the order backwards.
The lookup endpoint's "current version" fields can't be trusted either. averageUserRatingForCurrentVersion and userRatingCountForCurrentVersion came back identical to the all-time values on all 37 apps. I built a hypothesis on that — "ratings are resetting every release" — and dropped it: one app has a May review still alive across several releases, which contradicts it. Safest to treat those fields as mirrors of the all-time values and not use them.
The whole thing also depends on an unauthenticated public endpoint. If Apple closes it, I have no alternative. So instead of live queries the tool writes dated snapshots to disk. Store numbers move slowly, so the delta is the signal.
Why only Korea remains is a hypothesis too. "Korean users are friends and early adopters who stay three days" and "Korean traffic is simply higher quality" aren't separable from this data.
Today's snapshot from that file — 78 ratings, all KR — and the full 41-app list are in the 113-day ledger post.
Go hit lookup for your biggest storefront right now. If the rating count is zero, the thing to fix isn't the popup.