[Browser SIG] introduce browser.page.url.full

[mquentin]

Fixes open-telemetry/opentelemetry-browser#174

Changes

Following the 5th of March Browser SIG we identified the need of a browser.url.full. The existing url.full attribute holds network urls cf. official description

 Absolute URL describing a network resource according to RFC3986 [3]

Which does not match with a browser page location Url. As a result a RUM signal reporting a click interaction cannot rely on the url.full to report the page Url on which the click occurred.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: mquentin / name: Maxime Quentin (25452cf, 2dc6e42, 44f9503, bd05c95)

[lmolkova]

what's the conceptual difference between

Absolute URL describing a network resource according to RFC3986 [3]

and

Absolute URL of the document or page loaded in the browser according to RFC3986.

?

It's still a full URL of something following the RFC, why browser needs it's own URL ?

In terms of docs, whenever url.full is referenced on browser entities / spans / logs, its brief / notes can be refined to explain what this means in the context of browser - this is how semantic conventions are designed in general.

Unless there is a significant difference or a need to record more than one URL on the same telemetry item, we should avoid introducing new attributes.

[mquentin]

what's the conceptual difference between

Absolute URL describing a network resource according to RFC3986 [3]

and

Absolute URL of the document or page loaded in the browser according to RFC3986.

?

It's still a full URL of something following the RFC, why browser needs it's own URL ?

In terms of docs, whenever url.full is referenced on browser entities / spans / logs, its brief / notes can be refined to explain what this means in the context of browser - this is how semantic conventions are designed in general.

Unless there is a significant difference or a need to record more than one URL on the same telemetry item, we should avoid introducing new attributes.

Thanks for your feedback, let me give you some more context about these two Urls.

So the conceptual difference is that a RUM signal can have both a browser.url.full and a url.full.

The first one is related to the browser page url location such as https://github.com/open-telemetry/semantic-conventions/pull/3519 on this one page. url.full would be the url of a network request I would trigger while doing a POST http request from this https://github.com/open-telemetry/semantic-conventions/pull/3519 page. e.g. :

When I post this comment on this page, I generate an OTel signal that has:

{
   browser.url.full: "https://github.com/open-telemetry/semantic-conventions/pull/3519",
   url.full: "https://github.com/my-api-post-comment?param1=1,param2=2",
}

Indeed the description might need to be more specific, I am up for any suggestion if you have an idea. How long can an attribute description be usually ?

[martinkuba]

@lmolkova Ideally I think we would want browser.url.full (or similar) to be an entity attribute - it provides context for all telemetry signals emitted while user is viewing a given page.

Doesn't the name of an attribute need to be globally unique (unambiguous) if used as an entity attribute? What if two different entities both use an url.full attribute?

[martinkuba]

The browser entity currently has attributes that define the environment rather than the page/screen. I wonder if it would make sense to have a separate entity for page view (or navigation) rather than browser.

[mquentin]

Indeed browser looks environment related now that I have a second look at the other attributes. Naively, given that we already have #app-screen-name I would go for a new app.page.url.full which resonate quite well with the overall application entity description:

Application Attributes
Describes attributes related to client-side applications (e.g. web apps or mobile apps).
cf. #application-attributes

Would that work for you ?

[mquentin]

Update of the discussion regarding this from the browser SIG

browser.url.full, as app.page is a loaded term and can mean different things
We can probably go for browser.url.full and revisit based on user feedback

cf. https://docs.google.com/document/d/1G3yBAV5SzWBO3mmsBUos5bsn4yxsqkS1MLWl1urVojQ/edit?tab=t.0

[martinkuba]

Two weeks ago we agreed to proceed with browser.url.full for now, and make adjustments later based on feedback. I don't want to override that decision, but after some additional thought, I would recommend including page in the name for the following reasons:

• In most existing web observability SDKs, the URL is modeled as page (or view) context, and the attribute name reflects that
• browser.url.full is not a property of the platform and not specific enough to make it clear that it represents the page context

Your suggestion of browser.page.url.full seems clearer to me and avoids conflating platform metadata with page context.

[mquentin]

I agree browser.page.url.full looks a bit more self explanatory atm.
Also this page namespace is feature proof if other attributes related to the browser page need to be added. I will work on updating the PR

need to take another look based on the new information, dismissing original reivew

[github-actions]

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.