Record data use of user traffic by different core page transition types

components/data_use_measurement/content/content_url_request_classifier.cc

Index: components/data_use_measurement/content/content_url_request_classifier.cc
diff --git a/components/data_use_measurement/content/content_url_request_classifier.cc b/components/data_use_measurement/content/content_url_request_classifier.cc
index 23bbd8baa9624a0515bfab3b4bf2026ab5e4243a..add53965830447f297215f0e8f8d6ce4f5fe5178 100644
--- a/components/data_use_measurement/content/content_url_request_classifier.cc
+++ b/components/data_use_measurement/content/content_url_request_classifier.cc
@@ -4,8 +4,11 @@
 
 #include "components/data_use_measurement/content/content_url_request_classifier.h"
 
+#include "base/metrics/histogram_macros.h"
+#include "base/metrics/sparse_histogram.h"
 #include "content/public/browser/resource_request_info.h"
 #include "net/url_request/url_request.h"
+#include "ui/base/page_transition_types.h"
 
 namespace data_use_measurement {
 
@@ -26,4 +29,25 @@ bool ContentURLRequestClassifier::IsUserRequest(
   return data_use_measurement::IsUserRequest(request);
 }
 
+void ContentURLRequestClassifier::RecordPageTransitionUMA(
+    int32_t page_transition,
+    int64_t received_bytes) const {
+  ui::PageTransition core_page_transition = ui::PageTransitionStripQualifier(

[RyanSturm, 2017/01/10 18:32:23]

Like I mentioned before, this shouldn't be necessary.

[Raj, 2017/01/10 22:21:57]

Done.

+      static_cast<ui::PageTransition>(page_transition));
+  if (core_page_transition > ui::PAGE_TRANSITION_LAST_CORE)
+    return;
+  if (received_bytes <= 0)
+    return;
+
+  // Use the more primitive STATIC_HISTOGRAM_POINTER_BLOCK macro because the
+  // simple UMA_HISTOGRAM_ENUMERATION macros don't expose 'AddCount'.
+  STATIC_HISTOGRAM_POINTER_BLOCK(
+      "DataUse.PageTransition.UserTraffic",

[RyanSturm, 2017/01/10 18:32:23]

Do you need to address the issue mpearson raised on a bug about these
histograms? You can differ if you are cleaning them all up at once.

[Raj, 2017/01/10 22:21:57]

Its not clear whether the overflow bug should be fixed, and how it should be
fixed. In general, UMA is uploaded once every 30 mins, and the overflow occurs
at 4GB. So, this is a less-likely corner case for android users.

One approach is to log sparse histograms (individual UMA for each of the types,
instead of using enum). However, that would increase the amount of histograms
and may be overkill. tbansal@ mentioned it is performance inefficient too. 

Another approach is to aggregate and log the UMA in terms of 1K bytes, which
would lose some precision, and miss some bytes from users with low usage.

https://g3doc.corp.google.com/analysis/uma/g3doc/basic-introduction.md?cl=head

+      AddCount(core_page_transition, received_bytes),
+      base::LinearHistogram::FactoryGet(
+          "DataUse.PageTransition.UserTraffic", 1,
+          ui::PAGE_TRANSITION_LAST_CORE, ui::PAGE_TRANSITION_LAST_CORE + 1,
+          base::HistogramBase::kUmaTargetedHistogramFlag));
+}
+
 }  // namespace data_use_measurement