Report from your own server
The beacon cannot see most of what this product exists to find. A crawler asks for the page, reads it and stops — it never runs the script, so as far as the beacon is concerned it was never there.
What only your server can see
- Visits that never run any code — most crawlers, feed readers, uptime monitors and link previewers.
- What your site answered with, including pages that were not found.
- Requests for addresses that have never existed on your site, which is what a scanner looking for a way in spends its time on.
What only the browser can see
How long a page was actually on screen, how far down it was read, whether a pointer or keyboard was ever used, and what somebody clicked. A server cannot know any of it, and nothing here pretends otherwise: it is recorded as not observed rather than as nought.
Neither replaces the other. Every visit records which surface saw it, so a verdict can be read against what that surface was able to see, and running both on one site is the arrangement this is built for.
Getting a key
In the product, open your website and choose Server keys. The secret is shown once, at the moment you create it — only a fingerprint of it is kept, so it cannot be recovered afterwards.
A key works for one website and no other. Keep it where your server runs and nowhere else: never in a page, never in anything sent to a browser, never in a repository.
Sending a report
Post a batch of up to a hundred observations, oldest first, with the key in an Authorization header. The website is taken from the key and is never read from the body.
Each observation carries the page that was asked for and, where your server knows them, the visitor's own network address and user agent — theirs, not your server's. Those two are what most of a verdict rests on, which is why the key exists.
The full description of the request, every field and what it means, is in the product's own documentation.