Private betaRequest early access →

Sign in

Website analytics and your privacy

Zynth's public website measures its traffic the same way we build everything else: fail-closed, minimal, and honest about limits. This page states the complete data flow — what is processed, what is stored, and what is deliberately impossible — so the claim "privacy-first analytics" is checkable rather than decorative.

What we never do

  • No cookies, no localStorage identifiers. Nothing is placed on your device. There is no consent banner because there is nothing to consent to storing. (Signing in to the console is a different matter: it uses one strictly-necessary cookie, described in the Privacy Policy.)
  • No fingerprinting. We do not combine device characteristics to re-identify you.
  • No identifier on your device, and no persistent profile. Visitors are counted using a salted hash of values we do not store, and the salt rotates, so a returning visitor is recognised only within that rotation window. A "journey" in our analytics is the pages of one visit, never a person's history.
  • No advertising or third-party analytics. Measurement is self-hosted on our own infrastructure, in the same jurisdiction as the rest of the platform. No visitor data is shared with, or enriched by, any third party. One narrowly-scoped exception exists and is stated below rather than hidden: our operators can optionally have an AI model write a prose summary of the aggregate numbers. What that feature sends off-box is counts and our own category names (for example "27 crawler requests were served") — never a page you visited, never your browser details, never anything a visitor supplied. With the feature off (the default), nothing leaves our infrastructure at all.
  • No fine-grained location in our reports. Our reports show location at country level only. The tracker's own store can hold a region and a city where its location lookup supplies them; it never holds the IP address they were derived from.

What is processed, precisely

Two measurement paths exist, and each states its own limit:

Client-side (the tracker). A small script reports the page viewed, the referring site, and standard browser context (browser, operating system, device class, screen size, language). At ingest, your IP address is processed transiently — it contributes to the rotating-salt visitor hash and to a location lookup — and is not stored. What is kept: the pageview, the derived location (country, and region or city where the lookup supplies them), and the anonymous visitor hash.

Server-side (the edge log). Our web server keeps an access log of requests — the page, the status code, the self-reported client name (user-agent), and the referring site. IP addresses and identifying headers are deleted before the log line is written. This log exists mainly to measure AI-crawler traffic, which never runs the client-side tracker.

Retention

The analytics store built from the web-server log is purged automatically after 400 days. The tracker's own records (page views and visit sessions) are kept until we delete them; no automatic expiry is set on them. There is no raw-IP store to retain or delete in either: the address is gone before anything is written.

Why this matters for you as a customer

The same posture applies to the Perihelium platform itself — data minimisation, deletion at the edge, and honest labels on every metric are design rules, not marketing. If your compliance review needs this page's claims in writing, they are verifiable in the open: the measurement stack is self-hosted Umami plus an edge pipeline whose filter list is version-controlled and reviewed like any security change.

The early-access form

The private beta's early-access page is the one form on the marketing site, and it is ours end to end — no third-party form service, no mailing-list provider. What it collects, why, and how it is erased:

  • Collected: who you are (name, work email, role, organization), what the application is (name, URL, description, stage, platforms), what you would connect and what you want to test, expected scale and timing. Nothing else is stored with the request, and no cookie is set. One thing is stored beside it: the submission is recorded as a security event in the platform's event store, and that event carries the IP address it came from — the same abuse-detection record every sign-in and sign-up produces. The event is purged after 30 days and is not linked back to the application once it is gone; the edge log's own retention is described above. The beta selects applications that can test the platform seriously, which is why it asks this much and no more.
  • Consent, and a separate acknowledgement: two boxes, both unchecked until you tick them, and the request is refused without either. The consent covers what we store and why; the acknowledgement records that you understand the service is a private beta operated AI-first — it may change or be interrupted without notice, carries no service level, and you are responsible for backing up your own data. Each record stores when and which version of the wording you saw.
  • Purpose: one — contacting you about the private beta. It is written on the record.
  • Retention and erasure: held until you are invited, declined, or ask to be removed. Erasure is a hard delete of the request and its consent record; email sales@zynthmedia.com (the address the page names). The audit log keeps only an opaque row id, never the address.
  • Abuse protection: the door is rate-limited per source and globally, fails closed, and refuses disposable email domains — the same screening as agent onboarding.

The documentation assistant

The documentation site's Ask AI (in the search palette) is the one place a visitor's own words leave our infrastructure. When you ask it a question, the question you typed and the documentation excerpts retrieved for it are sent to our AI provider — named, with its processing location, on the sub-processors page — to generate the answer. Nothing else goes with it: no account identity, no cookie, no IP address. Your IP address is used only for an in-memory rate limit on the docs server and is never written down. Treat the question box like any third-party AI service: do not put personal data in it.

The same provider, under the same entry, also generates the optional prose summary of aggregate analytics described above (counts and category names only) and narrative assessments of security detections inside the platform's own console, when an operator has enabled it. Those assessments are written from rule names, severities, counts and times: the IP address or account a detection is about is replaced by a pseudonym before anything is sent, so the provider never receives it, and the real value is restored inside the platform before the summary is shown. That is why its sub-processor entry names all three flows, and not only this one.