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 1cfa48fbc4b33e07a84cddffee94218413878b39..bf8699d8183738d3d509d1a3822e99abe4e27ef0 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -8073,7 +8073,7 @@ other types of suffix sets.
     counts are the number of discards and the buckets are the number of users.
     Since the count values are absolute numbers, they need to be normalized
     before use - so divide the counts by the percentage of users found under
-    'MultiProfile.UsersPerSession'.
+    'MultiProfile.UsersPerSessionIncremental'.

[Mark P, 2014/03/06 21:36:33]

This was an earlier comment I forgot to publish.  Now publishing for posterity,
though it's somewhat wrong given new information in the changelist description.
----
This instruction about how to normalize these counts isn't right.

It's not even right if you do the math suggested in the description of
MultiProfile.UsersPerSessionIncremental.

For instance, suppose all the world does the following: log in with one user,
log in with another user, log in with another user.  Log out one user.  Now you
have two users.  Then browse the web.

If the world is 100 people, this means that the
MultiProfile.UsersPerSessionIncremental histogram will see 100 single user, 100
two-user, and 100 three-user.  The math will say 0 single-user sessions, 0
two-user sessions, 100 (= 100%) three-user sessions.

Now suppose some of the browsing causes discarded tabs.  These will all get put
in the two-user bucket for MultiProfile.DiscardedTabsPerUser.  There is no way
to normalize this based on the 0% of user we infer are in the two-user state.


This is no way to correct this mathematically.  It's a consequence of when
MultiProfile.UsersPerSessionIncremental.

Are you have a use for the MultiProfile.DiscardedTabsPerUser histogram without
this normalization instructions?  If not, then I advise you to remove it.  If
so, then keep it, but at least get rid of the incorrect normalization
instructions.

[Mr4D (OOO till 08-26), 2014/03/06 23:01:25]

As stated in the comment of my CL: there is no way to log out a single person
without closing the session. When one leaves the session, the session ends.

"If the world is 100 people, ..." correct that is exactly what that would mean,
all sessions would be 3 people sessions.

But... see my comment in the newer post.

   </summary>
 </histogram>
 
@@ -8117,10 +8117,13 @@ other types of suffix sets.
   </summary>
 </histogram>
 
-<histogram name="MultiProfile.UsersPerSession">
+<histogram name="MultiProfile.UsersPerSessionIncremental">

[James Cook, 2014/03/06 19:45:35]

You can't rename a stat in histograms.xml. You need to add a new one and mark
the old one as obsolete.

[Mr4D (OOO till 08-26), 2014/03/06 20:15:19]

Ahh. I didn't know! Done!

[Mark P, 2014/03/06 21:36:33]

old unpublished comment:
Please mark old histograms as <obsolete> (with its original description), then
create a new entry for the new histogrma.

   <summary>
     The number of users simultaneously signed into a multiprofile session on
-    Chrome OS. This is recorded whenever a new user logs in.
+    Chrome OS. This is recorded whenever a user gets added to the session. To
+    get the correct count, all following counts must be subtracted. Example: If
+    100 single user, 20 two user and 5 three user sessions, there were
+    100-20-5=75 single user sessions, 100-80=20 dual user sessions and so on.
   </summary>
 </histogram>