Add UMA stat to track home button and page prefs

Add UMA stat to track home button and page prefs

BUG=262954
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=213472

[Ken Rockot(use gerrit already), 2013-07-22 18:46:23]

PTAL

I think we really only want to track this when a profile is loaded. Maybe
there's a better place for this to live though?

[bbudge, 2013-07-22 20:03:49]

On 2013/07/22 18:46:23, rockot wrote:
> PTAL
> 
> I think we really only want to track this when a profile is loaded. Maybe
> there's a better place for this to live though?

Yes, we should collect once per profile is loaded. It's tricky to find the right
point to collect. I would recommend reading existing code that needs the
information and working back from there to find where the information is
actually loaded and stable.

[Mark P, 2013-07-22 20:08:31]

Here's another function with histograms get get emitted once per profile
load.  Perhaps you can trace back to find a common point?

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/sea...


On Mon, Jul 22, 2013 at 1:03 PM, <bbudge@chromium.org> wrote:

> On 2013/07/22 18:46:23, rockot wrote:
>
>> PTAL
>>
>
>  I think we really only want to track this when a profile is loaded. Maybe
>> there's a better place for this to live though?
>>
>
> Yes, we should collect once per profile is loaded. It's tricky to find the
> right
> point to collect. I would recommend reading existing code that needs the
> information and working back from there to find where the information is
> actually loaded and stable.
>
>
https://codereview.chromium.**org/19776015/<https://codereview.chromium.org/1...
>

[Ken Rockot(use gerrit already), 2013-07-22 23:21:04]

Stats collection stuff is moved into a BrowserContextKeyedService and poked at
browser startup; this guarantees one record per profile load.

[bbudge, 2013-07-23 00:56:25]

This looks like it will be a good place to track prefs. Are we concerned that
these might not reflect the actual settings once the DB and perhaps sync have
modified them? I'm thinking of default search engine, where the prefs value can
be overridden later in  TemplateURLService::EnsureDefaultSearchProviderExists().

[Ken Rockot(use gerrit already), 2013-07-23 15:43:24]

On 2013/07/23 00:56:25, bbudge1 wrote:
> This looks like it will be a good place to track prefs. Are we concerned that
> these might not reflect the actual settings once the DB and perhaps sync have
> modified them? I'm thinking of default search engine, where the prefs value
can
> be overridden later in 
TemplateURLService::EnsureDefaultSearchProviderExists().

For now we just want to track the state of the profile when it loads locally.
The question of out-of-sync prefs is also interesting, but it's a separate issue
with slightly lower priority. PrefMetricsService can be extended later to
accommodate it.

[bbudge, 2013-07-23 17:03:30]

On 2013/07/23 15:43:24, rockot wrote:
> On 2013/07/23 00:56:25, bbudge1 wrote:
> > This looks like it will be a good place to track prefs. Are we concerned
that
> > these might not reflect the actual settings once the DB and perhaps sync
have
> > modified them? I'm thinking of default search engine, where the prefs value
> can
> > be overridden later in 
> TemplateURLService::EnsureDefaultSearchProviderExists().
> 
> For now we just want to track the state of the profile when it loads locally.
> The question of out-of-sync prefs is also interesting, but it's a separate
issue
> with slightly lower priority. PrefMetricsService can be extended later to
> accommodate it.

The reason I'm bringing this up is that I tried hacking my Preferences file and
found that Chrome would temporarily set my DSE to what was in Prefs but later
would over write it with the local DB setting. So I'm wondering if our stats
might be significantly different if we only report Prefs, at least for DSE and
Homepage URLs.

[Ken Rockot(use gerrit already), 2013-07-23 20:00:56]

+battre to have a look too

After talking with Erik, it sounds like it's best to start as simple as possible
and only worry about the prefs file on our first pass. We can incrementally dig
deeper from there.

[bbudge, 2013-07-23 20:05:57]

LGTM

[Ken Rockot(use gerrit already), 2013-07-23 21:32:06]

+jochen for browser main change

[Mark P, 2013-07-23 21:35:49]

Forgive my naiveté.  Is this recorded on startup and/or when a new profile
is opened?  Also, does it handle opening multiple profiles at startup (as
in restore from where I left off, if I had multiple profiles open)?

I ask these questions because I'm probably going to be the guy who looks
most at these logs.

--mark



On Tue, Jul 23, 2013 at 2:32 PM, <rockot@chromium.org> wrote:

> +jochen for browser main change
>
>
https://codereview.chromium.**org/19776015/<https://codereview.chromium.org/1...
>

[Ken Rockot(use gerrit already), 2013-07-23 21:47:29]

On 2013/07/23 21:35:49, Mark P wrote:
> Forgive my naiveté.  Is this recorded on startup and/or when a new profile
> is opened?  Also, does it handle opening multiple profiles at startup (as
> in restore from where I left off, if I had multiple profiles open)?

These are recorded once for each created BrowserContext, so essentially once per
unique profile load per browser session. Multiple profiles (on startup or
otherwise) are covered.

[Mark P, 2013-07-23 22:05:35]

histograms.xml lgtm
(baring the one comment below)

https://codereview.chromium.org/19776015/diff/7001/tools/metrics/histograms/h...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/19776015/diff/7001/tools/metrics/histograms/h...
tools/metrics/histograms/histograms.xml:3890: Whether or not the home page user
preference is set to the default NTP
please fix the spacing

[meacer, 2013-07-23 22:54:52]

LGTM

[battre, 2013-07-24 13:08:06]

lgtm

[jochen (gone - plz use gerrit), 2013-07-24 13:09:01]

lgtm

[bbudge, 2013-07-24 14:19:01]

https://codereview.chromium.org/19776015/diff/23001/tools/metrics/histograms/...
File tools/metrics/histograms/histograms.xml (right):

https://codereview.chromium.org/19776015/diff/23001/tools/metrics/histograms/...
tools/metrics/histograms/histograms.xml:3881: <histogram
name="HomePage.IsHomeButtonEnabled" enum="BooleanEnabled">
It might be convenient to view all of these histograms on a single dashboard.
Could we name them with a common prefix, like 'Prefs' or 'Settings'? So these
two names would be:

Settings.IsHomeButtonEnabled
Settings.IsHomePageNewTabPage

Then I could name the search URL histograms:

Settings.DefaultSearchEngine
Settings.HomePageURL

etc.

[commit-bot: I haz the power, 2013-07-24 14:37:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rockot@chromium.org/19776015/32001

[commit-bot: I haz the power, 2013-07-24 18:34:18]

Change committed as 213472