[TTS] Basic Tap Suppression functionality.

chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java

Index: chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
diff --git a/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java b/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
index 573e7d1ceab2af2cc1e09214c17e31fb2fcf5ebf..4c993efee985ab07372ef22c2b905ae4fd20ff62 100644
--- a/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
+++ b/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchUma.java
@@ -880,6 +880,40 @@ public class ContextualSearchUma {
     }
 
     /**
+     * Log whether the UX was suppressed due to a Tap with broad signals.
+     * @param wasSuppressed Whether showing the UX was suppressed.
+     * @param isSecondTap Whether this was the second tap after an initial suppressed tap.
+     */
+    public static void logTapSuppression(boolean wasSuppressed, boolean isSecondTap) {

[Donn Denman, 2016/06/28 23:39:08]

I decided we don't really need these -- we'll know lots of taps are suppressed
just from looking at ResultsSeenByGesture.  Removed.

+        if (isSecondTap) {
+            // Note that we currently never suppress the second Tap, but we will soon.
+            RecordHistogram.recordEnumeratedHistogram("Search.ContextualSearchTapTwiceSuppressed",
+                    wasSuppressed ? TAP_SUPPRESSED : NOT_TAP_SUPPRESSED, TAP_SUPPRESSED_BOUNDARY);
+        } else {
+            RecordHistogram.recordEnumeratedHistogram("Search.ContextualSearchTapSuppressed",
+                    wasSuppressed ? TAP_SUPPRESSED : NOT_TAP_SUPPRESSED, TAP_SUPPRESSED_BOUNDARY);
+        }
+    }
+
+    /**
+     * Log whether results were seen due to a Tap with broad signals.
+     * @param wasSearchContentViewSeen If the panel was opened.
+     * @param isSecondTap Whether this was the second tap after an initial suppressed tap.
+     */
+    public static void logTapSuppressionResultsSeen(
+            boolean wasSearchContentViewSeen, boolean isSecondTap) {
+        if (isSecondTap) {
+            RecordHistogram.recordEnumeratedHistogram("Search.ContextualSearchSecondTapSeen",
+                    wasSearchContentViewSeen ? RESULTS_SEEN : RESULTS_NOT_SEEN,
+                    RESULTS_SEEN_BOUNDARY);
+        } else {
+            RecordHistogram.recordEnumeratedHistogram("Search.ContextualSearchTapSuppressionSeen",
+                    wasSearchContentViewSeen ? RESULTS_SEEN : RESULTS_NOT_SEEN,

[twellington, 2016/06/27 18:44:01]

Will this ever get called when the panel was shown? It looks like we're only
logging when  suppression is enabled, but it might be beneficial to log
counterfactual data as well.

[Donn Denman, 2016/06/28 23:39:08]

Yes, this is called when the panel is shown for the first N times: Even though
suppression is enabled, we show the panel multiple times before we actually
suppress.

Logging the counterfactual data is a good idea in theory, but because we have a
configurable threshold for suppressing we'd need to configure the Finch control
group for the counterfactual threshold we'd be evaluating.  This seems overly
complicated to me.  We just want to have a few experiment arms at different
settings and check the ResultsSeenByGesture for them to evaluate the new CTR.

[Theresa, 2016/06/29 01:51:57]

That makes sense, thanks.
What will we use this histogram to determine? For users who use the feature,
we'll have normal CTR, for users who don't use the feature, we'll have N counts
in the not seen bucket  (where N is the number we suppress at). Is that
different than ResultsSeenByGesture for the groups where tap suppression is
enabled?

I think we need to be able to answer these two questions:
1. What impact does this have on overall CTR? We can determine this from
ResultsSeenByGesture comparisons.
2. Did we lose any engagement (did we suppress when the user would have clicked
through)? 

#2 I think is harder to measure (we need counter-factual data), but my instinct
is any lost engagement will be really low so this doesn't seem like a big risk.
We can always merge a small CL back if we need more data.

[Donn Denman, 2016/06/29 02:30:36]

Actually these two histograms should split the overall CTR into those that
happen before the count limit and those that happen after the count limit (on a
second tap).  Remember when we suppress we don't get either seen or not-seen (we
should rename to panel opened/peeked or something like that to avoid confusion).
 Together they should sum to the overall CTR, which will help validate the
metrics.  Separately I think they are useful -- the CTR for the second tap
should inform us whether folks are discovering that second tap and finding it
useful.

For #2 -- loss of engagement -- I had planned to just look at panel opens in
response to Tap.  I do think this could go down a lot, especially if people
don't figure out they can long-press or tap twice and open to get the feature to
come back.  The feature has "gone away" in the past due to our outage, so they
may just think it's happening again.  We want to look at this usage to determine
the best N threshold for suppression.

[Theresa, 2016/06/29 02:42:53]

I wasn't considering the second tap getting logged separately, makes sense now,
thanks!
We'll just look at raw # of opens?

+                    RESULTS_SEEN_BOUNDARY);
+        }
+    }
+
+    /**
      * Logs whether search results were seen, whether the search provider icon sprite was animated
      * when the panel first appeared, and the triggering gesture.
      * @param wasIconSpriteAnimated Whether the search provider icon sprite was animated when the