Closed Bug 663261 Opened 14 years ago Closed 14 years ago

User count on public pages is total lifetime average (was supposed to be the week's average)

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: davemgarrett, Assigned: jbalogh)

References

Details

From bug 589364: Justin Scott: > We currently show weekly downloads in most add-on listing pages across the > site. Let's switch to showing the average daily users from the past 7 days. Justin Scott: > This number is only for the last 7 days, right? I think it used to be for > the whole add-on's life. Jeff Balogh: > It will be once the cron runs tonight. Flagfox is listed as having 1,063,877 users on the various public pages. e.g.: https://addons.mozilla.org/en-US/firefox/extensions/alerts-updates/?sort=users That number is the average over the total lifetime since 2007. See stats here: https://addons.mozilla.org/en-US/statistics/addon/5791 The average over the past week is 1,666,275 users. That's a 600k (36%) difference. As Firefox usage trends up and addon usage generally trends up, the lifetime average is fairly useless. Besides, users only care if people are using an addon, which implies now. This was supposed to be the 7 day average as stated in bug 589364 but that didn't happen for some reason. A footnote: If you want to state the number of users an addon has, rather than an average a more accurate count would be the peak daily user count over the past 7 days. Not all users use all addons everyday. Different addons have different usage patterns. Flagfox and other addons that get used in workplaces and/or schools have higher usage counts on weekdays. In my case Flagfox has 200k-300k weekday-only users which translates to the peak/total user count being around 100k more than the 7 day average. Some other addons have smaller or larger regular fluctuations.
Priority: P1 → --
The cron hasn't run yet.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
That explains it. Your "tonight" was 2011-06-01. When's it scheduled to run now?
(In reply to comment #2) > That explains it. Your "tonight" was 2011-06-01. When's it scheduled to run > now? The discussion you quoted on IRC was about the staging server. We pushed this code today so the "tonight" for production is...tonight.
Still shows the same exact number. Not run on production yet?
Looks like the job has failed for the last 2 days in production with "Lost connection to MySQL server during query." May have to break up the query?
Assignee: nobody → jbalogh
Status: RESOLVED → REOPENED
Priority: -- → P3
Resolution: WORKSFORME → ---
Target Milestone: --- → 6.1.2
The query was forcing an index that is not optimal anymore. I don't know if anything is optimal on update_counts, but we'll see how it rolls with this. https://github.com/jbalogh/zamboni/commit/8a50edf
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
The new 7-day average is already showing on the listing pages. Marking verified. That being said, now the stats page has two slightly different ADU/week numbers shown. If these are essentially the same number now shouldn't one (e.g. the one without the percentage changed footnote) be dropped from the table? Or better yet, how long until the long awaited stats page overhaul is ready?
Status: RESOLVED → VERIFIED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.