Closed Bug 826804 Opened 13 years ago Closed 12 years ago

[Google Analytics] Track "ShowFor" switcher usage in Google Analytics

Categories

(support.mozilla.org :: General, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED
2013Q1

People

(Reporter: ibai, Assigned: rrosario)

References

Details

(Whiteboard: u=sumo-team c=analytics p=2 s=2013.2)

We want to track how often the user agent switcher is used in the Support site. The easiest way of doing this is by generating events anytime somebody uses one or the other. My recommendation is to execute the following events when a user changes the OS or the Firefox version. For the OS dropdown: _gaq.push(['_trackEvent', 'UA Switch', 'OS', $article_slug]); For the Fx version dropdown: _gaq.push(['_trackEvent', 'UA Switch', 'Fx Version', $article_slug]); More detailed documentation about GA events can be found here: https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide
We should not call this thing the user agent, because it's not. It's initial values are guessed based on the user's UA, but when the user changes the OS or Fx Version selectors, the UA stays constant. I think this is better named 'ShowFor Switch'. We can't control the user's UA.
Summary: [Google Analytics] Track User Agent switcher usage in Google Analytics → [Google Analytics] Track "ShowFor" switcher usage in Google Analytics
Going conservative an making this a 2pter as we don't have experience doing this before.
Assignee: nobody → rrosario
Priority: -- → P2
Whiteboard: u=sumo-team c=analytics p=2 s=2013.2
Target Milestone: --- → 2013Q1
(In reply to ibai from comment #0) > My recommendation is to execute the following events when a user changes the > OS or the Firefox version. Do we just want to track the event once per page view? Or do we want to track each time they change the selection on one page view?
Flags: needinfo?(ibai)
We should track all the instances, Analytics will help us understand how many visitors use it and how many times per pageview. Also, it should be easier to implement, correct? Meaning, not keeping track if it's the first time or not.
Flags: needinfo?(ibai)
(In reply to ibai from comment #4) > Also, it should be easier to implement, correct? Meaning, not keeping track > if it's the first time or not. Yeah, it is slightly easier probably. But I just wanted to be sure. Thanks!
(In reply to ibai from comment #0) > For the OS dropdown: > > _gaq.push(['_trackEvent', 'UA Switch', 'OS', $article_slug]); > > For the Fx version dropdown: > _gaq.push(['_trackEvent', 'UA Switch', 'Fx Version', $article_slug]); Thge forth parameter needs to be an int so this won't work. We could put all the info in the 3rd parameter. But I assume the event would be tied to the page they are on by GA automatically?
I propose the following: _gaq.push(['_trackEvent', 'ShowFor Switch', 'Version - <version selected>']); For example: _gaq.push(['_trackEvent', 'ShowFor Switch', 'Version - m17']); _gaq.push(['_trackEvent', 'ShowFor Switch', 'Version - fx19']); _gaq.push(['_trackEvent', 'ShowFor Switch', 'OS - android']); _gaq.push(['_trackEvent', 'ShowFor Switch', 'OS - win7']);
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #6) > (In reply to ibai from comment #0) > > For the OS dropdown: > > > > _gaq.push(['_trackEvent', 'UA Switch', 'OS', $article_slug]); > > > > For the Fx version dropdown: > > _gaq.push(['_trackEvent', 'UA Switch', 'Fx Version', $article_slug]); > > The forth parameter needs to be an int so this won't work. We could put all > the info in the 3rd parameter. But I assume the event would be tied to the > page they are on by GA automatically? Nevermind, the docs are a bit confusing. It seems you can add as many string and/or int parameters as you want. So how about: _gaq.push(['_trackEvent', 'ShowFor Switch', '<Version or OS>', '<version or os selected>', '<article slug>']);
GAH! Scratch comment 8. I hate these docs. Let's use this syntax better: _trackEvent(category, action, opt_label, opt_value, opt_noninteraction) So we can do, for example: _trackEvent('ShowFor Switch', 'Version - m18', 'download-and-install-firefox-android') _trackEvent('ShowFor Switch', 'OS - winxp', 'update-firefox-latest-version') Does that work for you?
Also, keep in mind that slug isn't unique. You need locale+slug to get unique document.
The more information the better. So yes, it works! Also, if we can keep the slug in English and add the locale, that will be neat...I don't foresee any usage of knowing the article and the locale, but is better to collect that data know and not regret in 6 months that we didn't. Thanks for putting it together.
Talking to Ibai, we decided on: _trackEvent('ShowFor Switch', 'Version - m18', 'download-and-install-firefox-android / en-US') _trackEvent('ShowFor Switch', 'OS - winxp', 'update-firefox-latest-version / pt-BR')
That last parameter is '<en-US slug> / <current locale>'
I tried to deploy, but I think we are having deployment issues. Leaving this open for now.
This is working on prod now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Data is being collected. Surprisingly (I wasn't expecting a big usage), the switches are used 5000 times a day for OS changes and around 4000 times for Version changes.
Status: RESOLVED → VERIFIED
Yeah, that's definitely more than I had expected, but even 5000 times a day are only 0,8% of /kb/ visits. Still, it might be worth figuring out why people are using the switched. From the data it looks like this is happening most often on pages that are related to updates of Firefox or plugins and pages where we say that we have stopped supporting certain versions. Might be that people think they can update their browser/addon/OS by using the selector. I'd suggest we do a quick survey that triggers when people use the switcher. What do you think, Ibai?
As discussed, yes, it seems that there's some confusion around this switches that is particularly evident in the updating articles. Let's open another bug to investigate what's going on and move the conversation forward there.
You need to log in before you can comment on or make changes to this bug.