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

components/data_use_measurement/content/content_url_request_classifier.cc

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #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 {
 
 bool IsUserRequest(const net::URLRequest& request) {
   // The presence of ResourecRequestInfo in |request| implies that this request
   // was created for a content::WebContents. For now we could add a condition to
   // check ProcessType in info is content::PROCESS_TYPE_RENDERER, but it won't
   // be compatible with upcoming PlzNavigate architecture. So just existence of
   // ResourceRequestInfo is verified, and the current check should be compatible
   // with upcoming changes in PlzNavigate.
   // TODO(rajendrant): Verify this condition for different use cases. See
   // crbug.com/626063.
   return content::ResourceRequestInfo::ForRequest(&request) != nullptr;
 }
 
 bool ContentURLRequestClassifier::IsUserRequest(
     const net::URLRequest& request) const {
   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