Closed Bug 845603 Opened 11 years ago Closed 11 years ago

Categories

(www.mozilla.org :: Analytics, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wbowden, Assigned: sancus)

References

(Blocks 1 open bug, )

Details

(Whiteboard: r=114231,114415)

Attachments

(1 file)

Hi, 

The link below redirects from moz.org to Google Play.  It's an important link for tracking referrals from about:home to GP.  Could we update the tracking on this from Webtrends to Google Analytics:

https://www.mozilla.org/mobile/android-download.html

Thanks!
Cmore:  is this related to the larger question about tracking Android downloads?
Summary: Update Google Play link to Google Analytics → Update https://www.mozilla.org/mobile/android-download.html to use Google Analytics
(In reply to jbertsch from comment #1)
> Cmore:  is this related to the larger question about tracking Android
> downloads?

Yes, if we had Google Play store and Android install analytics, we would not need this redirect page. I don't think that is going to happen anytime soon, so we need to get GA on this page. It is super easy and I will find the code.
Jess will keep Webtrends tags on her emails that point to android downloads until this bug is resolved. When this is resolved, she can switch them to UTM tags.
sancus: this should be a quick change as I described in comment 3. famous last words?
Assignee: nobody → sancus
Assignee: sancus → booboobenny+bugzilla
Both urls use a 0 delay metarefresh. For testing you can use something like wget or block the refresh with a browser plugin.

https://www-dev.allizom.org/en-US/mobile/android-download.html
https://www-dev.allizom.org/en-US/mobile/android-download-beta.html

Everything looks OK to me.
Whiteboard: r=114231 qawanted
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
wget --no-check-certificate https://www-dev.allizom.org/en-US/mobile/android-download.html

<html>
  <head>
    <script>
var _gaq = _gaq || [];
var pluginUrl = '//www.google-analytics.com/plugins/ga/inpage_linkid.js';
_gaq.push(['_require', 'inpage_linkid', pluginUrl]);
_gaq.push(['_setAccount', 'UA-36116321-1']);
_gaq.push(['_setAllowLinker', true]);
_gaq.push(['_setAllowAnchor', true]);
_gaq.push(['_trackPageview']);
(function() {
    var ga = document.createElement('script');
    ga.type = 'text/javascript';
    ga.async = true;
    var prefix = ('https:' == document.location.protocol ? 'https://ssl' :
                  'http://www');
    ga.src = prefix + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(ga, s);
})();
</script>
    <meta http-equiv="refresh"
          content="0; url=https://play.google.com/store/apps/details?id=org.mozilla.firefox">
  </head>
  <body>

  </body>
</html>
I am slightly worried that we may lose some GA requests because of the meta refresh 0. It may not be enough time for GA to execute before leaving the page. Would anyone support changing it to 1?
Whiteboard: r=114231 qawanted → r=114231
Was this a problem with the webtrends implementation?
(In reply to Ben (:bensternthal) from comment #10)
> Was this a problem with the webtrends implementation?

Yes, and it is why Winston would use bit.ly links pointing to this page to get cleaner click data.
I pushed the google analytics additions live. Are we sure that 1 second is enough additional time to make sure the GA stuff works? Capturing a slightly bigger but still entirely random percentage of visitors to that url won't necessarily *improve* our numbers...
Are we at a point where I can start using GA for this URL?  And if so, should I keep using bit.ly in conjunction with GA until we're sure the data is accurate?
(In reply to Andrei Hajdukewycz [:sancus] from comment #12)
> I pushed the google analytics additions live. Are we sure that 1 second is
> enough additional time to make sure the GA stuff works? Capturing a slightly
> bigger but still entirely random percentage of visitors to that url won't
> necessarily *improve* our numbers...

1 second should be suffice. GA recommends 500ms.
(In reply to Winston Bowden from comment #13)
> Are we at a point where I can start using GA for this URL?  And if so,
> should I keep using bit.ly in conjunction with GA until we're sure the data
> is accurate?

Winston, please update this bug when you start using GA so we can close it. Thanks
(In reply to Winston Bowden from comment #13)
> Are we at a point where I can start using GA for this URL?  And if so,
> should I keep using bit.ly in conjunction with GA until we're sure the data
> is accurate?

Yes, you can now start to use GA tagging on this page. Use this page to build the URL:

http://support.google.com/analytics/bin/answer.py?hl=en&answer=1033867

You will end up with something like this:

https://www.mozilla.org/en-US/mobile/android-download.html?utm_source=about-home&utm_medium=snippet&utm_campaign=android-snippet-apr-2012

I'm CC'ing Gareth, the new Analytics person at Mozilla.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Snippets have been updated with the GA links.
(In reply to Winston Bowden from comment #17)
> Snippets have been updated with the GA links.

Can you post a few links here so we can review?
sancus: let us know when the change to 1 seconds is put into production. Thanks!
Looks good to me! We will probably get better data once it is changed to one second delay. You can find the campaign data in the "Google Analytics" > Traffic Sources > Sources > Campaigns.
Whiteboard: r=114231 → r=114231,114415
live in r114418
Verified the 1 second is in production. Thanks!
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
thanks all
Status: RESOLVED → VERIFIED
I noticed that utm campaign params do not get passed forward to the play store url upon re-direct. 

Can we please append any query strings within the original url to the play store url upon re-direct? 

Example

Original that gets redirected: 
https://www.mozilla.org/en-US/mobile/android-download.html?utm_source=snippet&utm_medium=snippet

New Play URL with Parameters Appended: 
https://play.google.com/store/apps/details?id=org.mozilla.firefox&utm_source=snippet&utm_medium=snippet

Thanks.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Sancus: Can you check this out?
Flags: needinfo?(sancus)
We can't simply echo the query string because that will introduce XSS and CSRF attack vectors at the least, so....

What format are these campaign tags that we are trying to pass through? Are they always going to be in a particular variable(like ?utm=) or whatever, what characters will they use?(a-z, 0-9 only?), etc. It's possible to filter this but we need to be pretty restrictive.
Flags: needinfo?(sancus)
Flags: needinfo?(chrismore.bugzilla)
+1 on not echoing out the request parameters. The only ones we care about are:

utm_source
utm_medium
utm_term
utm_content
utm_campaign

Example:

https://www.mozilla.org/mobile/android-download.html?utm_source=snippet&utm_medium=snipper_banner&utm_campaign=acme123
Flags: needinfo?(chrismore.bugzilla)
Assignee: booboobenny+bugzilla → sancus
Attachment #751946 - Flags: review?(pmac)
If we can use these utm_* args from the play store, then why do we still need this page? This seems like a very error prone technique that will likely result an a security hole.

1. It seems very un-mozilla to be degrading the user experience for tracking
2. We have bit.ly for this kind of thing. They're very good at it.

Can we just delete this redirect page?
That would indeed be vastly preferable.
(In reply to Paul McLanahan [:pmac] from comment #31)
> If we can use these utm_* args from the play store, then why do we still
> need this page? This seems like a very error prone technique that will
> likely result an a security hole.
> 
> 1. It seems very un-mozilla to be degrading the user experience for tracking
> 2. We have bit.ly for this kind of thing. They're very good at it.
> 
> Can we just delete this redirect page?

Sam: We need your input here. Are you find with GA UTM tags pointing directly at the Play Store and using bit.ly links? Do you even need this interstitial page anymore?
Flags: needinfo?(smott)
adding to mozilla.org kanban board - >research and design
Priority: -- → P3
I am going to close this bug. We should either just re-make this page in bedrock or just point links directly to the play store. Will reach out to Winston and Sam about what they want to do. Most links to this page are coming from snippets.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Flags: needinfo?(smott)
Resolution: --- → FIXED
Comment on attachment 751946 [details] [diff] [review]
utm passthrough code

Review of attachment 751946 [details] [diff] [review]:
-----------------------------------------------------------------

We've decided not to do this. r- just to remove the flag.
Attachment #751946 - Flags: review?(pmac) → review-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: