ASO Patents

Document type	Academic study, not a patent
Title	Google Play Store App Ranking Prediction Using Machine Learning Algorithm
Authors	Muhammad Suleman, Ahsan Malik, Syed Sajjad Hussain
Affiliations	College of Computer Science and Information Systems, Institute of Business Management, Karachi. Faculty of Engineering Sciences and Technology, Hamdard University, Karachi
Platform studied	Google Play Store
Dataset	Described as a real time dataset of over 10,000 apps
Tools	MATLAB 2018, Microsoft Excel
Best model	Fine tree regression

What This Study Covers and Why It Matters for ASO

What it examines: whether a machine learning model can predict an app’s standing on the Google Play Store from publicly visible attributes such as category, install count, review count, size, price type, Android version compatibility and content rating.

This is the one item on this site that is a research paper rather than a patent, and it is worth being precise about what that changes. A patent is evidence about what a platform designed. A study like this is evidence about what an outside observer can infer from public data. Those are different kinds of knowledge, and conflating them is the most common mistake in ASO writing.

The honest headline: this study does not tell you how Google ranks apps. It tells you how well a small set of visible metrics predicts another visible metric across a sample of apps. Those are correlations among outputs of the ranking system, not a view into the system itself. The authors do not claim otherwise, but the title invites the stronger reading, and the stronger reading is not supported.

What it is genuinely useful for:

• It puts a number on how much of the variation in app standing the obvious public metrics explain, and the number is modest. An R squared of 0.52 means roughly half the variation is not accounted for by category, installs, reviews, size, price type, compatibility and content rating combined.
• That residual half is the interesting part. It is where metadata quality, creative, retention, conversion and everything else that is not in a public dataset lives. A study that explains half the variance with the easy variables is, read correctly, an argument that the hard variables matter.
• It is a useful template. The method is reproducible in your own category with your own data, and doing that per category is more informative than any cross category average.

A sourcing note. We have not been able to verify the publication venue, year or DOI for this paper from an independent source, and the summary below reflects the paper as previously read for this site. If you have the citation, please get in touch and it will be added.

Study Summary

The authors set out to help two audiences at once: users trying to identify good apps among too many options, and developers trying to understand what drives their app’s standing. Their starting observation is that rating and review counts alone are thin information for a user making a choice.

They assembled a dataset of over 10,000 Google Play Store apps, cleaned and normalized it, selected features, and applied a range of regression techniques including linear regression and decision trees. Models were evaluated with root mean square error, R squared and mean absolute error. The best performer was a fine tree regression model.

Metric	Value	Plain reading
RMSE	0.33	Typical error of about a third of a point on the response scale
R squared	0.52	About 52 percent of the variation explained, 48 percent unexplained
MAE	0.21	Average absolute error of roughly a fifth of a point
Average test accuracy	61.62 percent	Reported by the authors alongside the regression metrics

The authors conclude that implementing a tree algorithm to predict app ranking is feasible, and that forecasting a suitable rating for an app can help improve app positioning, manage trends in the app store and make rating systems more accurate.

Detailed Explanation

The features used

The input fields, as described in the paper, are app category, number of reviews, number of downloads, app size, type meaning free or paid, Android version compatibility, and content rating. App Annie analytics is also named among the parameters considered.

Two observations about that list.

First, every one of these is a store level attribute. There is nothing about the app’s text, nothing about its screenshots, nothing about retention or session behavior, and nothing about keyword performance. So the model is being asked to predict standing from the app’s shape rather than from anything about how well it satisfies users.

Second, the reference to App Annie analytics as an input field is not developed. App Annie, now data.ai and since merged into Sensor Tower, provided estimated download and revenue data. Including estimates derived from a third party model as a feature alongside the platform’s own published figures would raise questions about what the model is actually learning from. The paper as summarized does not clarify how or whether that field was used.

Ranking or rating?

This is the study’s central ambiguity and it has to be addressed head on. The title and framing are about predicting app ranking. The results discussion describes the best model as providing the best app rating prediction, and the concluding sentence talks about forecasting a suitable rating against an app.

Those are not the same target and the distinction is not cosmetic.

• Rating is a 1 to 5 average of user scores. An RMSE of 0.33 and MAE of 0.21 are consistent with a 1 to 5 scale, which suggests rating is the actual response variable.
• Ranking is a position in a list, produced by Google’s algorithm. Predicting it would require position data, which is not in the described feature set and is not what the error metrics look like.

On the evidence available, the study predicts rating and describes it as ranking. That reframes the contribution considerably. Predicting a rating from review counts and install counts is a reasonable exercise, but it is a study about user satisfaction, not about store ranking.

The circularity problem

If the response variable is rating, then including number of reviews as a feature deserves scrutiny. Review count and rating are not independent: apps accumulate reviews and ratings through the same act, and rating stability is a function of review volume. A model given review count is partly being told about the thing it is predicting.

The same concern applies to download count. Downloads are influenced by visible rating, so a model predicting rating from downloads is learning a relationship that runs in both directions. Nothing in the described methodology addresses this, and a cross sectional regression cannot separate the directions.

This does not make the result worthless. It does mean the R squared of 0.52 should be read as an upper bound on explanatory power rather than a conservative estimate, because some of that explained variance is likely the target explaining itself.

What the dataset probably is

The paper describes a real time dataset of over 10,000 Google Play Store apps. No collection method, date range or scraping approach is specified in the material available.

A dataset of roughly that size with exactly those columns, category, rating, reviews, size, installs, type, price, content rating and Android version, matches the shape of widely circulated public Play Store datasets used in teaching and in dozens of similar papers. That is an observation about the shape of the data, not an accusation, and the paper may well describe its own collection in a section not summarized here. But “real time” is a strong claim and it is not supported by anything in the described methodology, so it should not be repeated as fact.

Sample size matters too. Ten thousand apps is a small slice of a catalog in the millions, and if the sample skews toward popular apps, which most public datasets do, then the findings describe the visible end of the store rather than the store.

Method and tools

The pipeline described is conventional: data collection, pre-processing to clean and normalize, feature selection, model training across several regression techniques, and evaluation against RMSE and R squared. The work was done on Windows with MATLAB 2018 and Microsoft Excel for data manipulation.

Fine tree is MATLAB’s own naming for a decision tree with a large number of leaf nodes, meaning a low minimum leaf size and therefore a highly flexible fit. That it outperformed the alternatives is expected and carries a caveat: fine trees overfit readily, and a reported average test accuracy of 61.62 percent against an R squared of 0.52 is consistent with a model that has learned the sample better than the phenomenon. Cross validation details would settle this and are not described.

What it does and does not establish

Claim	Supported?
Public app attributes correlate with app standing	Yes, moderately
Roughly half the variation is unexplained by those attributes	Yes, and this is the most useful finding
Tree based models beat linear models on this data	Yes, as reported
The study reveals how Google ranks apps	No
Optimizing the studied features will improve ranking	No. Correlation across apps does not imply an effect within one app

The fifth row is the one that matters most in practice. A finding that larger install counts accompany better standing across a sample does not mean that any action you take on install count will move your standing. That is the difference between a cross sectional association and a causal lever, and no model trained this way can tell you which you are looking at.

How to use this in practice

• Repeat the exercise inside your own category rather than accepting a cross category result. Category is one of the features precisely because it dominates, so averaging across categories hides more than it reveals.
• Read the unexplained half as your working brief. If public attributes explain around 52 percent, the work that differentiates apps sits in the remainder.
• Do not cite this study, or studies like it, as evidence about Play Store ranking factors. Cite it as evidence about how much public metrics explain.
• If you build your own model, hold out time as well as apps. Predicting next quarter from this quarter is a much harder and much more useful test than predicting one app from other apps.

Why this sits alongside the patents

The contrast is the point. Apple’s patents name the signals directly: download distributions per query, conversion rates across time windows, installation retention factors, click through rates stored in three variants. An outside study working from public data has category, installs, reviews, size, price and compatibility.

That gap is the reason this site reads patents. Not because patents prove what is implemented, but because they name the variables that the platforms themselves consider worth computing, and no amount of regression on public data will recover a variable that was never published.