Add a new entry to omnibox_event.proto to log specific type of contextual suggestions

components/omnibox/browser/autocomplete_match.h

Index: components/omnibox/browser/autocomplete_match.h
diff --git a/components/omnibox/browser/autocomplete_match.h b/components/omnibox/browser/autocomplete_match.h
index 9ab496c7dc665b0f6ba3e7c7b95271b882cc1e00..a414ea382d33f957079c0d377cd96f34b5b0cf1a 100644
--- a/components/omnibox/browser/autocomplete_match.h
+++ b/components/omnibox/browser/autocomplete_match.h
@@ -367,6 +367,12 @@ struct AutocompleteMatch {
   // Type of this match.
   Type type;
 
+  // Used to identify the specify type of the autocomplete match. For example,
+  // contextual zero suggest suggestions uses this field to record the specific
+  // suggestion types in order to assess the quality of multiple suggestion
+  // sources.
+  std::string specific_type;

[Mark P, 2017/03/14 20:17:49]

I'd curious why you've chosen to add a specific_type / sub_type here as opposed
to expanding the list of valid types.  For example, we have a variety of search
query types that are based on the server suggestion: SEARCH_SUGGEST (general),
SEARCH_SUGGEST_TAIL, SEARCH_SUGGEST_ENTITY, SEARCH_SUGGEST_PERSONALIZED, etc.

I'm not sure whether that's a better approach than adding another field.  I'd
like us to know your reasoning for the choice you made.

[gcomanici, 2017/03/14 20:42:55]

I was mostly concerned about adding unnecessary complexity to the enum of
AutoComplete types. Since this change introduces 12 additional types which are
of interest only to the team working on contextual suggestions, it made more
sense to have a separate independent field. I'd rather not pollute histograms
which are concerned with the high-level AC types. 

[Mark P, 2017/03/14 21:04:09]

Makes sense to me.

What about the decision not to store this in omnibox_event.proto?  Do you think
you'll never want to do analysis like looking at the list of types of zero
suggest suggestions shown at the time a suggestion was used?  Or look at
interactions between, say, suggestion position and zero suggest specific type?

[gcomanici, 2017/03/15 01:35:56]

Short answer: I'm scared of omnibox_event.proto. I looked a bit into it, but I
don't have a good grasp of where the data saved in this proto is used for
updating histograms. 

Indeed, further analyses will be of interest, but I believe that will happen
when we get more traffic. With this CL, we are trying to go for quick gains in
quality, which will allow hopefully allow us to get more usage and more in-depth
analyses. I chose not to go for the proto in the interest of getting this
specific histograms ready earlier, but if you believe using the proto is not as
complex as I think it is, I could look into incorporating these signals in the
proto. 

+
   // Set with a keyword provider match if this match can show a keyword hint.
   // For example, if this is a SearchProvider match for "www.amazon.com",
   // |associated_keyword| could be a KeywordProvider match for "amazon.com".