UserEvent proto exploration for 0-Suggest use case.

components/sync/protocol/user_event_specifics.proto

Index: components/sync/protocol/user_event_specifics.proto
diff --git a/components/sync/protocol/user_event_specifics.proto b/components/sync/protocol/user_event_specifics.proto
index 8d3efd1b3126faa2dbe3bedd446c7c48bd381693..f03d0602d58c90af9aed47b5404e02213c92d74c 100644
--- a/components/sync/protocol/user_event_specifics.proto
+++ b/components/sync/protocol/user_event_specifics.proto
@@ -13,6 +13,28 @@ option optimize_for = LITE_RUNTIME;
 
 package sync_pb;
 
+// Records the event of 0-suggest making a request to cusco and generating

[gcomanici, 2017/05/16 14:19:57]

In Chromium code base, this service is known as "experimental contextual
zero-suggest suggestions". We should try to use this instead of cusco, which is
the internal name.

How about "Records requests to the service providing experimental contextual
zero-suggest suggestions."?

+// suggestions for the user. By itself, this event is relatively meaningless.
+// Although this event is navigation linked, presumably the cusco request
+// already knows what url the request was originally on. The purpose of this
+// event is to join |cusco_request_id| to a ZeroSuggestSelected event.
+message ZeroSuggestRequest {
+  optional int64 cusco_request_id = 1;

[gcomanici, 2017/05/16 14:19:57]

We should rename this to contextual_zero_suggest_request_id.

+}
+
+// Records the event of the user selecting and navigating to a particular
+// 0-suggest option. Purposely does not contain |cusco_request_id|, because this
+// event is linked to the destination navigation, not the source navigation,
+// and thus deletions are keyed off the destination navigation/url.
+message ZeroSuggestSelected {
+  // The |event_time_usec| of the ZeroSuggestRequestEvent that generated the

[Toyama, 2017/05/16 14:08:34]

Where is |event_time_usec| defined?

And do you mean s/ZeroSuggestRequestEvent/ZeroSuggestRequest/ ?

+  // suggestions of which one was clicked on to generate this event.
+  optional fixed64 request_event_id = 1;

[gcomanici, 2017/05/16 14:19:57]

Should the type be int64, for consistency with the event_time_usec it is
referring to? Also, the name is misleading. If we log the time and not the event
id, then the name should be something like "request_event_time_usec".

+
+  // The index of the suggestions that was selected by the user.
+  optional int32 index_selected = 2;
+}
+
 message UserEventSpecifics {
   // Time of event, as measured on the client (unix epoch).
   optional int64 event_time_usec = 1;
@@ -24,5 +46,8 @@ message UserEventSpecifics {
   // other events belonged to.
   optional fixed64 session_id = 3;
 
-  // TODO(skym): Wrap actual event payloads in a oneof.
+  oneof event {
+    ZeroSuggestRequest zero_suggest_request = 4;
+    ZeroSuggestSelected zero_suggest_selected = 5;
+  }
 }