Never Sends
The beacon has five fields. Everything outside those five is never collected. No email, no name, no full URL, no cookie value, no IP address in the tracking store, no user agent string, no raw pixel resolution.
No user identity
asset.js does not read document.cookie. It does not read localStorage or sessionStorage. It does not access IndexedDB. It has no mechanism to know who is logged in to your site. HttpOnly cookies are inaccessible to JavaScript by definition — asset.js cannot read those even in principle.
No identifier of any kind — transient or persistent — is included in the beacon. The beacon carries the site key, which identifies the site. It carries nothing that identifies the person who triggered the page load.
No full URL
The query string is dropped before the path is included in the beacon. A URL like /checkout?email=user@example.com&order=99&promo=SAVE10 is recorded as /checkout. The email address, order number, and promo code in the query string never enter the beacon. They never travel from the browser to statelessid.com.
Search terms typed into a search engine before clicking through to your site arrive in the HTTP Referer header. The script reads document.referrer, extracts only the hostname (google.com, bing.com), and discards the rest. The search query is not recorded.
No browser fingerprint inputs
Browser fingerprinting uses a combination of detailed browser properties to produce a probabilistic identifier. asset.js does not collect the inputs fingerprinting relies on: it does not enumerate installed fonts, it does not render a canvas for measurement, it does not read WebGL renderer strings, it does not query audio context characteristics, it does not read navigator.plugins, and it does not access battery status.
The script reads screen.width for the class assignment and does not record the raw pixel value. It reads navigator.language for the language class and takes only the primary two-letter code. Both readings produce broad category values shared by many users — not narrow values that distinguish individuals.
IP address and server logs
Every HTTP request arrives at the server with an IP address in the network layer. That is a fact of how TCP/IP works, not something the script controls. The IP address of the machine that sent the beacon request is not written into the tracking store. It exists in server access logs managed separately from the analytics data.
The tracking store — the thing that holds visit counts — contains no IP addresses. The server access logs that might contain them are not the same as the analytics data, are not surfaced in the dashboard, and are managed under standard server log policies.
Troubleshooting
If a privacy audit tool reports that asset.js accesses document.cookie, verify by reading the live source code on the Features page on statelessid.com. The full unminified source is shown there. If the live file does not reference document.cookie and the tool is still reporting it, the tool may be using a cached copy of an older version of the script, or it may be pattern-matching on the URL rather than performing dynamic analysis. Test with the current live file in a controlled environment.
To confirm the exact beacon payload your site sends, open DevTools → Network, load a page with asset.js, and find the request to statelessid.com. Inspect the request body or query parameters. The payload is small and human-readable. Compare what you see to the five fields described in the beacon-fields article. Anything not in those five fields is not present.