472538 - Daily & Total Download Counts appear to have been too high since Nov 16

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Statistics, defect)

Description

[Seth Wagoner]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: 

This might be related to the ADU Count bug 468570 - or it might be a completely different bug. 

As I discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=469376#c8

There is a serious descrepancy between the AMO download stats and what we are seeing on our onInstall page ping counts. Currently, we are seeing about 20k/day on AMO vs 4-5k on our onInstall page, and it has been that way since 21Dec - the stats before that are even *more* broken particularly Dec 15/16 which are possibly 10x higher than they ought to be. 

Here is what I had to say on Dec 15th (from the above comment link): 

Looking at the AMO stats for Interclue (addon 4999), and comparing them with
the hitcounts for our onInstall page, I would say that the AMO stats for

16Nov-8Dec: have roughly twice the expected number. 
Dec 9: has approx 0.5x the expected number. 
Dec 10: has 2-3x the expected number.
Dec 11-13: have 4-5x the expected number.

Sorry I can't be more accurate, but I don't by any means take our hit-count on
the oninstall page as gospel, given that it won't count anyone using noscript,
and sometimes the page gets hit from sources other than an actual install, but
up until a little while ago it was always *reasonably* close to the AMO count,
and since then it's been way out. 

Also, our total download count and weekly download count are currently way
higher than they ought to be, and, as mentioned in the title of this bug, the
last two weekly update-ping counts are broken as well, and conversely are on
the very low side. 

I'm pretty sure that the AMO numbers made sense a week ago, and that the
doubling of the 16Nov-8Dec download counts must have happened in the last few
days, possibly due to reprocessing of the logfiles? 

The pre-Nov-16th counts I'm not sure about, but they seem close enough. We got
a big boost Nov 16 from being in Fashion your Firefox, then a bigger one Dec
1st as we went into the featured list, but not as big a boost as seen in the
current numbers! 


Reproducible: Always

Comment 1

[Jorge Villalobos [:jorgev] (he/him)]

Some examples:
https://addons.mozilla.org/en-US/firefox/statistics/addon/1865
https://addons.mozilla.org/en-US/firefox/statistics/addon/1843
https://addons.mozilla.org/en-US/statistics/addon/7684

Zooming out makes it quite evident.

We were planning a 1M download celebration for Fire.fm (last one) around February, which was our ballpark, but now we're nearing 2M!

Comment 2

[Wil Clouser [:clouserw]]

I wanted a wider audience than just this bug so I posted this to my blog but this is our current plan and timeline:  http://micropipes.com/blog/2009/01/22/add-on-statistics-status/

Short answer:  This should be fixed at the end of next week and then we'll start back filling stats.

Comment 3

[Nick Nguyen [:osunick]]

Daniel, do we have an ETA on this?

Comment 4

[Wil Clouser [:clouserw]]

Daniel processed some stats last night with the new script and the numbers are a lot lower than the current numbers.  We're attributing that to this bug (specifically: the dupe request filtering in the current script was broken).

When he imports the February numbers expect a sharp drop in your stats down to correct numbers and let us know how they line up with what you're seeing on your servers.

Comment 5

[Wil Clouser [:clouserw]]

New download numbers are in for Feb 1-4.  Feb 5-6 will go in tonight and then it will be updated nightly.

The stats table at the bottom updates separately but should take less than an hour.

Comment 6

[Mike Kaply [:mkaply]]

The blog post indicated there would be detail in this bug.

> the dupe request filtering in the current script was broken

Is not detail.

Can someone please detail exactly what the problem was and what was the fix?

Comment 7

[Wil Clouser [:clouserw]]

(In reply to comment #6)
> The blog post indicated there would be detail in this bug.
> 
> > the dupe request filtering in the current script was broken
> 
> Is not detail.
> 
> Can someone please detail exactly what the problem was and what was the fix?

The code was rearranged in r20420 and the counting code fell outside of an else statement that it shouldn't have.  This happened on 12-11; I don't know why it was miscounting before then but I don't plan on investigating.  We've replaced the entire log parsing system as it's clearly outgrown itself.

Comment 8

[Wil Clouser [:clouserw]]

Bug 477923 is tracking back filling statistics.  What do you think of the past week of stats?

Comment 9

[Wil Clouser [:clouserw]]

I'm pulling this out of our milestones for now.  It's essentially fixed except for the backfilling which it's dependent on.  Once the backfilling is done this will be resolved.

Comment 10

[Daniel Einspanjer [:dre] [:deinspanjer]]

This bug can probably be marked as fixed.  Download stats for 2008-11-15 to 2009-02-23 were inserted to production as part of Bug 477923.