When linking to LH docs, include utm parameters for analytics

[rviscomi]

Right now when we link to the LH docs we don't include any tracking information. For example:

https://developers.google.com/web/tools/lighthouse/audits/has-viewport-meta-tag

We could include utm parameters to better understand how visitors arrived at the docs and why. For example:

https://developers.google.com/web/tools/lighthouse/audits/has-viewport-meta-tag?utm_source=lighthouse&utm_medium=extension&utm_content=failure

Ideally we'd use utm_medium to differentiate the Chrome extension from the Audits panel in Dev Tools. Not sure if the code is self-aware enough to make this distinction.

Other params: utm_source always lighthouse to indicate that we sent users there from this tool, and utm_content to identify why users were sent to the docs (the audit failed, passed, maybe specific details about the failure reason).

cc @paulirish @patrickhulce @kaycebasques

[kaycebasques]

utm_content=failure would be very helpful data.

[kdzwinel]

@paulirish regarding utm_medium - I haven't found any existing code that recognizes the environment (I thought that maybe sentry code is doing that, but sentry only works in cli). How does this look in your opinion:

function getEnvironment() {
  if (typeof window !== 'undefined') {
    if (typeof InspectorMain !== 'undefined') {
      return 'devtools';
    }
    return 'extension';
  }
  return 'cli';
}

[Edit] utm_source -> utm_medium

[rviscomi]

^ small correction: utm_source should always be lighthouse, but we should customize the utm_medium param to match the environment

[kdzwinel]

As discussed on the eng meeting - we are going to include environment info in the build time (instead of detecting it in the runtime as I originally proposed).

[brendankenny]

#4972 was well suited to things before we changed the whole build system.

The changes broke the PR pretty badly, but hopefully made it simpler to accomplish the same task. There's a separate entry point for the extension/DevTools/LR/CLI now as well as a separate build entry point for each, which means we can easily add something to each platform's call out to the report generator (or add a process.env variable if it really comes down to it).