tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 8ff2149da299371b8e7d69b6f9ac6c98c35cbb70..9692b21a7a959cda3c43ceb657892b9f60d68ec4 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -19052,6 +19052,39 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   </summary>
 </histogram>
 
+<histogram name="PasswordManager.SyncAccountWithoutPasswordsTimesUsed">
+  <owner>gcasto@chromium.org</owner>
+  <owner>vabr@chromium.org</owner>
+  <summary>
+    Number of times a users has used the password for their sync account. Note

[Ilya Sherman, 2014/06/27 21:40:50]

nit: "a users" -> "a user"

+    that this histogram only tracks users that are enrolled in sync, but not
+    password sync. Recorded on browser startup. Any usage before M29 is not
+    included. Any usage before M36 may not be properly accounted if it was on a
+    different profile.

[Ilya Sherman, 2014/06/27 21:40:49]

So, this tracks the number of times the user has ever used this password, across
all of time?  That seems like something of a strange thing to track, especially
since there's no accommodation for how long the user has been using Chrome. 
Note also that any metrics recorded on startup bias towards users who relaunch
Chrome more frequently.

I think it would be good to try to clarify what your baseline for this metric
is, and then try to design the histogram to include the baseline.  For example,
perhaps you're interested in comparing the total number of Gaia logins to the
number of Gaia logins with the synced account's password (but presumably only
for users who are using Sync).  Or, perhaps you're interested in measuring a
rate of use, i.e. how many times per week was a synced account's password used? 
(Note, though, that measuring a rate is much harder to do without introducing
bias.)

Incidentally, this histogram <summary> does not currently make this clear, but I
think you're measuring the number of times the password was autofilled -- is
that true?  Perhaps what you want to compare is the frequency with which a Sync
account's password is autofilled vs. entered manually?

[Garrett Casto, 2014/06/27 22:33:20]

By "using Chrome" are you talking about passwords that were imported from other
browsers? We don't start tracking this until after the password is saved in
Chrome, so that's not an issue. It's true that this doesn't take into account
how many of those usages happened when the user was syncing vs. before they were
syncing. I was trying to be conservative and possibly over count because it's
still going to be a pain point for users if they only use this password every
few months, which we might not see if we only pay attention to logins from this
point on.

As for the bias, we had talked about solving this on the server side before, but
it doesn't look like there has been any movement on that. Are there any better
ways that you can think of to remove this bias, short of trying to report only
once per day (which we've already decided is pretty painful)?
I think that there are two questions we want answered.

1) What percentage of the population would be affected by not autofilling sync
credentials
2) How painful would this be for that group of users.

1) should be answered by SyncingAccountState (modulo reporting biases), so this
is trying to answer 2). My assumption was that any time a user loses this
ability it's going to be a pain point. That is, it's not clear to me that it
matters what percentage of logins are affected so much as total number.
Measuring a rate might be interesting, though that requires syncing additional
metadata about when logins occur. You could also accomplish this server side
with appropriate logs analysis I suppose.
It's actually how often it's autofilled and then successfully submitted. I can
update the histogram once we've finalized what's going on here. As for the later
point, if the user has their password saved but is still typing it, either we
have a bug somewhere or they are changing their password. It's not obvious to me
that paying attention to password change is useful for answer the questions that
we have, but I haven't thought about it to much. Maybe it's useful to know
because if the rate is high then users will be less likely to be upset if they
end up locked out because they already reset their password a lot? Not sure.

[Ilya Sherman, 2014/06/27 23:24:54]

I mean that a user who just started using Chrome last week will, on average,
have fewer Gaia logins than a user who's been using Chrome for a year, assuming
the two users log in equally often.  So, measuring total logins across all time
seems weird for this reason.
It's pretty hard to entirely remove bias, but you can typically reduce it by
picking a baseline for your metric, and then sampling both the metric and its
baseline at the same time.  Absolute numbers are very hard to interpret
properly.  Relative metrics are much easier to work with.
I guarantee you that the absolute number will be nonzero.  How do you evaluate
whether an absolute number is significant or not?  I claim that you'll need to
decide in the context of some baseline metric.
Well, a Sync user might have their password saved, or they might not.  The
manual case would apply if they do not.

+  </summary>
+</histogram>
+
+<histogram name="PasswordManager.SyncAccountWithPasswordsTimesUsed">
+  <owner>gcasto@chromium.org</owner>
+  <owner>vabr@chromium.org</owner>
+  <summary>
+    Number of times a user has used the password for their sync account if they
+    are syncing passwords. Recorded on browser startup. Any usage before M29 is
+    not included. Usage before M36 may not be properly accounted if it was on a
+    different profile.
+  </summary>
+</histogram>
+
+<histogram name="PasswordManager.SyncingAccountState"
+    enum="PasswordManagerSyncingAccountState">
+  <owner>gcasto@chromium.org</owner>
+  <owner>vabr@chromium.org</owner>
+  <summary>
+    Information about the user's current sync status crossed with if their
+    synced password is saved or not.
+  </summary>
+</histogram>
+
 <histogram name="PasswordManager.TimesGeneratedPasswordUsed">
   <owner>dubroy@chromium.org</owner>
   <owner>vabr@chromium.org</owner>
@@ -43255,6 +43288,20 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   <int value="2" label="Match"/>
 </enum>
 
+<enum name="PasswordManagerSyncingAccountState" type="int">
+  <summary>
+    The value is a combination of the current sync state and if the user has
+    their sync password saved.
+  </summary>
+  <int value="0" label="User is not syncing."/>
+  <int value="1"
+      label="Not Syncing/Pasword saved. This value should not happen."/>
+  <int value="2" label="Syncing without passwords/Sync password not saved"/>
+  <int value="3" label="Syncing without passwords/Sync password saved"/>
+  <int value="4" label="Syncing with passwords/Sync password not saved"/>
+  <int value="5" label="Syncing with passwords/Sync password saved"/>
+</enum>
+
 <enum name="PasswordManagerUIDismissalReason" type="int">
   <int value="0" label="Bubble lost focus / No infobar interaction"/>
   <int value="1" label="Clicked 'Save'"/>