App Market Catalogue Analysis

A product team planning a new mobile app needs to know where it can compete. The obvious approach is to rank categories by average rating or total installs. Both are misleading. Store listings are a catalogue, not a census of usage: ratings are missing for a large share of apps, installs are published in bands, and the "average" app sits in a distribution that is heavily skewed by a small number of very large titles.

The decision

The team needed to choose a category and a positioning strategy: where demand is large enough to matter, where competition is crowded, and where a paid or niche product can still find space. That requires comparing categories on like-for-like measures and being explicit about what the listing data cannot show — retention, acquisition cost and revenue.

What we worked with

A snapshot of roughly 10,800 app listings with 13 fields:

• Identity: app name, category and genre labels.
• Engagement signals: rating, review count and install band.
• Listing attributes: free or paid, price, size, content rating and last update.
• Technical context: current version and minimum Android version.

The traps we designed around

• Installs are bands, not counts. Values such as "10,000+" and "5,000,000+" are ordered categories. Averaging them requires a documented midpoint assumption, and the result is not a count. We kept the original band and analysed the distribution instead of reporting a false precision.
• Missing ratings are not random. Around 13.6% of listings have no rating, and the rate varies by category: in some categories a third of apps are unrated. Those apps are not a random subset — they may be new, low-engagement or simply not promoted. Treating missing ratings as zero would distort every category comparison.
• Duplicate app names. More than a thousand listings reuse a name that appears elsewhere. Without a package identifier, it is not possible to tell whether these are duplicate listings, regional variants or unrelated apps. We avoided deduplicating on name alone and reported the ambiguity.
• One row is not one app. The snapshot includes listing metadata that changes over time. Reviews and ratings are cumulative; the file does not show the period over which they accumulated.
• Dirty categorical fields. "Type" contains a missing value and a stray "0"; prices are strings and free apps are represented as zero rather than a separate flag; sizes mix megabytes and "Varies". Each has to be normalised explicitly.
• Averages hide the shape. A category with a high mean rating can still be dominated by poorly rated apps. Medians, percentiles and the share of unrated apps tell a more useful story.

How the analysis was built

1. Normalise the listing fields. Install bands were converted to an ordered scale, prices to numeric values, and size and type to documented categories. Invalid rows were quarantined rather than silently coerced.
2. Profile coverage before comparing. For each category, we reported the number of listings, the share with a rating and the share that were paid. Categories with too few listings were flagged.
3. Compare distributions. Category profiles used median rating, rating percentiles, install-band distribution and paid share — not a single average.
4. Separate description from inference. The analysis describes the catalogue as observed. It does not infer downloads, revenue or retention, and it does not treat rating as a measure of product quality.
5. Build a decision view. Categories were plotted on two axes the team could act on: catalogue size (competition) and the share of listings with meaningful engagement signals (evidence of demand). The chart was a conversation aid, not a scoring model.

What this changes

• Category choice is framed as trade-off. Large categories offer demand but also more competition and more unrated noise; smaller categories may be easier to enter but provide weaker evidence.
• Missing ratings become information. A category with many unrated apps is not necessarily weak — it may be young or under-promoted — but it cannot be compared on rating alone.
• Paid share is treated as a positioning signal. It changes the pricing and acquisition conversation, not just the product one.
• The team stops asking for "the average app". They ask for the distribution and the segment they intend to compete in.

What you receive

• A cleaned listing table with documented parsing rules.
• A category coverage report showing listing counts and missing-rate by field.
• Distribution views by category, install band and price type.
• A one-page positioning summary with explicit limits.

Where this applies

The method fits app publishers, marketplace teams and product marketers evaluating a catalogue. The minimum inputs are a listing snapshot with category, install band, rating, review count and price type. The first deliverable is a coverage and missingness note, because ratings and installs are rarely as complete as dashboards imply.

This is an illustrative case study using a public app-store listing snapshot; it does not report results from a specific client engagement. It reflects our standard method for catalogue and market analysis.