Skip to content

Conversation

@martinkuba
Copy link
Contributor

@martinkuba martinkuba commented Feb 15, 2025

Changes

This adds a new event for capturing the page view event from browser/web applications.

Related to open-telemetry/opentelemetry-browser#13

Merge requirement checklist

@martinkuba martinkuba requested review from a team as code owners February 15, 2025 19:39
@jsuereth jsuereth moved this from Untriaged to In Review in Semantic Conventions Triage Mar 4, 2025
@github-actions
Copy link

github-actions bot commented Mar 6, 2025

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Mar 6, 2025
@github-actions
Copy link

Closed as inactive. Feel free to reopen if this PR is still being worked on.

@github-actions github-actions bot closed this Mar 13, 2025
@trask trask reopened this Mar 13, 2025
@trask trask removed the Stale label Mar 13, 2025
@github-actions
Copy link

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Mar 29, 2025
@github-actions
Copy link

github-actions bot commented Apr 5, 2025

Closed as inactive. Feel free to reopen if this PR is still being worked on.

@github-actions github-actions bot closed this Apr 5, 2025
@lmolkova lmolkova reopened this Apr 5, 2025
@lmolkova lmolkova removed the Stale label Apr 5, 2025
@github-actions
Copy link

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Apr 21, 2025
@trask trask removed the Stale label Apr 21, 2025
@github-actions
Copy link

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label May 15, 2025
@github-actions
Copy link

Closed as inactive. Feel free to reopen if this PR is still being worked on.

@github-actions github-actions bot closed this May 22, 2025
@martinkuba martinkuba reopened this Jun 17, 2025
@martinkuba martinkuba requested a review from a team as a code owner June 17, 2025 15:31
@github-project-automation github-project-automation bot moved this from Awaiting codeowners approval to Blocked in Semantic Conventions Triage Aug 6, 2025
@lmolkova lmolkova moved this from Blocked to Awaiting codeowners approval in Semantic Conventions Triage Aug 6, 2025
@martinkuba
Copy link
Contributor Author

I have made a few changes based on feedback:

  • switched from using body fields to attributes
  • all new attributes are in the browser.* namespace
  • for the URL field, I am now using the existing url.full attribute
  • renamed page_view.title to page.title , since that seems to be really a property of the page
  • updated the type enum to use human readable values (page_load and soft_navigation - I felt these make most sense, but open to other ideas)

There are a couple of things that still need to be resolved

  • per @david-luna’s comment, the page title attribute could contain PII values, which complicates the instrumentation. It is also not clear if it provides much value. I am open to removing it (at least for now). lmkwyt
  • I think the change_state attribute needs clarification. Is it intended to capture the mechanism of how the URL was changed or whether the new URL was added to the history stack? There are other ways of changing the URL than using the history API, so if it complicates things, I am also open to removing this for now.

Comment on lines +63 to +82
- id: browser.page_view.type
type:
members:
- id: physical_page
value: page_load
stability: development
brief: >
Initial page load within the browser which will generally also
precede a PageNavigationTiming event.
- id: virtual_page
value: soft_navigation
stability: development
brief: >
This is for Single Page Applications (SPA) where the framework
provides the ability to perform client side only page
"navigation", the exact definition of what a virtual page
change is determined by the SPA and the framework it is using.
stability: development
brief: Type of navigation
examples: ["page_load", "soft_navigation"]
Copy link
Contributor

@thompson-tomo thompson-tomo Sep 2, 2025

Choose a reason for hiding this comment

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

Similar to the other comment, I feel browser.page.view_type or browser.document.view_type might be a better fit as it is describing the page being shown in the browser.

Choose a reason for hiding this comment

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

similar here

Copy link

@joaquin-diaz joaquin-diaz Sep 2, 2025

Choose a reason for hiding this comment

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

I wouldn't go with browser.document.view_type, I think we should reserve that namespace for attributes that are coming from window.document so it's easier to understand where is that coming from. I agree that it makes sense for referrer to be browser.document.referrer

It looks like we're dealing with two namespaces here:

  • page
  • page_view

Maybe having a proper definition of what they are can help assigning the attributes. If I have to give it a go I would say:

  • page_view: it represents the action of navigating to a certain URL, whether is a full load (cold start) or soft navigation (like in SPAs)
  • page: it contains information of the current page that the user is seeing in the browser, such us URL, title, etc

Having said that I think here we're trying to describe the navigation type, so I agree that it should be in the page_view namespace

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with @joaquin-diaz, the intent is to describe the type of navigation. Page itself does not have a type, especially when the values are either "page_load" or "soft_navigation". Maybe rename to browser.navigation.type?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree the page doesn't have a type hence suggestion was view_type but I do like your suggestion of browser.navigation.type as it is clear what it is describing.

Choose a reason for hiding this comment

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

Agree, I also like browser.navigation.type

Choose a reason for hiding this comment

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

Same. There are other nav types: reload and back_forward. What about:

load
soft
reload
back_forward

Copy link
Contributor

@thompson-tomo thompson-tomo Sep 11, 2025

Choose a reason for hiding this comment

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

@martinkuba did we want to go with the change to browser.navigation.type especially as it would also potentially allow the additional types

Copy link
Contributor Author

@martinkuba martinkuba Sep 11, 2025

Choose a reason for hiding this comment

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

We discussed this in the SIG meeting last week and decided to keep it like this. Navigation type already exists in the navigation API, so did not want to overload it.

We might want to add navigation.type attribute in the future, but it would have this other meaning (captured from navigation.activation.navigationType).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: In Progress
Status: Awaiting codeowners approval

Development

Successfully merging this pull request may close these issues.

9 participants