Conversation
The element and the kind of interaction INP was reported on only exist in the span's name and op today. That makes them unavailable to anything that reads attributes, and it cannot express an INP that web-vitals reports without an interaction, which still gets a span name and a `ui.interaction.click` op. Explicit attributes can simply be omitted then.
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Attributes
Other
Internal Changes 🔧Deps
🤖 This preview updates automatically when you update the PR. |
The web vital attributes are named after the field of the performance entry they come from: `lcp.element` after `LargestContentfulPaint.element`, `cls.source` after `LayoutShift.sources`. For INP that field is `PerformanceEventTiming.target`, which is also what web-vitals and the product call it.
logaretm
changed the title
There was a problem hiding this comment.
Generally fine with this but to think about: We have a browser.web_vital.lcp.element attribute. Does it make sense to rename this to browser.web_vital.inp.element?
Somewhat related, I'm planing on adding a ui.element.selector attribute to generically capture selectors but this likely doesn't fit here, given the target could also be a component name. Does that make sense to you?
There was a problem hiding this comment.
actually, on second thought, "target" is probably more fitting for using it interchangeably on selectors or component names. I'll probably go with ui.element.target myself
2 participants
The element and interaction type INP was reported on only exist in the span's name and op, I think it's a bit of a guess-work and is subject to breakage if we decide to rename span name/ops, an explicit attributes makes the most sense here.
I propose defining
browser.web_vital.inp.targetandbrowser.web_vital.inp.interaction_typeas attributes the SDK can send optionally when they are known.