The Beacon API: the quiet request that skips your consent wrapper

Published 2026-10-10

There is a request your consent wrapper probably never sees. It fires when the visitor leaves, carries analytics payloads, and is designed to survive page unload. The Beacon API exists so developers can send data as the page closes without blocking navigation. That same design makes it the quietest tracking request on most sites: it fires outside the normal page lifecycle, often after the consent logic has finished running.

How sendBeacon actually works

navigator.sendBeacon takes a URL and a payload and hands them to the browser, which delivers them asynchronously even as the document unloads. Developers use it for exactly the moments when normal requests fail: the final page-view ping, the session-end event, the "user completed checkout" signal fired from the confirmation page's unload handler. It is reliable by design, which is precisely the problem.

Most consent wrappers gate tracking by controlling script execution: block the analytics script until consent is granted, and nothing fires. Beacons break this model because the sending code is often not the analytics script at all. It is a small inline handler, a tag manager custom event, or a first-party endpoint that forwards to the analytics vendor server-side. The wrapper blocked the vendor's script, but the beacon carries the vendor's data anyway.

Why wrappers miss it

Timing is the first reason. Consent state is evaluated when the page loads; beacons fire when it unloads. A visitor who never consented, or who consented and then withdrew, can still trigger unload handlers that were registered before the withdrawal. The wrapper's job is done by then. The beacon's job is just starting.

The second reason is attribution. Wrappers classify requests by matching URLs against vendor lists. Beacon endpoints are frequently first-party: /collect, /events, /api/ping. The wrapper sees a request to the site's own domain and waves it through, never knowing the endpoint forwards everything to a third-party analytics pipeline. First-party collection with third-party forwarding is the standard architecture now, and URL-based classification cannot see through it.

Finding beacon traffic on your own site

Open devtools, go to the network tab, and navigate away from the page. Watch for requests that appear during unload. Then check the initiators: sendBeacon calls show up with the beacon type in modern devtools, and keepalive fetch requests behave similarly. Search your tag manager for unload, beforeunload, pagehide, and visibilitychange triggers, and read what each one sends and where.

Do this on the checkout confirmation page and the form thank-you pages first. Those are the pages where unload handlers are densest and where the data is most sensitive. A beacon carrying purchase details to an analytics vendor without consent is the finding that turns a routine audit into an incident.

Gating beacons the way that holds

The fix is a consent-gated queue. All beacon sends go through a single function that checks current consent state before dispatching, including at unload time. Consent withdrawal must flush or drop the queue, not just stop new entries. And the first-party endpoints need the same scrutiny as third-party scripts: document where each endpoint forwards data, and gate the forwarding on the same consent categories.

Test it the way it fails: grant consent, withdraw it, then navigate away and watch the network tab. Then test the reverse: never consent, complete a conversion, and confirm nothing leaves on unload. If your wrapper vendor claims beacons are covered, make them demonstrate it in this exact sequence before you believe them.

Common questions

Is sendBeacon itself a violation?

No. The API is neutral. The violation is sending personal data through it without a legal basis, the same as any other request. Audit the payload and the consent state, not the API.

What about fetch with keepalive?

Same treatment. keepalive fetch survives unload like beacons do, and wrappers miss it for the same reasons. Gate both through the same function.

Can scanners detect this?

Most cannot, because scanners do not reliably simulate unload behavior or consent withdrawal sequences. This is a manual-test finding. Put it in the human part of the audit checklist.

Frequently asked questions