New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 783032 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
(OOO slow)
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

[TTS] Remove tap-limit counters and limiting taps

Project Member Reported by donnd@google.com, Nov 9 2017

Issue description

We have some tap limits that will be problematic with our tap suppression work because they can limit when we respond to tap for undecided users.  One limit based on the DisableablePromoTapCounter can completely suppress taps for undecided users that have never opened the panel.  Most users can get CS for long-press and then if they open the panel it will start working for tap again.  However, with Smart Selection the longpress activation won't be available for some users.  I think we should just remove this complication, and related limits.
 
Do we know how many undecided users currently have contextual search disabled on tap due to too many taps without an open?

Comment 2 by donnd@google.com, Nov 9 2017

We do collect data for this, but it's confusing me and I need to do some follow-up.  For the record it looks like 20% of users have never opened the panel and didn't see any tap-generated Peeks, based on my reading of the histogram below.  

https://uma.googleplex.com/histograms?endDate=20171107&dayCount=28&histograms=Search.ContextualSearchPromoTapsForNeverOpened&fixupData=true&uniqueUsers=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

Comment 3 by donnd@google.com, Dec 5 2017

Labels: -M-64 M-65

Comment 4 by donnd@google.com, Dec 15 2017

Cc: k...@chromium.org mahmadi@chromium.org
I looked at these tap-disabled metrics again, and I think I understand them now:
approximately 50% of our users have tap disabled because they have reached the tap limit and never opened the panel (50 taps).  The panel is still shown on long-press (unless they have Smart Text Selection enabled), but we don't trigger on tap if they are also undecided.

In ContextualSearchPolicy#logCurrentState we log the state of all users and have ~170M.  We log CSPTapsForNeverOpened for those that have never opened the panel (~85M) and CSPTapsBeforeFirstOpen for those that have opened the panel (~85M).  The ContextualSearchPromoTapsRemaining has almost the same user count as CSPTapsBeforeFirstOpen (~80M) but is slightly less because it doesn't count decided users.

Details at https://uma.googleplex.com/histograms?endDate=20171107&dayCount=28&histograms=Search.ContextualSearchPreferenceState%2CSearch.ContextualSearchPromoTapsBeforeFirstOpen%2CSearch.ContextualSearchPromoTapsForNeverOpened%2CSearch.ContextualSearchPromoTapsRemaining&fixupData=true&uniqueUsers=true&showMax=true&filters=platform%2Ceq%2CA%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

Since this is such a large number of users I think it makes sense to keep them in the tap-disabled state for now, but have an experiment that throws them back into the tap-enabled state.  We'll be able to activate this experiment if the Ranker Tap Suppression looks good so they'll move from never seeing the tap-triggering to sometimes seeing it (hopefully under good circumstances).

Comment 5 by k...@chromium.org, Dec 18 2017

Oh - do we restrict IPH for these users?

Comment 6 by donnd@google.com, Dec 18 2017

> Oh - do we restrict IPH for these users?
No, we don't.  But the impact is small and we can add a workaround.

This only effects the CONTEXTUAL_SEARCH_WEB_SEARCH_FEATURE because the other two features either are triggered on Tap or require the panel to have been opened before. Since this "Promote Contextual Search" bubble says "Tap a Word..." we'll need to do something to make sure tap does work for these users. 

I think the simplest way to address this is to add another condition to the triggering for the CONTEXTUAL_SEARCH_WEB_SEARCH_FEATURE to require that the panel have been opened at least once in the past.  

Comment 7 by k...@chromium.org, Dec 18 2017

Sure that sounds good.
Project Member

Comment 8 by bugdroid1@chromium.org, Jan 9 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d0827a723f95029b44b8f3b721f956243487ec31

commit d0827a723f95029b44b8f3b721f956243487ec31
Author: Donn Denman <donnd@google.com>
Date: Tue Jan 09 00:55:39 2018

[TTS] Remove tap limits for resolve and prefetch.

Removes the user-visible limits on whether a Tap gesture will
resolve or prefetch, making the behavior more consistent.

Adds a Feature to override the tap-disable behavior for users
that have never opened the panel.

Keeps all counters and counter-updating behavior unchanged.

BUG= 783032 

Change-Id: I74abed9c6a1f86f3b2d90a89521560697ef441df
Reviewed-on: https://chromium-review.googlesource.com/830823
Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Donn Denman <donnd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527839}
[modify] https://crrev.com/d0827a723f95029b44b8f3b721f956243487ec31/chrome/android/java/src/org/chromium/chrome/browser/ChromeFeatureList.java
[modify] https://crrev.com/d0827a723f95029b44b8f3b721f956243487ec31/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchFieldTrial.java
[modify] https://crrev.com/d0827a723f95029b44b8f3b721f956243487ec31/chrome/android/java/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchPolicy.java
[modify] https://crrev.com/d0827a723f95029b44b8f3b721f956243487ec31/chrome/android/javatests/src/org/chromium/chrome/browser/contextualsearch/ContextualSearchManagerTest.java
[modify] https://crrev.com/d0827a723f95029b44b8f3b721f956243487ec31/chrome/browser/android/chrome_feature_list.cc
[modify] https://crrev.com/d0827a723f95029b44b8f3b721f956243487ec31/chrome/browser/android/chrome_feature_list.h

Comment 9 by donnd@google.com, Jan 9 2018

Status: Fixed (was: Assigned)

Sign in to add a comment