Elastic homepage analytics

[alexfrancoeur]

Relates to #25734 #70571

@cqliu1 @ryankeairns I took a first stab at defining some telemetry for the homepage. Let me know what you think, we can iterate if needed.

Navigation from the homepage

Questions we want answered

• Which solution / use case is clicked into most on the homepage? (Kibana included here)
• Which ingest option is clicked into most from the homepage?
• Which management option is click into most from the homepage?

Metrics to help answer these questions

Generally, I think it makes sense to include some time buckets here, but I hesitant to go overboard with the time intervals as each panel will end up having four fields. If we wanted to match the application_usage metrics, having 7 day, 30 day, 90 day and total would be beneficial here - but I think we should discuss.

• Clicks into [panel] for the last 7 days
• Clicks into [panel] for the last 30 days
• Clicks into [panel] for the last 90 days
• Total clicks into [panel]

Navigation to the homepage

Questions we want answered

• How much time is actually spent in the homepage?
• How frequently are users explicitly navigating to the homepage?

Metrics to help answer these questions

We are capturing this today with application usage telemetry. No more additional work here 😄

Changing the homepage

Questions we want answered

• How many clusters are changing the homepage?
• How many spaces have changed their homepage?

Metrics to help answer these questions

I don't believe this exists today, so we'd have to plug into advanced settings most likely to capture the actual change. But we could equally measure the amount of times people clicked into this.

• Total number of spaces with a changed homepage
• Total number of clicks on the 'Display a different page on log in' links (home and overview)

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[ryankeairns]

This is great. Are there any Telemetry docs on how we might go about accomplishing this?
I'm not familiar with the setup and, in turn, am having a difficult time estimating how much work is here.

[ryankeairns]

Should we use the same approach for the Kibana landing page?

[alexfrancoeur]

This is great. Are there any Telemetry docs on how we might go about accomplishing this?

I'll send over a wiki link that has a few different docs

Should we use the same approach for the Kibana landing page?

++ I'd imagine we'll have similar questions. We'll probably want to track in a separate issue but I'll defer to @AlonaNadler on the types of questions she'd like to answer

[TinaHeiligers]

@alexfrancoeur #81827 adds ui_metrics that are in the format we're familiar with for ui_metrics:

`ui_metric.Kibana_home`

"ui_metric": {
  "Kibana_home": [
    {
      "key": "manage_data_card_console",
      "value": 1
    },
    {
      "key": "set_home_as_default_route",
      "value": 3
    },
    {
      "key": "solution_panel_observability",
      "value": 1
    },
    {
      "key": "ingest_data_card_ingestManager",
      "value": 1
    },
    {
      "key": "ingest_data_card_home_tutorial_directory",
      "value": 1
    },
   ...
  ]
}

Once https://github.com/elastic/telemetry/issues/465 has been handled (scoped for 7.11), and we have a new index in Telemetry-Next that will transform the data, we'll be reporting metrics as:

ui_metrics custom index document example

{
  appName: 'Kibana_home',
  eventName: 'set_home_as_default_route',
  eventType: 'click',
  timestamp: <date_collecting_started>,
  total: 13,
	cluster_metadata: {
     cluster_uuid,
     license,
     processed_timestamp,
  },
  ...any other fields we need
}

We're not going to pre-aggregate the data before sending it from Kibana for reasons given in https://github.com/elastic/telemetry/issues/465, so the major work here is transforming the data and indexing it into a custom Telemetry-Next index.

We need to keep any changes to the ui_metric API to an absolute minimum and all we're actually doing is adding the timestamp field to the data that's already captured. In short, we're not changing the API at all.