Instrument browser app screen url

[mquentin]

Problem statement

So I am looking for a specific OTel RUM instrumentation: I need to know on which screen/page a click interaction happened.

For now we have app.screen.name and app.screen.id which is great as it is agnostic of any browser and mobile context. However for a browser app, I do not see yet a proper way of instrumenting the location.href of my screen.

In the example of a click interaction, I cannot leverage the url.full to hold my location.href as my click did not trigger any network call and therefore the url.full: Absolute URL describing a network resource does not make sense.

Suggested solution

I am suggesting we introduce a new app.screen.url.full field. This field can also match a Mobile context given that a lot of Mobile apps contain webviews and therefore can also have a screen.url.

Like this one can have a app.screen.name: Login and also have a more specific field such as app.screen.url.full:www.myfullurl.com/path?param1...

This would also enable some url browser processor such as https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/web-common/src/SessionLogRecordProcessor.ts that would automatically populate the app.screen.url.full with the browser API location.href without requiring users to configure any app.screen.name.

Alternative solution

An alternative would be to update the definition of url.full to be more permissive and allow holding network or location urls.

[mquentin]

Update:

Following the browser SIG, a couple of options where mentioned such as app.url.full but did not resonate much for browser developers. Given the existing Android and iOS namespaces and the couple of use-cases envisioned such as browser navigation type instrumentation it started to make sense to introduce a dedicated namespace browser. Following the SIG recommendation, for this specific issue here, I will work on introducing a new field browser.url.full.

[thompson-tomo]

Have we considered app.screen.path as I suspect we could better reusage of that and we maintain the browser namespace for describing the platform rendering the webpage.

[martinkuba]

@thompson-tomo We agreed on using the browser namespace for the following reasons

• web developers tend to think in terms of pages or documents, not app or screen
• the concept of app.screen is different in what it represents for mobile
• we feel there might be other browser-specific attributes that warrants having its own namespace
• these will be experimental, so we can start with browser and switch to more generic attributes later once we have a better understanding of different use cases