Closed Bug 545704 Opened 14 years ago Closed 10 years ago

don't auto initiate download and bouncer hit if user visits download page has current version of firefox installed

Categories

(www.mozilla.org :: Information Architecture & UX, defect)

Product:
www.mozilla.org
Component:
Information Architecture & UX
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: chofmann, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

downloads v. adu's for first few weeks of 3.6
69.73 KB, image/png
Details
rough translation of mozilla.jp Firefox donload page
184.79 KB, image/jpeg
Details 
      No description provided.
Mysterious...
OS: Mac OS X → All
Hardware: x86 → All
see  Bug 477324 for more details but there are a few cases that we are causing downloads to be initiated and bouncer hits to happen that result in large over counting of our download stats.   Maybe by as much as 2 or 3x.

we need to fix this by sniffing for the current version of firefox and not starting the download or causing a bouncer hit if the user already has firefox installed.

here are the scenario's.

user checks for updates, or has been served the update.
they might not be sure if they want it so from the software update dialog they
click on 

  "view more information about this update"

That takes them to the release note page which has links to download.html

If they click on the link and get to download.html they get an auto initiated
download; but then they figure out that's really not what they need or want. 
The user then is likely to dismiss the download resulting in one "over count",

but then they leave the download.html page around in an open tab.
the user then goes back to proceeding with the update on the software update
dialog.  after the update happens they get the dialog to restart their browser.

After the restart with the new update version the old set of tabs from the last
session gets reopened and they would hit
http://www.mozilla.com/en-US/products/download.html?product=firefox-3.5.6&os=win&lang=en-US
 with the new installation.  This would be the second over count, and the one
with the current version user agent.


we could test the theory in comment 23, or fix the problem if one exists, by
changing Firefox session restore to not (re)load download.html after a firefox
restart, but that seems like kind of a weird special case change.

I think the server side check to to find if you  are downloading a version that
you already have, and redirecting to a page that does not autostart another download would be a better solution.
for example we now are reporting just over 50 million downloads since firefox 3.6 was released, but we only running at around 13 million active daily users.   even if you apply the 3x multiplier we would still be 10's of millions of downloads off in the correct count.
Summary: don → do
Summary: do → don't auto initiate download and bouncer hit if user visits download page has current version of firefox installed
the growing gap between number of "reported" downloads v. the increase in active daily users is in part created by this over counting.
We (mozilla.jp) have already considered this... When Firefox users visit http://mozilla.jp/firefox/ and click the green download button, they'll be informed that "you are using the latest version" or "update recommended", and the built-in Check for Updates feature will be proposed. This prevents full-sized installers from being downloaded by the current Firefox users.
Copying Dave & Daniel, as they're the guys who know how the download counter works.
morgamic,  can we get this on the q2 goals/schedule?

I'm pretty sure this plays a larger part of the discrepancy between the 120 million downloads we have for 3.6, and only ~20 millon adu's
What about people using the latest version who legitimately want to download the latest version again (to put an a USB disk or burn on a CD for a friend)?
As you can see in the screenshot above, we have a manual download link at the bottom of the page.
they should be able to click for a download, but not have the download auto-initiated.

With the sniffing in place We could change the text on http://www.mozilla.com/en-US/products/download.html?product=firefox-3.6&os=osx&lang=en-US to show:

if not $LATEST_VERSION$

  Thanks for choosing Firefox!

  Your download should automatically begin in a few seconds, 
  but if not, click here

else

  Thanks for choosing Firefox!

  It looks like you already have the latest version of Firefox,  
  but if you need a another copy to share with others or reinstall, 
  click here to download another copy.

This might also be a good place in both paths to remind people that Firefox is Free!  so they don't fee uneasy when they see the download offer (and package) tossed at them.  Some may be dismissing the download because of uneasiness about the offer on the first visit to the page (see ken's research on this), and this could be still another source of over counting.
Agreed about "free" being an important thing to remind people about. I'd update the text to something like:

 It looks like you already have the latest version of Firefox,  
  but if you need another copy to share with others or reinstall, 
  click here for the free download.
It feels like we should be doing the detection + changes on download buttons, instead of download.html.  

In the case that a user has the latest version, the download button could be modified, less prominent or hidden, so that they never even click on the button in the first place.  We could make new use of this space, e.g. promote add-ons

With the current proposal, if a user has the latest version, and wants to download a build anyway, they're clicking a download button, then we're making them click it again (essentially)  That seems like a weird UX

For the second over-count point, I think we could find a way to prevent auto-starting an unintentional download when a tab is restored.  Maybe by redirecting, or some javascript magic.  Not sure of the specifics yet.

Otoh, is there any way to tell partial downloads from complete ones while collecting metrics?  We can squash these types of cases, but that would really get to the root of the problem.
(In reply to comment #13)
> 
> For the second over-count point, I think we could find a way to prevent
> auto-starting an unintentional download when a tab is restored.  Maybe by
> redirecting, or some javascript magic.  Not sure of the specifics yet.
> 
> Otoh, is there any way to tell partial downloads from complete ones while
> collecting metrics?  We can squash these types of cases, but that would really
> get to the root of the problem.

I think there are two problems we are trying to solve.  One is the over counting in the metrics system, and the second is getting rid of the annoying download dialogs for users in cases where they aren't making sense.

I think some version detection and suggestion in comment 11 does both.
As I commented over in the other bug we should also try and make the code as generic and easy for other sites to copy and use as possible....


>> chris hofmann      2010-01-04 15:03:44 PST

I notice this same behavior on 

http://get.adobe.com/flashplayer/thankyou/?installer=Flash_Player_10_for_Mac_OS_X

when I updated flash.

If you leave these auto downloader pages open after downloading and starting a
plugin install, you will also get another download when the browser session is
restored after the plugin installation completes.
did we fix this for 4.0?

looks like we are over counting downloads again when compared to ADU growth, and there seems to be some unexplained diff between glow and pentaho downloads

date   adu 
       increase
	        4.0 ADU	
                        daily downloads pentaho	
                                        total downloads pentaho	 
                                                           total downloads glow
3/26                                                            30000000
3/25  2200429	13205837	5939083	        15021731	24000000
3/24  3840682	11005408	9082648	        16473339	18000000
3/23  2156275	 7164726        7390691	        10320514	12000000
3/22  1351108	 5008451        2929823	         3164876         6000000
3/21   396130	 3657343         235053		                 

anyone know whats going on?
We know we have a growing problem with gaming of the download counter. We have put filters in for certain user agent strings and for certain IPs. We have a more comprehensive filter system going in early next week.
As far as the pentaho dashboard goes, two issues:
1. It doesn't have the exact same set of filters the glow site uses. This will cause it to be slightly higher than the same subset of data on glow.
2. By default, the dashboard only shows manual downloads, not AUS initiated ones.  In the lower left, there is a multi-select filter so you can include all downloads to match glow.
yeah, I suspect some gaming, but site that directly links to

http://www.mozilla.com/en-US/products/download.html?product=firefox-4.0&os=osx&lang=en-US

or any user that downloads from an older firefox release, 
then restarts with that open tab to that page they downloaded from, 
will initiate a hit to the counter until we have fixed this problem.

we could probably figure out the size of the linking problem by looking at referers to that url.

we might be able to tell the the size of the later problem by seeing a lack of referal in the logs since that's just a page load in a restored tab at startup.
I can see this user navigation pattern in the crash data too when users hit some of our migration incompatibility start up crashes upon installing and launching 4.0 for the first time, or then they try a re-start to solve the problem.

Firefox 4.0 user
crashes 3 seconds after start
Last Crash	5 seconds before submission
Install Age	35 seconds since version was first installed.

with signature
mozalloc_abort(char const* const) | NS_DebugBreak_P | nsCycleCollectingAutoRefCnt::decr(nsISupports*)  -- one of our high ranking startup crashes on 4.0 

reported url out of the history that shows up in the crash reports is:

http://www.mozilla.com/en-US/products/download.html?product=firefox-4.0&os=win&lang=en-US

see some examples at:

https://crash-stats.mozilla.com/report/index/ad13f30d-b9d7-4bf3-afec-7be002110325

https://crash-stats.mozilla.com/report/index/06497192-70fa-40c9-bb45-c60252110325
I'm not sure how we should address this issue. Any suggestions?
comment 11 has a suggested solution.
(In reply to comment #21)
> comment 11 has a suggested solution.

That would have the unfortunate side-effect of requiring the manual click even after someone who visits mozilla.com and has clicked the Download button to intentionally download a new copy.

Perhaps we could combine the solution in comment 11 with a referrer-check. Something like this:

 If you have no referrer (* see note below)
  AND
 You have the latest version installed
 Then show the text from comment #11

* If there is no referrer, you probably didn't click just a green download button on mozilla.com. No referrer would probably mean:
a) opened the page as part of a restored session (which is the pertinent issue for this bug)
b) copy/pasted the URL into the location bar
c) clicked on a link from an external app (email, IM app, twitter client, etc.)

Are there any other common reasons why there would be no referrer that I'm not thinking of?
Bookmark
Private Browsing Mode
Some other Referrer masking config


In all of the cases listed so far, my opinion is that it is worth having the user go through an extra click since we have evidence that a lot of these download requests are unintentional.
Anyone know if we can reliably check the referrer and not have the results be clobbered by CDN/caching?
I'm not sure I'm following along here.

comment 11 is user agent check.  the intent here is that:

if the user doesn't have firefox 4 (or what ever the latest version) the auto download would start and they would show content just as happens now.

if the user already has firefox 4 installed, then they would get shown a page that would all allow them to click and get the download, but the auto initiated download would not happen.
Kohei, has also explained how this kind of set is already working on mozilla.jp
The new report that daniel is working on the shows new active installs from blocklist pings helps to provide a sense of how far our download numbers may be off.   pentaho reports around 2 million downloads per day for firefox 4 over the last few day, but we only see around 900k newly activated installs.

               downloads   new_active_instals

2011-04-19	2,109,852  865079   41%
2011-04-20	2,062,811  924650   44%
2011-04-21	1,972,125  867022   43%
I'm not at all surprised by that. We've always known that we lose a lot of people between download and a running install. http://blog.mozilla.com/metrics/2007/11/02/firefox%E2%80%99s-funnel-factor/
Sorry, I meant to add that this probably says very little about the accuracy of our download numbers. We know we lose lots of people who never even locate the downloaded file or fail to complete the installer or can never again locate Firefox after the first run. Unless we can control for those, our blocklist pings don't tell us anything about our downloads.
> We know we lose lots of people who never even locate the
downloaded file....

removing this source of error and annoyance helps us to get a better handle on exactly how many people run into those kind of problems, and how many people are initiating unintentional downloads.  right now its all speculation about what the buckets look like but my guess is that we are trading off one extra click for hundreds of users that want an extra download v. hundreds of thousands of clicks for users that are doing multiple clicks to clean up after the unintended downloads.

I'm also not sure if I understand the theory behind the extra click to get an extra download for a friend.  why wouldn't the helper just download directly on to the friends machine, or just use the download they already used for their install to throw on the USB key?   If we had some kind of unique license key on each installer, or the installer could only be used once this might make sense, but we don't.
we will get another chance to get some more data on this with the release of firefox 9 when we separate the push to the website and the push to the update system come as separate events.

laura forrest also mentioned at a recent mozcamp that she had some additional survey data from users that hit this page with an up-to-date version and responded that what they were trying to do was to download which would still be confusing to me.  Depending on which side of the download and installation process they were on, and more intimate knowledge of how the update system works I can also see how users might not be giving clear responses about what they are doing, or what they think they need to do, to complete an update that we offer them.

with partial or full silent updates we might also see the spike in downloads around the rapid releases disappear as well.

Its clear we still see spikes in downloads around relase dates and I image some of these are the result of users getting auto-update notices, getting confused, and doing manual downloads and duplicating the update effort.  here is a 10 day profile on either side of the last firefox release.

10/30/11	1771694
10/31/11	2029967
11/01/11	2054067
11/02/11	2056000
11/03/11	2048503
11/04/11	1997188
11/05/11	1813660
11/06/11	1794862
11/07/11	2032688
11/08/11	2490522
11/09/11  3888932
11/10/11  4419063
11/11/11  3723410
11/12/11   3035582
11/13/11     2804500
11/14/11   3082277
11/15/11     2884984
11/16/11       2724359
11/17/11	2586004
11/18/11	2454765
11/19/11	2184126
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
While the download experience for new users has improved, this is still valid.
Component: General → Information Architecture & UX
Depends on: 883801
Bug 883801 has changed the download experience for existing Firefox users. And it's working well in most cases. I think we can mark this bug fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: