6 min read
App Store Connect source types, explained for indie apps
What App Store search, browse, web referrer and app referrer mean, how the impression to download funnel works, and how to read it next to subscription revenue.
Open App Analytics, look at where your downloads came from, and App Store Connect sorts them into a few buckets. Each App Store Connect source type tells you how someone found your app, which part of your work brought them, and what you could change to get more. For an indie app with a small, uneven trickle of installs, reading those buckets correctly matters more than the totals.
This is a field guide: the source types you will see, the funnel each one has, why the numbers arrive late and sometimes not at all, and how to set them next to subscription revenue without fooling yourself.
What are the source types in App Store Connect?
Apple credits every impression, product page view and download to the place it started. Four of them carry almost all the traffic for a typical indie app:
| Source type | Where the person started | What it usually means for an indie app |
|---|---|---|
| App Store Search | A query typed into the App Store search tab | Your name, subtitle and keywords are being matched, or someone heard about you and searched your name |
| App Store Browse | The Today tab, the Apps or Games tabs, charts and category lists | Featuring or chart placement. Small and spiky for most indie apps, large for a week if Apple features you |
| Web Referrer | A link to your App Store page, tapped on a website in a browser | Your own site, your blog posts, press coverage, directories that link to you |
| App Referrer | A link tapped inside another app | Links shared in messaging and social apps, or cross-promotion from your own other apps |
You may also see smaller buckets, including one for activity Apple couldn't attribute. They are worth a glance when they grow, and safe to ignore when they stay small.
Branded search lives inside App Store Search
This catches people the first time. You post about your app somewhere, people open the App Store and type its name, and the downloads land in App Store Search. The post did the work; search gets the credit. A jump in search downloads the day after a launch is almost always the launch, not your keywords.
The practical rule: before you celebrate a keyword change, check whether anything else happened that week that would make people search for you by name.
Social links can land in either referrer bucket
Whether a tap from a social app counts as web referrer or app referrer depends on how that app opens links: in its own browser, in Safari, or straight into the App Store. Don't conclude a channel brought nothing until you have checked both referrer sources. Better still, give each channel its own campaign link, which we cover in App Store campaign links.
How does the impressions → product page views → downloads funnel work?
Each source type has its own three-step funnel, and the steps answer different questions.
Impressions count the times your app was shown: a row in search results, a tile on a list, a feature card.
Product page views count the times someone opened your product page.
Downloads here means first-time downloads plus redownloads. Updates and restores are separate and don't belong in an acquisition funnel.
From those, two ratios are worth tracking per source:
- Page views per impression. Low in search means the result itself isn't earning the tap: icon, name, subtitle, the first screenshots shown in results.
- Downloads per page view. Low here means people looked and left: screenshots, description, ratings, price.
For the referrer sources, the first ratio barely matters. Someone who taps your link goes straight to the product page, so judge web and app referrer on downloads per page view, and on how many page views they bring at all.
A hypothetical week, to make the shape concrete:
| Source | Impressions | Page views | Downloads | Downloads per page view |
|---|---|---|---|---|
| App Store Search | 4,000 | 600 | 150 | 25% |
| App Store Browse | 900 | 40 | 6 | 15% |
| Web Referrer | 260 | 220 | 90 | 41% |
| App Referrer | 130 | 110 | 35 | 32% |
Read this way, search is the volume and the referrers are the intent. When your sources differ like this, a single "conversion rate" for the whole app hides more than it shows.
Why are the numbers late, and why do small ones disappear?
Two things make App Store data feel unreliable when it isn't.
It arrives late. The analytics reports land a day or two after the day they describe. If you check on Tuesday morning, Monday is probably missing or partial. Don't read the most recent day as a drop.
Small numbers get withheld. Apple applies privacy thresholds so that tiny counts can't be traced to individual people. When you split a small app by day, source type and campaign, a lot of cells are tiny. The effects:
- the sum of the sources can come out lower than the app total,
- a campaign with a handful of downloads can show nothing on some days and a few on others,
- a new source can look like it started on a later date than it really did.
The fix is boring and works: look at weeks, not days. Sum seven days before comparing sources, and treat any cell in single digits as a hint rather than a measurement.
How do you pair source types with subscription revenue?
App Store data is aggregate. Apple doesn't tell you which person downloaded from which source, so you can't follow a single user from an impression to a paid subscription. Anyone who claims to show you revenue per App Store search keyword is modeling, not measuring.
What you can do honestly is line up the same periods side by side: the store funnel per source, then trials started and new MRR from your subscription data.
| Week | Search downloads | Referrer downloads | Trials started | New MRR |
|---|---|---|---|---|
| Week 1 | 150 | 125 | 48 | €210 |
| Week 2 | 230 | 120 | 51 | €225 |
In this hypothetical, search downloads rose by half and trials barely moved. That suggests the new search traffic is low intent, perhaps a broad keyword that matches people who aren't your users. It doesn't prove it. Correlation across a few weeks is the most this data supports.
Two habits make the comparison less noisy:
- Respect the lag. A download becomes a trial on day one or later, and a trial becomes paid only after the trial ends. With a 7-day trial, this week's new MRR belongs mostly to last week's downloads. Shift one series before you compare them. If trial conversion itself is moving, see trial-to-paid conversion rate first, because a change there will look like a change in traffic quality.
- Use the web side where you can. Web referrer traffic often starts on your own site, which you can measure per visitor. If the page that links to the App Store is your blog, you know how many people read it and clicked, even if Apple only gives you totals after that.
What should an indie app actually watch?
Most weeks, three numbers per source are enough: product page views, downloads, and downloads per page view, with trials and new MRR beside them for the same period shifted by your trial length. Look at App Store Browse only when you have been featured. Look at the referrer sources by campaign once you have campaign links in place.
If you'd rather not assemble that table each Monday, Joinsight's App Store Connect integration reads impressions, product page views and downloads by source type and by campaign within a source, shows them next to RevenueCat trials and new MRR, and labels the thin cells instead of hiding them. The same funnel is available to Claude through the get_app_store_funnel tool on the MCP server.