[EBT] Track "click" events

[afharo]

Summary

This PR implements the click event for EBT.

It listens to any click that occurs in the UI and reports it with the full list of attributes. For example, an HTML like:

<div id="my-top-div" class="my-style my-other-style">
  <button data-test-subj="my-action-button">Click here!</button>
</div>

Will report an event like:

{
  "timestamp": "...",
  "context": {},
  "//": "👆the EBT client automatically adds those fields",
  "event_type": "click",
  "properties": {
    "target": [
      "DIV",
      "id=my-top-div",
      "class=my-style my-other-style",
      "BUTTON",
      "data-test-subj=my-action-button",
    ]
  }
}

The target is reported as an array of strings because it feels easier to identify each value when analyzing them. Also, if we need a concatenated version, it's easier to concatenate in the analytics solution than to split by blank space because HTML allows you to store spaces in the attributes' values.

Resolves #125695.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
Some of the attributes of the HTML elements might contain PII info.	Low	High	Apps shouldn't use users' data to identify HTML elements. Any potential standard attribute that may contain user data is added to the POTENTIAL_PII_HTML_ATTRIBUTES constant

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[afharo]

Is there an API in @kbn/expect that allows you to match a subset of an array?

[pgayvallet]

I don't think so 😞

[pgayvallet]

Technically, LGTM.

I still have a concern about volume though. Recording all clicks will generate a massive amount of events. We need to make sure that our shipper backends are properly scaled in term of both influx and storage capacity. I'm especially thinking about the internal v3 telemetry endpoint/cluster.

[pgayvallet]

I don't think so 😞

[pgayvallet]

I don't necessarily have a better idea, but I still wonder how usable this will be, in practice.

[afharo]

The idea I had in mind is that folks can identify if an action is performed by checking if a user clicked on a specific component. If knowing that the user interacted with that component is enough to identify that a feature is used, they don't need to instrument their own events.

In the past we've seen folks leveraging FullStory's click capture for this same purpose: How many users clicked on data-test-subj="my-special-button"?.

Do you think we should take a different approach?

[pgayvallet]

I thought FullStory already had its own internal collection of click events? If that's the case, maybe we should limit the event to the teleV3 shipper?

[afharo]

#131146 already limits the events that are sent to FullStory.

[afharo]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 4469f6a
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
core	349	350	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	299.4KB	300.1KB	+739.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
core	57	58	+1

Total ESLint disabled count

id	before	after	diff
core	67	68	+1

History

• 💚 Build #43118 succeeded 2b3ed06

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[afharo]

I still have a concern about volume though. Recording all clicks will generate a massive amount of events. We need to make sure that our shipper backends are properly scaled in term of both influx and storage capacity. I'm especially thinking about the internal v3 telemetry endpoint/cluster.

@pgayvallet, it is a very valid concern. According to our Application Usage telemetry, all our opted-in users add up to 4.5 million clicks daily. Bearing in mind that each click event is, approximately, 1.3kB (it largely depends on the length of the target property though), that's about 5.4GB daily re "clicks" events.

@elastic/platform-analytics, is this a volume we can assume?

[afharo]

FWIW, I checked the current Security Solutions' inflow and they are sending 6x that volume. I think we should be fine.

[afharo]

As confirmed with @haywoood on Slack, the volume should not be a problem. I'll go ahead and merge.