Event Limit
asset.js sends exactly one beacon per full page load. No second beacon fires on scroll, click, time on page, or visibility change. An optional script-error signal is separate and capped at one per load.
One load, one beacon
The beacon fires once, when the page reaches DOMContentLoaded. It does not retry on network failure. It does not queue. If the network is unavailable at that moment, the beacon does not fire and the visit is not counted. There is no local buffer that replays missed beacons on the next page load.
The design intent is accurate counts of page loads under the conditions that existed at load time. Retrying would inflate counts by counting a single page load multiple times. Not retrying means a visit that could not send the beacon is simply not counted — the count is a minimum, not an estimate.
No interaction events
The script does not attach event listeners for clicks, scrolls, form submissions, mouse movement, video plays, or any other user action. The visit count in your dashboard represents page loads, not interactions. If you need to count button clicks or form completions, that is a different implementation outside the scope of what this script does.
There are no custom event calls in asset.js. You cannot call a tracking function from your own code to add a second event for the same page load. The script's API is the script tag itself — one tag, one load, one beacon.
Script-error signal
asset.js can optionally capture uncaught JavaScript errors through window.onerror and send a companion signal alongside or shortly after the main beacon. That signal contains one field: the page path where the error occurred. No error message, no stack trace, no variable values, no error type. The count that appears in the Errors section of the board comes from this signal.
The error signal is capped at one per page load. If multiple uncaught errors fire on the same page load, only the first triggers the signal. The page path is recorded once. The board shows how many page loads produced at least one uncaught error — not how many individual errors occurred across all loads.
Why one event per load
The design goal is a count of how many times each page was loaded, under what conditions. That question is answerable with one beacon per load. Answering richer questions — which links are clicked, how far down visitors scroll, what sequence of pages they visit — requires a richer data model, specifically a hit log or session table. This system intentionally has neither.
The limit on events per load is part of what keeps the stored data at the aggregate level. One beacon per load plus aggregation at write time means the data that reaches the store is already a count, not a list of events that could be re-explored.
Troubleshooting
If visit counts seem higher than expected for a page, remember that any full page reload generates a new beacon. Single-page application navigation that updates the URL with the History API without a full reload does not generate a new beacon automatically. If your framework performs a full document reload on internal navigation, each navigation produces a beacon.
If the Errors section shows counts but you are not aware of JavaScript errors on those pages, the errors may be from third-party scripts loaded on the same page. window.onerror catches uncaught errors from all scripts, not only your own code. The error signal records the page path, not the script that threw the error.