Add Browser UserAction Event #1941

Karlie-777 · 2025-02-26T22:44:43Z

Fixes #

Changes

Please provide a brief description of the changes here.

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

CONTRIBUTING.md guidelines followed.
Change log entry added, according to the guidelines in When to add a changelog entry.
- If your PR does not need a change log, start the PR title with [chore]
schema-next.yaml updated with changes to existing conventions.

Karlie-777 · 2025-02-26T23:52:44Z

model/browser/events.yaml

+          requirement_level: recommended
+          examples: ["//*[@id='testBtn']"]
+        - id: user_action_type
+          type: enum


need to confirm the user_action_type enum. Currently, I am using the definitions from https://github.com/microsoft/ApplicationInsights-JS/blob/main/extensions/applicationinsights-clickanalytics-js/src/Enums.ts

breedx-splk · 2025-03-04T22:46:29Z

model/browser/events.yaml

+    name: browser.user_action
+    brief: >
+      This event describes actions performed by the user such as click, scroll, zoom, resize, etc.
+    body:


I would like to see a comment here to clarify that this is temporary or that this will actually be an attribute. That way readers do not expect to find content in the actual body.

breedx-splk · 2025-03-04T22:46:50Z

model/browser/events.yaml

+        - id: element
+          type: string
+          stability: development
+          brief: Target element tag name and it is obtained via event.target.tagName.


Suggested change

brief: Target element tag name and it is obtained via event.target.tagName.

brief: Target element tag name and it is obtained via `event.target.tagName`.

breedx-splk · 2025-03-04T22:51:29Z

model/browser/events.yaml

+        - id: click_coordinates
+          type: string
+          stability: development
+          brief: Click coordinates captured as a string in the format {x}X{y}.
+          requirement_level: recommended
+          examples: ["345X23"]


Is this specific enough? Should this also specify if the coordinates are relative to the element or the page or the window or ???

breedx-splk · 2025-03-04T22:51:37Z

model/browser/events.yaml

+  - id: event.browser.user_action
+    stability: development
+    type: event
+    name: browser.user_action


Do we think there's an opportunity to use another prefix/namespace other than browser? It seems like this is something that mobile (ios/android) could certainly also benefit from as well. If we can't make it broader to support multiple clients, then I fear we will encounter duplication later. I also undertand if the answer is "no, it doesn't make sense because browser already has all this stuff (eg. element xpath below, etc)"...but I think we should at least consider it.

Possible alternative namespaces: client.user_action, app.user_action, ux.action...

Maybe, but that is a larger discussion for the Client SIG. We can always deprecate this event in favor of any stable standard. But generally it would be "nice" to have to define a commonly used event once -- but there are some very browser centric definitions here at the moment.

breedx-splk

I think this is good, especially as a first pass "development" event, thanks! I left some comments and think there is room for improvement and possibly sharing/broadening, but I don't want those to block. Thanks for making this bite-sized!

trask · 2025-03-11T17:54:29Z

model/browser/events.yaml

+      stability: development
+      type: map
+      fields:
+        - id: element


let's try to follow attribute naming guidelines since we'll be moving these to (complex) attributes in the future

Suggested change

- id: element

- id: element.tag.name

@trask Sorry No!
These are NOT top-level attributes and do not (and should not) conform to the full attribute naming guidelines (ONLY top-level attributes should and MUST conform to that specification) -- NOT the contents of the body / value of a complex attribute.

If / when the body becomes a standard complex attribute then there will need to be a convention in place about how these event specific attributes are named, which will most likely need to include the actual event name as the prefix (browser.user_action.[payload/data] -- for a single complete attribute).

Then there is just the overhead of creating individual on-off fields (only used for a single event) and going through the approvals / discussions about each individual field and how it can / should be made generic. Vs having a single discussion about the "naming" of fields within a specific event. If / When the community decides that they want to reuse the same type of "thing" identified by the individual event specific name, then at that point for those few fields (like the already defined url.full) it makes sense to have the broader naming / namespace discussions and then the event specific "changes" to pass that value as a top-level attribute rather than in the single value body / payload complex attribute.

While I know there has been discussions about "allowing" complex types to be defined as individual fields but sent in a complete manner, this is would not scalable and would also mean that for every event specific field for every event the names would become something like browser.user_action.XXXX, so not whenever an event has to be constructed the these long attribute names have to be constructed (and destructed -- for transport). This WILL result in

larger code sizes (if these are included in the global semantic conventions and consumed) -- yes instrumentations could construct by thats another issue

larger install sizes (for servers) if these are now included in the global semantic conventions

More CPU used in constructing these events (to create the log record) and then even more to convert and send them

More memory usage in generating these events

More storage costs for these events (as browsers will generate billions/trillions of these events), a single user will generate hundreds of these events in a single session and large sites have 100's millions of daily users

Additional, part of the reason that the browser environment NEEDS to keep these in a single location is because

(already mentioned but) These are specific and unique to each event and should only be compared against other events with the same name it does not need to be elevated to a top-level attribute

These need to be kept as small as possible as this is specific for an environment that has extremely strict size, memory, network bandwidth constraints

If / when this moves from body to a single complex attribute whose value contains these, then again it doesn't need to have a full namespace.

The client Sig spent months defining the "common" set of values for the event payloads based on different companies (well before some of the attributes became stable and renamed (like the url.* discussions), so while moving "some" of the fields to top-level attributes, most of the fields should not.

I'm not proposing a top-level element.* namespace, this would still be under the browser.user_action complex attribute in the future, e.g. browser.user_action.element.tag.name

I'm ok with keeping this as just element

on further discussion in client SIG meeting, let's go with tag.name

(we can't have both .element and element.id)

@breedx-splk , based on us changing this from a browser focus to a generic user focus is element the correct description of the "thing" being tracked here?

I know for .NET there is no "Element" (so the tag name is not relevant as it's more "type" (button, text box)) but it does have an id for the GUI object...

Originally (years ago), we started out calling this target. So really looking for input on a generic name that would work for most languages / frameworks.

trask · 2025-03-11T17:54:54Z

model/browser/events.yaml

+          brief: Target element tag name and it is obtained via event.target.tagName.
+          requirement_level: recommended
+          examples: ["button"]
+        - id: element_xpath


Suggested change

- id: element_xpath

- id: element.xpath

Some of the documentation (if you care to read) around how we got to these names in the client SIG are located in the Archived section of the Client SIG meeting notes this inlcudes documents and spreadsheets used to get consensus on names to be used

If your objecting the the _ then I would propose using just xpath

model/browser/events.yaml

trask · 2025-03-11T18:00:15Z

model/browser/events.yaml

+          type: enum
+          members:
+            - id: clickleft
+              value: "cl"


is cl an existing abbrevation defined somewhere (e.g. a browser spec)? thanks!

trask · 2025-03-11T18:01:52Z

model/browser/events.yaml

+            See enum [here](https://github.com/microsoft/ApplicationInsights-JS/blob/main/extensions/applicationinsights-clickanalytics-js/src/Enums.ts) for potential values we could add support for.
+          requirement_level: required
+          examples: ["cl"]
+        - id: click_coordinates


what do you think about

click.x

click.y

or is {x}Y{y} a browser spec thing? thanks

We had this discussion in the Client Sig when we came up with this name, it went through many iterations and we settled on a single field formatted in this manner so that backends (and users) can add any processing they want around this vs the overhead of populating, sending, storing and processing of individual fields.

For reference, the Android MotionEvent provides x and y as separate fields. https://developer.android.com/reference/android/view/MotionEvent

discussion in SIG meeting leaning towards 2-value number array

Karlie-777 · 2025-03-12T19:03:23Z

model/browser/events.yaml

@@ -0,0 +1,82 @@
+groups:
+  - id: event.browser.user_action


May use client?

Karlie-777 added 2 commits February 25, 2025 17:08

add browser user action events

39243d9

update

4971c2d

Karlie-777 requested review from a team as code owners February 26, 2025 22:44

Karlie-777 and others added 4 commits February 26, 2025 14:44

Merge branch 'main' into karlie/browseruseraction

58bf03b

update

750650f

update

2de2559

update

1621e7e

Karlie-777 commented Feb 26, 2025

View reviewed changes

breedx-splk reviewed Mar 4, 2025

View reviewed changes

breedx-splk approved these changes Mar 4, 2025

View reviewed changes

Merge branch 'main' into karlie/browseruseraction

2d284b7

breedx-splk mentioned this pull request Mar 4, 2025

Add Browser Exception Event #1942

Open

3 tasks

MSNev approved these changes Mar 11, 2025

View reviewed changes

trask reviewed Mar 11, 2025

View reviewed changes

Karlie-777 commented Mar 12, 2025

View reviewed changes

model/browser/events.yaml

@@ -0,0 +1,82 @@

groups:

- id: event.browser.user_action

Copy link

Author

Karlie-777 Mar 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May use client?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Browser UserAction Event #1941

Add Browser UserAction Event #1941

Karlie-777 commented Feb 26, 2025

Karlie-777 Feb 26, 2025

breedx-splk Mar 4, 2025

breedx-splk Mar 4, 2025

breedx-splk Mar 4, 2025

breedx-splk Mar 4, 2025 •

edited

Loading

MSNev Mar 12, 2025

breedx-splk left a comment •

edited

Loading

trask Mar 11, 2025

MSNev Mar 12, 2025

trask Mar 12, 2025

trask Mar 18, 2025

trask Mar 18, 2025 •

edited

Loading

MSNev Mar 18, 2025

trask Mar 11, 2025

MSNev Mar 12, 2025

trask Mar 11, 2025

trask Mar 11, 2025

MSNev Mar 12, 2025

breedx-splk Mar 18, 2025

trask Mar 18, 2025

Karlie-777 Mar 12, 2025

	brief: Target element tag name and it is obtained via event.target.tagName.
	brief: Target element tag name and it is obtained via `event.target.tagName`.

Add Browser UserAction Event #1941

Are you sure you want to change the base?

Add Browser UserAction Event #1941

Conversation

Karlie-777 commented Feb 26, 2025

Changes

Merge requirement checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

breedx-splk Mar 4, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

breedx-splk left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trask Mar 18, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

breedx-splk Mar 4, 2025 •

edited

Loading

breedx-splk left a comment •

edited

Loading

trask Mar 18, 2025 •

edited

Loading