What a Visit Means
A visit is one page load, counted once. The number rises by one. No record linking the count to a person is created or stored anywhere in the system.
One load, one count
When asset.js fires the beacon, a single integer in the correct bucket increases by one. The incoming request is not stored as a row. There is no hit log anywhere that you or anyone else can replay, sort, or join against another table. The count accumulates; the individual signal does not persist.
The next load of the same page increments the same counter. Whether that second load comes from the same person or a different person makes no difference to the system — it cannot distinguish them, and it does not try. The counter stores the total, not the sequence of events that produced it.
What the beacon carries
The beacon includes your site key, the page path with the query string stripped, the referrer host or a direct marker, the screen-size class, and the load-speed band. None of these fields identify a person. Each one describes the visit's context — what page was loaded, from where, on what kind of screen, at what speed.
The site key routes the count to the right site's totals. The path routes it to the right page row. The referrer host, screen class, and load band slot the count into the right dimension bucket. All five fields serve counting. None serve identification.
What happens after the count is recorded
The beacon data is absorbed into the day's running totals and the individual signal is discarded. By the time the response leaves the server, there is no row representing that specific beacon. The aggregate exists; the event that produced it does not.
This is not a retention policy applied after storage. The aggregate is what is written in the first place. There is no prior step where a detail row is created and then deleted. The system's storage model is the aggregate, and the aggregate is the only output.
What a visit is not
A visit is not a session. Sessions require a timeout, a start event, and an end event — concepts that all require tracking a person across time. StatelessID has no session model. Each page load is independent.
A visit is not a unique visitor. Unique-visitor counts require recognizing the same person on a second load. StatelessID has no recognition mechanism. The same person loading the same page three times contributes three to the total, the same as three different people each loading it once. See the article on unique visitors for more detail.
Troubleshooting
If you see visit counts that seem higher or lower than expected, remember that a visit is a page load, not a person or a session. Reloading a page counts again. A visitor who loads three different pages of your site contributes three to the site total — one for each load. That is the intended behavior.
If you are testing the script and no visits appear in the dashboard, confirm that the site key in data-k matches the hostname you registered in setup. A key issued for example.com does not accept beacons from a localhost or staging hostname. Register a separate site for each hostname you want to track independently.