We will need to add metrics. We should use equivalent metrics to those that already exist for the tab switcher/stack view, and add more as needed -- Gabe and/or Mardini may have things they want to see measured, for example.

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Per mardini@, here are the metrics (user actions Clank will be using, many of which we have in the legacy implementations. we should match these as much as possible.

MobileStackViewCloseTab + MobileTabClosed	when a tab is closed via the X
MobileStackViewSwipeCloseTab + MobileTabClosed	when a tab is closed via swipe
MobileTabSwitched				whenever a tab is switched
MobileToolbarStackViewNewTab			when a new tab is created (only through the + button.)
MobileTabReturnedToCurrentTab			when users exit the tab switcher to return to the current foreground tab (new)
MobileToolbarStackViewButtonInStackView		swiping to open the switcher (new)
MobileStackViewNormalMode			when user switches between regular & incognito
MobileToolbarSwipeOpenStack

How will we address the the fact that we don't have SwipeCloseTab or SwipeOpenStack? 
I guess for the others, we want to keep the same names to be able to track across releases, right ?

These are already handled by a WebStateListObserver:
MobileTabClosed 
MobileTabClosed
MobileTabSwitched    

These are in-flight in a CL:
MobileStackViewCloseTab 	                when a tab is closed via the X 	
MobileToolbarStackViewNewTab			when a new tab is created (only through the + button.)
MobileTabReturnedToCurrentTab			when users exit the tab switcher to return to the current foreground tab (new)
MobileStackViewNormalMode			when user switches between regular & incognito
MobileStackViewIncognitoMode			when user switches between regular & incognito

These are not yet possible:
MobileStackViewSwipeCloseTab                    when a tab is closed via swipe
MobileToolbarStackViewButtonInStackView		swiping to open the switcher (new)
MobileToolbarSwipeOpenStack

I also grepped for UserMetricsAction in ui/tab_switcher/, and we should probably also support the following:

When entering/exiting the grid (for any reason):
MobileTabSwitcherPresented    
MobileTabSwitcherDismissed

When switching between panels. Some of these are the same events as metrics listed earlier in this bug; we should record both for now so we can compare usage between the new UI and the old UIs on both phones and iPads:
MobileTabSwitcherHeaderViewSelectIncognitoPanel
MobileTabSwitcherHeaderViewSelectNonIncognitoPanel
MobileTabSwitcherHeaderViewSelectDistantSessionPanel

When creating new tabs (+ button, again overlapping with other metrics):
MobileTabSwitcherCreateIncognitoTab
MobileTabSwitcherCreateNonIncognitoTab

Opening a tab from the remote tabs panel:
MobileTabSwitcherOpenDistantTab

Opening existing tabs:
MobileTabSwitcherOpenIncognitoTab
MobileTabSwitcherOpenNonIncognitoTab

Closing existing tabs:
MobileTabSwitcherCloseIncognitoTab
MobileTabSwitcherCloseNonIncognitoTab

And maybe:
MobileTabSwitcherEnableSync

After the UI refresh is 100% launched and there is no need to compare to usage of the old tab switching UIs (e.g., M70+), we will revise and condense these action names for both clarity (naming them 'TabGrid ...') and to eliminate redundancy. A separate bug, blocked on this one, will be filed for that.

Copied  issue chromium:818452  to issue chromium:856965

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

commit e9e3e6783a10bc05cd0e3b6b6d05289240b4276a
Author: edchin <edchin@chromium.org>
Date: Wed Jun 27 14:18:14 2018

[ios] Metrics for tab grid

This CL implements these metrics in tab grid:

MobileStackViewCloseTab 	when a tab is closed via the X
MobileToolbarStackViewNewTab	when a new tab is created (only through the + button.)
MobileTabReturnedToCurrentTab	when users exit the tab switcher to return to the
                                current foreground tab
MobileStackViewNormalMode	when user switches between regular & incognito
MobileStackViewIncognitoMode	when user switches between regular & incognito


Bug:  818452 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I570a31af65bc929f646d005789cecb1a0afca442
Reviewed-on: https://chromium-review.googlesource.com/1116284
Reviewed-by: edchin <edchin@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Commit-Queue: edchin <edchin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570758}
[modify] https://crrev.com/e9e3e6783a10bc05cd0e3b6b6d05289240b4276a/ios/chrome/browser/ui/tab_grid/grid/grid_view_controller.mm
[modify] https://crrev.com/e9e3e6783a10bc05cd0e3b6b6d05289240b4276a/ios/chrome/browser/ui/tab_grid/tab_grid_view_controller.mm

I also did a grep and had planned to implement all the metrics from tab_switcher. This CL is in-flight. Will also connect with ghendel@ to review what metrics have been ported and see what gaps if any there are.

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

commit e886d841e5d39dbbb3ad042df29c65d1eaa8ec5c
Author: edchin <edchin@chromium.org>
Date: Wed Jun 27 23:55:40 2018

[ios] Additional tab grid metrics

This CL implements these additional metrics:

Entering/Exiting tab switcher:
MobileTabSwitcherPresented
MobileTabSwitcherDismissed

Selecting panels:
MobileTabSwitcherHeaderViewSelectIncognitoPanel
MobileTabSwitcherHeaderViewSelectNonIncognitoPanel
MobileTabSwitcherHeaderViewSelectDistantSessionPanel

Creating, opening, closing tabs:
MobileTabSwitcherCreateIncognitoTab
MobileTabSwitcherCreateNonIncognitoTab
MobileTabSwitcherOpenIncognitoTab
MobileTabSwitcherOpenNonIncognitoTab
MobileTabSwitcherCloseIncognitoTab
MobileTabSwitcherCloseNonIncognitoTab


Bug:  818452 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I1352eb8e99fb6c044d954a0690f6a2f00c511572
Reviewed-on: https://chromium-review.googlesource.com/1117130
Commit-Queue: edchin <edchin@chromium.org>
Reviewed-by: Sergio Collazos <sczs@chromium.org>
Reviewed-by: edchin <edchin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570946}
[modify] https://crrev.com/e886d841e5d39dbbb3ad042df29c65d1eaa8ec5c/ios/chrome/browser/ui/tab_grid/grid/grid_view_controller.mm
[modify] https://crrev.com/e886d841e5d39dbbb3ad042df29c65d1eaa8ec5c/ios/chrome/browser/ui/tab_grid/tab_grid_coordinator.mm
[modify] https://crrev.com/e886d841e5d39dbbb3ad042df29c65d1eaa8ec5c/ios/chrome/browser/ui/tab_grid/tab_grid_view_controller.mm

The NextAction date has arrived: 2018-07-04

Is there more that needs to happen here?

I'm going to do one final assessment of the metrics before closing this today.

These all look good to me. 

Two questions I want to look into at some point and want to make sure are possible to analyze: 
-How many tabs users have open at any given time (seems like this is currently supported already)
-What % of tab switcher opens lead to no change in the existing tab the user is in? (e.g. they just close a bunch of tabs but go back to their current one)

ghendel@ re: #21 -- is "at some point" M70 or later? If so, please file a separate bug or bugs for those metrics. If not ...  please file a separate bug so we can assess priority for M69.

For the question -- "How many tabs users have open...", ghendel@ and I looked and found "Tabs.CountAtResume" and "Tabs.CountAtStartup" to be the relevant metrics. Those are already implemented and are comparable across milestones. 

For the question -- "What % of tab switcher opens lead to no change..." -- ghendel@ said there might be an android metric already. This can be filed as a separate bug. 

Otherwise, I believe we can close out this bug.