[Payments] Add PaymentRequest checkout funnel UKMs.

components/payments/core/journey_logger.h

Index: components/payments/core/journey_logger.h
diff --git a/components/payments/core/journey_logger.h b/components/payments/core/journey_logger.h
index 67401c1ec4af961ca11b371d1d135fe6f5655730..75a91b36867d9569ad847e3f18ac395b2047ff47 100644
--- a/components/payments/core/journey_logger.h
+++ b/components/payments/core/journey_logger.h
@@ -8,6 +8,18 @@
 #include <string>
 
 #include "base/macros.h"
+#include "url/gurl.h"
+
+namespace ukm {
+class UkmService;
+}
+
+namespace internal {
+// Name constants are exposed here so they can be referenced from tests.
+extern const char kUKMCheckoutFunnelEntryName[];
+extern const char kUKMCompletionStatusMetricName[];
+extern const char kUKMLastStepMetricName[];
+}  // namespace internal
 
 namespace payments {
 
@@ -46,6 +58,15 @@ class JourneyLogger {
     COMPLETION_STATUS_MAX,
   };
 
+  // The steps of a successful Payment Request.
+  enum CompletionStep {

[Mathieu, 2017/04/10 01:03:02]

Completion is misleading, let's find a better term

[sebsg, 2017/04/10 15:30:28]

Done.

+    STEP_INITIATED = 0,

[Mathieu, 2017/04/10 01:03:02]

had an idea, let me know what you think.

if each value was 1 << 0, 1 << 1, etc., we could accumulate 

checkout_step_ |= step;

And this would allow us to log various other steps (not necessarily linear)
easily. 

Let's say I extend your example and we have

SELECTED_SHIPPING_OPTION = 1 << 4
SELECTED_PAYMENT_METHOD = 1 << 5
etc.

we could de facto differentiate in the metrics between 
00111 and 11111 or 10111, which are all success cases but with variations.

[sebsg, 2017/04/10 15:30:29]

Excellent idea! I was thinking that we should add more stuff, like added card or
something. This is perfect!

+    STEP_SHOWN = 1,
+    STEP_PAY_CLICKED = 2,
+    STEP_RECEIVED_INSTRUMENT_DETAILS = 3,

[Mathieu, 2017/04/10 01:03:02]

I would recommend removing the STEP_ prefix from all these

[sebsg, 2017/04/10 15:30:28]

Acknowledged.

+    STEP_MAX,
+  };
+
   // Used to mesure the impact of the CanMakePayment return value on whether the
   // Payment Request is shown to the user.
   static const int CMP_SHOW_COULD_NOT_MAKE_PAYMENT_AND_DID_NOT_SHOW = 0;
@@ -53,7 +74,9 @@ class JourneyLogger {
   static const int CMP_SHOW_COULD_MAKE_PAYMENT = 1 << 1;
   static const int CMP_SHOW_MAX = 4;
 
-  explicit JourneyLogger(bool is_incognito);
+  explicit JourneyLogger(bool is_incognito,

[Mathieu, 2017/04/10 01:03:02]

no explicit

[sebsg, 2017/04/10 15:30:28]

Done.

[sebsg, 2017/04/10 15:30:29]

Done.

+                         GURL url,
+                         ukm::UkmService* ukm_service);
   ~JourneyLogger();
 
   // Increments the number of selection adds for the specified section.
@@ -75,6 +98,9 @@ class JourneyLogger {
   // Records the fact that the Payment Request was shown to the user.
   void SetShowCalled();
 
+  // Records the steps as they are done.
+  void SetCurrentStep(CompletionStep step);
+
   // Records the histograms for all the sections that were requested by the
   // merchant and for the usage of the CanMakePayment method and its effect on
   // the transaction. This method should be called when the Payment Request has
@@ -125,12 +151,21 @@ class JourneyLogger {
   void RecordCanMakePaymentEffectOnCompletion(
       CompletionStatus completion_status);
 
+  // Records the Payment Request Url Keyed Metrics.
+  void RecordUkms(CompletionStatus completion_status);

[Mathieu, 2017/04/10 01:03:02]

RecordUrlKeyedMetrics is nice and descriptive

[sebsg, 2017/04/10 15:30:29]

Done.

+
   SectionStats sections_[NUMBER_OF_SECTIONS];
   bool was_can_make_payments_used_;
   bool could_make_payment_;
   bool was_show_called_;
   bool is_incognito_;
 
+  CompletionStep current_step_;
+
+  // For the UKMs.

[Mathieu, 2017/04/10 01:03:02]

nit: I don't think we need this line

[sebsg, 2017/04/10 15:30:28]

Done.

[sebsg, 2017/04/10 15:30:29]

Done.

+  GURL url_;
+  ukm::UkmService* ukm_service_;
+
   DISALLOW_COPY_AND_ASSIGN(JourneyLogger);
 };