[TTS] Remove tap-limit counters and limiting taps |
||||
Issue descriptionWe 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.
,
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
,
Dec 5 2017
,
Dec 15 2017
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).
,
Dec 18 2017
Oh - do we restrict IPH for these users?
,
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.
,
Dec 18 2017
Sure that sounds good.
,
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
,
Jan 9 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by twelling...@chromium.org
, Nov 9 2017