I think we should port all of these to MD extensions. Doesn't need to block Canary/Dev, be it would be nice to add them sometime soon so we can get an early glimpse at usage.

I'll think about new metrics to add and file a separate bug.

Separately, can you point me to the old histograms? I would like to look at the data but can't seem to find them.

I did find some of them, but not all. Also it turns out these are not histograms but actions (usage counts). Pasting the ones I did find below:

https://uma.googleplex.com/p/chrome/usage/?sid=c3b8ce5ae5fd180b4ad5e01e126e13cb
https://uma.googleplex.com/p/chrome/usage/?sid=2d191bf09f72bf2f238b6fd57c989028
https://uma.googleplex.com/p/chrome/usage/?sid=27361f24e7b49e0f1b5ca65347eb1758
https://uma.googleplex.com/p/chrome/usage/?sid=b478cf476d4d17760794c062c1596140

@Devlin: Do you have any thoughts on whether these metrics should be ported to the new UI? Do you know if they are they still useful? Is there any UX/product decision to be taken based on these?

@4, I think all of these metrics will be useful for informing future product / UI decisions. I think there are others that would be useful too, in particular as search and keyboard shortcuts. Could we add those to the list?

Regarding search metrics: In a previous discussion it was concluded that most users (very high percentile) have very few extensions/apps. Nonetheless we kept search to help power users (technically it was implemented before we came around that metric).

What decision would be driven from more search usage data?
Are we planning to remove it if usage seems to be low? It seems that we already expect it to be very low, given that it is unlikely a user with less than 10 extensions to search, since they all fit in the landing page.

Are we planning to improve it if usage is high? For example filtering on enabled/disabled as requested by issue 379184?

> in particular as search and keyboard shortcuts

Keyboard shortcuts seems to be addressed by Options_ExtensionCommands already. So if we were to port this, do we need more metrics regarding shortcuts?


@Devlin: Would it be reasonable to modify the implementation of various chrome.developerPrivate() methods, to record metrics? Instead of separately recording metrics from the UI? This would eliminate the need to keep porting metrics when the UI is re-implemented.

> What decision would be driven from more search usage data?
> Are we planning to improve it if usage is high? For example filtering on enabled/disabled as requested by issue 379184?

Yes - this data would be useful for prioritizing future work.

> Keyboard shortcuts seems to be addressed by Options_ExtensionCommands already. So if we were to port this, do we need more metrics regarding shortcuts?

Thanks for clarifying. No I don't think we need more metrics - Options_ExtensionCommands seems sufficient.

> @Devlin: Do you have any thoughts on whether these metrics should be ported to the new UI? Do you know if they are they still useful? Is there any UX/product decision to be taken based on these?

I think they are still useful, as jawag@ commented as well.  I know that bettes@ did reference these when designing the new MD page.

> @Devlin: Would it be reasonable to modify the implementation of various chrome.developerPrivate() methods, to record metrics? Instead of separately recording metrics from the UI? This would eliminate the need to keep porting metrics when the UI is re-implemented.

This can make sense, but note that developerPrivate can be used from more than just the chrome://extensions page (there's a couple apps that use it).  We should be able to filter that out in the C++, but we'd need to make sure we do that.  Additionally, the old page uses chrome.developerPrivate() too, so we'd need to make sure to either a) update the old page to not record these separately, or b) only record if MD extensions is enabled.  And finally, a number of these actions might not correspond 1:1 with the developerPrivate calls.  For instance, showing keyboard commands is JS-only, and showing the pack extension dialog and then dismissing it (rather than clicking on "pack") wouldn't result in a call, either.  Overall, I'm not actually sure that moving these to developerPrivate would be easier than having them in JS.  But, I'm not that opposed either.

Out of curiosity, does settings record user actions?  What mechanism does it use?

> Out of curiosity, does settings record user actions?  What mechanism does it use?

It uses two different mechanisms (not sure why):

  1) C++ metrics handler, see [1]
  2) chrome.metricsPrivate API, see [2]

[1] https://cs.chromium.org/search/?q=metricsHandler+file:%5Esrc/chrome/browser/resources/settings/+package:%5Echromium$&type=cs
[2] https://cs.chromium.org/search/?q=chrome.metricsPrivate+file:%5Esrc/chrome/browser/resources/settings/+package:%5Echromium$&type=cs 

FYI, CL for the existing metrics is at https://chromium-review.googlesource.com/c/chromium/src/+/816354.

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

commit 0d869d70faa70bcc2b325a46bbd39684057f807f
Author: dpapad <dpapad@chromium.org>
Date: Tue Dec 12 23:38:43 2017

MD Extensions: Port UMA metrics from previous UI.

Bug:  781439 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I2aff2f2096f6824ceffc05c2c94fcbf013166e5a
Reviewed-on: https://chromium-review.googlesource.com/816354
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Dave Schuyler <dschuyler@chromium.org>
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523603}
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/compiled_resources2.gyp
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/item_list.html
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/item_list.js
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/keyboard_shortcuts.js
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/service.js
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/sidebar.html
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/sidebar.js
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/browser/resources/md_extensions/toolbar.js
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/chrome/test/data/extensions/webui/sanity_check_available_apis.js
[modify] https://crrev.com/0d869d70faa70bcc2b325a46bbd39684057f807f/extensions/common/api/_api_features.json

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

How safe is this merge overall? Is this well tested in Canary?

How safe is this merge overall?
Fairly safe. It is very unlikely that this can cause any regression. Moreover I tested that the UMA added is working as expected by visiting chrome://user-actions and ensuring that the entries appear there as expected.

Is this well tested in Canary?
Tested on Canary 65.0.3295.0

As discussed in meeting, Extensions MD launch is behind a flag. Change has been tested and verified in Canary, and should be a safe merge overall. Approving merge to M64 branch:3282

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

commit e09ba457fe8ca9a551e6dad0137fb474feff1a29
Author: dpapad <dpapad@chromium.org>
Date: Tue Dec 19 00:15:06 2017

[M64 merge] MD Extensions: Port UMA metrics from previous UI.

TBR=dpapad@chromium.org

(cherry picked from commit 0d869d70faa70bcc2b325a46bbd39684057f807f)

Bug:  781439 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I2aff2f2096f6824ceffc05c2c94fcbf013166e5a
Reviewed-on: https://chromium-review.googlesource.com/816354
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Dave Schuyler <dschuyler@chromium.org>
Commit-Queue: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#523603}
Reviewed-on: https://chromium-review.googlesource.com/833341
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#281}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/compiled_resources2.gyp
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/item_list.html
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/item_list.js
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/keyboard_shortcuts.js
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/service.js
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/sidebar.html
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/sidebar.js
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/browser/resources/md_extensions/toolbar.js
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/chrome/test/data/extensions/webui/sanity_check_available_apis.js
[modify] https://crrev.com/e09ba457fe8ca9a551e6dad0137fb474feff1a29/extensions/common/api/_api_features.json