Small counts, voluntary enquiries

Application measurement: pageviews, not people

Our first-party measurement adds a pageview to a UTC-day total for a known public page and a broad referrer category: direct, internal, search, social or other. It does not create visitor IDs, hash IP addresses, store raw IP addresses or user-agent strings, or retain full referrer URLs, query strings or fragment identifiers in the analytics file. There are no external analytics scripts, tracking cookies or localStorage identifiers in this measurement.

The browser classifies a referrer locally before sending the category. The server briefly checks the user-agent header for common bot signals, then discards it rather than storing it in analytics. We honor Do Not Track and Global Privacy Control signals by skipping measurement. A short aggregate rate counter limits writes without identifying visitors.

These are pageviews, not people or verified human visits. Reloads and repeated visits can count again. Blocked or disabled JavaScript, privacy preferences, failed beacons and rate limits can lower counts; undetected bots or automated submissions can raise them. Referrer restrictions and incomplete search-engine recognition also affect categories. Missing measurement is not evidence of zero readership.

Enquiries are separate, private records

If you submit a research request, we store your name, email, optional organization, research question and affirmative consent to review and reply. We add a server-generated reference, receipt time and handling status. A random submission key helps avoid duplicate records when you retry the same form; it is not used as an analytics or cross-page identifier.

Details are held in private server storage for the site operator to review and respond. They are not put into analytics or public reports. Routine owner notifications can use counts rather than contact details. No marketing subscription is created, and we do not sell enquiry details or share them with agencies for prospecting. Hosting infrastructure necessarily processes requests to serve the site.

The on-screen acknowledgement means a request was saved, not that an email was sent or a provider delivered data. There is no automatic email or data delivery attached to the form. A reply is not guaranteed. Please do not submit wallet addresses, account details, confidential documents or other sensitive information.

Retention and deletion

The application keeps at most the most recent 90 UTC-day buckets when analytics is written. Enquiries become eligible for deletion 90 days after receipt, including their retry keys. The application removes expired enquiries during subsequent intake processing or private maintenance; the operator can remove them sooner when no longer needed.

These cleanup controls are not a promise of instantaneous deletion: an inactive site or a storage failure can delay a cleanup run. Operational backups, if enabled, can retain deleted copies until their separate rotation. Any manual reply correspondence is separate from the form record. No backup or correspondence retention period is asserted here.

Hosting access and security logs

Normal web-server access and security logs may contain IP addresses, requested URLs, timestamps and browser information. Those infrastructure logs are separate from the aggregate application analytics described above and follow the server operator’s security and log-rotation controls. This notice does not claim that the whole hosting stack never logs IP addresses. Avoid putting personal information into page URLs.

Ask about, correct or withdraw a request

Use the request form to ask about privacy, request access or correction, or withdraw consent and ask for deletion. Include your saved reference, if available, and use the same email address. We may need to verify that the record is yours before disclosing or changing it. No additional marketing consent is required.