Is this supposed to report via the PLM UKM metrics?

I think we should report this using the PLM codebase. It requires some small changes.

Today all the PLM UKM logic happens in the UKM observer but instead I'd like to see us move:

source_id_(ukm::UkmService::GetNewSourceID()) {}

from the UKM observer constructor to the PageLoadTracker constructor, and then provide that source id to all observers, via the PageLoadExtraInfo struct.

Then any observer can log UKM associated with the same source and we can do things like join UKM metrics from different observers for the same source id.

So in this new world, if data reduction proxy observer logs that DRP was used for a given page load (for a given source id), we can then determine the FCP, FMP, etc for that DRP load by joining on source id and filtering to page loads where the DRP bit is set. DRP observer no longer has to also log FCP, FMP, etc for these loads, since UKM data is joinable in a way that UMA data is not.

Ryan, how does this sound to you? Is this something you'd like to implement?

I was actually just writing an email, and I like your proposal better than mine. One outstanding issue is offline previews that use MHTML. Currently, PLM UKM is not reported for those pages, so it is not clear if it should report for MHTML or if we should just drop offline previews from consideration considering the previews will just be much faster in every case.

I can take over the transition in either case 

I'll begin writing a doc on it, since the UKM team might want to review the design.

Sounds good, thanks! Good point re: MHTML.

One idea would be to have some sort of callback that observers can invoke to register interest in UKM metrics for a given page load, and if that callback gets invoked by one or more observers, then we tell the UKM observer to log metrics for that page.

But for v1 I'm inclined to forego this and do the simple thing, then circle back and address MHTML and any other similar cases in a v2 follow up.

Looking forward to your doc, thank you!

Ryan, would it be possible to generalize this solution to provide the list of interventions (previews and otherwise) that have been applied to a page? I think in the long term that's what we're going to want.

The plan is to allow any PLM observer to tack on information to the PLM UKM blob.

I think that's a good end goal and should be very achievable. I'll let Ryan comment more, but here's my high level thinking for how this info should be structured:

I'm inclined to group similar interventions together in a single metric using an enum bitfield, but keep different kinds of interventions separate from one another.

So for example we might have a UKM metric that contains a bitfield of document.write related intervention information, and a separate metric that contains a bitfield for preview related information, etc. We wouldn't put the doc.write info and the previews info in the same metric/bitfield.

How does this sound?

I agree that we should collapse information into bitfields where it makes sense.

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

commit 1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2
Author: ryansturm <ryansturm@chromium.org>
Date: Mon Jul 17 20:54:03 2017

Adding previews information to PLM UKM

This adds four metrics to the PLM UKM for previews: "opt_out", set to true when the user hit "Show Original" on a preview;
"server_lofi", "client_lofi", and "lite_page" set to true when a preview was shown. When no preview is
shown, no metrics are added to the UKM.

Similarly, when the user does not opt out, nothing is added for opt_out.

This does not track offline previews yet, but may in the future.

The infobar posts an event to page_load_metrics for the web contents when the user clicks "show original" on the page.

BUG= 701514 , 723711 ,728707

Review-Url: https://codereview.chromium.org/2952343004
Cr-Commit-Position: refs/heads/master@{#487238}

[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/BUILD.gn
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/metrics_web_contents_observer.cc
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/metrics_web_contents_observer.h
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/observers/lofi_page_load_metrics_observer_unittest.cc
[add] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/observers/previews_ukm_observer.cc
[add] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/observers/previews_ukm_observer.h
[add] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/observers/previews_ukm_observer_unittest.cc
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/page_load_metrics_initialize.cc
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/page_load_metrics_observer.h
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/page_load_tracker.cc
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/page_load_metrics/page_load_tracker.h
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/previews/previews_infobar_delegate.cc
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/previews/previews_infobar_delegate.h
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/browser/previews/previews_infobar_delegate_unittest.cc
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/chrome/test/BUILD.gn
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/services/metrics/public/cpp/ukm_recorder.h
[modify] https://crrev.com/1806f8e181472bb2fb3d32ce575c4b2ec8a36bf2/tools/metrics/ukm/ukm.xml