docs: use cases for the navigation event

[martinkuba]

This doc describes the data the navigation event captures and the use cases it is intended to be used for.

[BenoitZugmeyer]

💬 suggestion: From my understanding, "soft navigations" are included in "same-document" navigations. It might be easier to understand if we had a structure like this:

• Capturing hard navigations
• Capturing same-document navigations
  • Soft navigations
  • Other URL changes

[joaquin-diaz]

Given that a query string change can lead to no modification of the page content (maybe is just a way of keeping internal state), should that be defined as navigation?

[david-luna]

If I recall correctly that was the issue that made us differentiate page_view events from navigation ones.
Ref: #3

Wasn't navigation event scoped to only URL changes? (sorry for my bad memory)

[joaquin-diaz]

I also can't remember but I'm ok with it if that's what we agreed on

[wolfgangcodes]

Thank Martin! This looks great!

suggestion: a follow-on once things mature might be to add a sections to link out to relevant semantic conventions and implemented instrumentations.

That would allow us to document what the user wants to do (the use cases here), the data that drives it (semantic conventions) and the how consumers produce that data (the instrumentation).

[vigneshshanmugam]

Suggested change

	| [`browser.navigation`](navigation-event.md) | Captures a page page navigation event (both hard navigations and soft SPA navigations). | In review [PR1910](https://github.com/open-telemetry/semantic-conventions/pull/1910) | In review [PR2386](https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2386) |
	| [`browser.navigation`](navigation-event.md) | Captures a page navigation event (both hard navigations and soft SPA navigations). | In review [PR1910](https://github.com/open-telemetry/semantic-conventions/pull/1910) | In review [PR2386](https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2386) |

[vigneshshanmugam]

Suggested change

For full page loads, this event SHOULD be emitted as early as practical after the browser commits the new URL. Durations and detailed milestones for page load are captured separately by the Navigation Timing event (from the PerformanceNavigationTiming API). Navigation timing data is typically sent when timing fields are finalized (often after the `load` event), which means it may be missing if the user leaves early or if `load` never fires. The navigation event therefore provides a more reliable analytics signal, while navigation timing is used for performance analysis.

For full page loads, this event SHOULD be emitted as early as practical after the browser commits the new URL. Durations and detailed milestones for page load are captured separately by the Navigation Timing event (from the PerformanceNavigationTiming API). Navigation timing data is typically sent when timing fields are finalized (often after the `load` event), which means the event might be lost if the user leaves the page early or if `load` event never fires. The navigation event therefore provides a more reliable analytics signal, while navigation timing is used for performance analysis.