Add some histograms to see how often users click through blocking pages....

Add some histograms to see how often users click through blocking pages.

R=jar


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=14569

[jar (doing other things), 2009-04-25 07:35:30]

Although you can indeed get away with putting each stat in its own histogram (as
you did in this CL), I think it would be much more readable if you had a linear
histogram, with 3 buckets, each of which recorded a click in one of the
categories. This way you'll have comparative numbers right next to each other.

The nicest example is the implementation of Net.HadConnectionType and
Net.ConnectionTypeCount (although their names are probably not perfect).  The
critical point is you too probably want both an actual tally of clicks, as well
as the number of sessions in which a user clicked each type of box.  Take a look
in net/base/connection_type_histograms.cc:
for the details.

[jim.roskind, 2009-04-26 22:59:31]

LGTM...  but...

These events are in general pretty rare.  If you consider the bias introduced
when a user hits one of these pages, and then tries it again a few times to see
if it was real... and then demos it to a friend.... you may want absolute count,
and well as thte "number of sessions" this happened in.  Since I think it is
unlikely that a single user will visit multiple sites (unless they are working
with the site, etc.), it is probably interesting to see the number of sessions
that use each of these (as well as what you are currently gathering, which is
the number of times these UI actions take place).

The nicest example is the implementation of Net.HadConnectionType and
Net.ConnectionTypeCount (although their names are probably not perfect).  The
critical point is you probably want both an actual tally of clicks, as well as
the number of sessions in which a user clicked each type of box.  Take a look in
net/base/connection_type_histograms.cc for the details.

[abarth-chromium, 2009-04-26 23:34:56]

That's a good point.  I'm inclined to land this as-is for now.  We can look at
the results from the dev channel and then iterate on exactly what data we'd like
to collect.  At this point I'm curious how the CTR rates compare for SSL errors
vs. Safe Browsing errors.

[jar (doing other things), 2009-04-27 00:20:48]

OK.... pushing out a histogram soon would be a good thing, as you'll get data
and can go from there.  

I just realized one tiny change I'd suggest, and you can make it or not, the
LGTM is sticky ;-).

Be sure to look at your results using 
about:histograms
to be sure you're getting what you'd expect.  If you're having trouble
instigating the events, you can always use the debugger to at least force some
path's to be taken, and then make sure the histograms look fine.

http://codereview.chromium.org/99020/diff/11/1016
File chrome/browser/safe_browsing/safe_browsing_blocking_page.cc (right):

http://codereview.chromium.org/99020/diff/11/1016#newcode62
Line 62: static LinearHistogram histogram("interstial.safe_browsing", 0, 2, 4);
Looking at the unit test, and other examples, the more common set of numbers
(for min, max, count) would be:

1, N, N+1

In this case, perchance:

1, 3, 4 would be best.

Also note, that it is good to leave one additional bucket unused, as buckets are
defined as having a min and max value.  Hence the "top bucket" is always "N no
infinity".  This can cause problems if you later decide to add another bucket,
and then you have a distinct "N to N+1" and "N to infinity" coming from
different flavors of the histogram.