Due to differences in hosted vs packaged (hosted doesn't re-ping the market) we can't base our stats on active daily users. We should base the popularity of apps solely on average number of installs over the last 30 days.

Let's do this with monolith

Popularity uses the `Installed` table which only includes logged-in user installs. We should include anonymous installs when calculating popularity as well. This would likely need a new table since we want popularity per region and don't want to have to pull this from monolith whenever we want it. (And to avoid coupling ES indexing to require Monolith)

Note: We recently updated the code to store `weekly_downloads` and `total_downloads` which is populated via Monolith. Currently popularity uses `Installed` which is total installs -- albeit not completely reliable and only counts logged-in user installs. We could pretty simply switch to using `total_downloads` as the popularity metric.

let's do it

Should we do total downloads over last X days (like 90?) so that newer, more popular things have a chance to make the popular list?

I filed bug 1116564 to fix or remove regional popularity. If we moved to calculating popularity as "installs in the last 90 days" we could also calculate that per region and make regional popularity actually mean something.

https://github.com/mozilla/zamboni/commit/7388ab8 To verify: * Ensure that a re-index has occurred to pull in the new popularity score (ask robhudson on IRC) * View apps sorted by popularity. * Ensure that the top apps look reasonable based on their 90 day install counts in statistics.

Verified as fixed in FF38(Win7) I have checked statistics for several apps in the Popular list and they look good. The apps with most install counts are displayed first. Closing bug.