859557 - Change /firefox/all/ download links to /download page instead of d.m.o

Status: RESOLVED WONTFIX

(www.mozilla.org :: Pages & Content, defect, P2)

Description

[Chris More [:cmore]]

On this page:

http://www.mozilla.org/en-US/firefox/all/

The download links point to URLs like:

http://download.mozilla.org/?lang=en-US&product=firefox-20.0&os=win

The links should be pointing to mozilla.org instead of DMO like:

https://www.mozilla.org/en-US/products/download.html?product=firefox-20.0&os=win&lang=en-US

Why?

Because, there is no Web Analytics on download.mozilla.org and thus we cannot add conversion goals or download instructions for these users. If we pointed the users to /products/download.html, the save-as would pop up on the subsequent page and also download instructions would show.

The only other option is to fire off a GA virtual page view for:

/[locale]/products/download.html?product=[build]&os=[os]&lang=[locale]

Is there a compelling reason to keep these links pointing to d.m.o?

Comment 1

[raymond [:retornam] (inactive)]

(In reply to Chris More [:cmore] from comment #0)
> On this page:
> 
> http://www.mozilla.org/en-US/firefox/all/
> 
> The download links point to URLs like:
> 
> http://download.mozilla.org/?lang=en-US&product=firefox-20.0&os=win
> 
> The links should be pointing to mozilla.org instead of DMO like:
> 
> https://www.mozilla.org/en-US/products/download.html?product=firefox-20.
> 0&os=win&lang=en-US
> 
> Why?
> 
> Because, there is no Web Analytics on download.mozilla.org and thus we
> cannot add conversion goals or download instructions for these users. If we
> pointed the users to /products/download.html, the save-as would pop up on
> the subsequent page and also download instructions would show.
> 
> The only other option is to fire off a GA virtual page view for:
> 
> /[locale]/products/download.html?product=[build]&os=[os]&lang=[locale]
> 
> Is there a compelling reason to keep these links pointing to d.m.o?


We would have to localize  this page https://www.mozilla.org/en-US/products/download.html?product=firefox-20.0&os=osx&lang=en-US ofr all locales if we were to go 
the  /[locale]/products/download.html?product=[build]&os=[os]&lang=[locale] route.


The best option is to track onClick events for each link on this page http://www.mozilla.org/en-US/firefox/all/

Comment 2

[Steven Garrity [:sgarrity]]

(In reply to raymond [:retornam] from comment #1)
> (In reply to Chris More [:cmore] from comment #0)
> > Is there a compelling reason to keep these links pointing to d.m.o?
> 
> We would have to localize  this page
> https://www.mozilla.org/en-US/products/download.html?product=firefox-20.
> 0&os=osx&lang=en-US ofr all locales if we were to go 
> the  /[locale]/products/download.html?product=[build]&os=[os]&lang=[locale]
> route.

Raymond is correct about localizing the download.html page. That said, we're in the process of porting it to bedrock and I would like to see a minimal version of the page in all locales. With the full download instructions and email form available only in locales where we have the resources to localize.

I think we could get the base version of the page down to just two key strings:
1. A "Thank you for downloading..." type title, and
2. A "Your download will start soon, if not..." note.

Comment 3

[Chris More [:cmore]]

What about if we hold onto this bug until we get the new download page ported to bedrock and localized? Currently, when I look at download trends on mozilla.org, the ones originating from /all is not captured. 

Thanks for the input on this and we will revisit it after we are further along with the Bedrock migration.

Comment 4

[Mike Alexis [:malexis]]

Is this bug still valid? Looks like links are still pointing to d.m.o

Comment 5

[Chris More [:cmore]]

It's still valid and let's wait until the universal analytics and tag manager implementation is done. Blocked by bug 1126966.

Comment 6

[Alex Gibson [:agibson]]

(In reply to Chris More [:cmore] from comment #0)
> Is there a compelling reason to keep these links pointing to d.m.o?

This is an old bug and may no longer be relevant, but I would say the biggest reason to keep these links pointing to d.m.o is that it offers users a simple, direct download link using plain old https. Pointing *everything* to /firefox/new/ would create a single point of failure for downloads on the whole site, and is something I would very much like us to avoid for the sake of analytics alone. 

Now that we have the new split template for /firefox/new/, we may also soon move to using /firefox/all/ as a fallback direct download link on scene 2, if things should break for some reason. Doing what's proposed in this bug however would result in a circular fail for those users, as we would be removing all the direct links in the user flow.

We also have automated download link tests set up on these pages to check all the URLs, so it is a valuable way to catch download 404's. Without this, there would be times when downloads for x locales or builds could go broken and unnoticed.

Unless there's a compelling reason why we can't already track these link clicks in GTM (I can't see why not?), I would vote for closing this as wontfix.

Comment 7

[Alex Gibson [:agibson]]

Given Comment 6 was made 11 months ago, I'm going to close this as WONTFIX.