Privacy Defaults

Vizoalica is designed to collect minimal product analytics data by default.

What the browser SDK collects by default

• Page origin and path, with identifiers such as /orders/8841 replaced by :id, and the route after # for fragment-routed sites (for example /#/pricing).
• Actions: which button or link was clicked, on which page. Each records a short name taken from the control's own label (redacted, at most 80 characters), its kind, and, for links, the destination's origin and path. See what actions record.
• A boolean indicating whether a query string was present and redacted.
• Optional page title, capped in length.
• A random identifier for each page load (not stored in the browser, so it cannot link visits).
• Nothing else is written to the browser, with one exception you ask for: the optional ?vizoalica_ignore=1 switch stores the value 1 in your own browser so your own visits are left out.
• Explicit custom events created by the site owner.
• Campaign labels: the utm_source, utm_medium and utm_campaign of the landing address, cleaned and cut to 64 characters (see Campaigns and the campaign labels review). No other query value is read.
• Safe scalar custom properties after filtering.

How unique visitors are counted

The SDK stores nothing in visitors' browsers: no cookies, no local storage, no session storage. (The only exception is a switch you turn on yourself, in your own browser; see Exclude your own visits.) The backend counts unique visitors itself. For each event it computes a keyed hash of a random value for the current UTC day, the website, the visitor's IP address, and their user agent, and stores only that hash. The IP address and user agent are never stored.

Each day's random value is kept in the backend's database and deleted by the daily scheduled job once the day has ended. After that, nobody, including you, can recompute a day's hashes or link them to a visitor or to another day. This is the same approach as other cookieless analytics tools.

What this means for reports:

• One person on one website on one day is one visitor.
• The same person on two days, or on two of your websites, counts as two visitors. A range of several days adds up each day's visitors.
• Several people behind one IP address with the same browser version count as one visitor.

A signed-token website can still pass its own visitor identifier in the token (visitor_id), for example for signed-in users. Reports show that as a separate identity mode.

Whether your site needs a consent banner for analytics depends on the rules that apply to it. data-consent records the state on every event. To send nothing for a visitor who declines, do not load the script.

What is not collected by default

• Raw form input values.
• Passwords, payment data, access tokens, refresh tokens, API keys, cookies, or authorization headers.
• Full URL query values, or address fragments that are not routes (anchors, tokens, sign-in data).
• Raw page text or DOM snapshots.
• Session replay, heatmaps, or click recordings: actions are counted, with no position, timeline, or replay.

URL handling

The browser SDK minimizes URLs before event delivery:

https://example.com/pricing?token=secret&plan=pro

becomes structured data equivalent to:

{
  "url_origin": "https://example.com",
  "url_path": "/pricing",
  "url_query_redacted": true
}

The backend rejects page-view events that appear to contain unredacted query values in the path.

Actions: clicks on buttons and links

The SDK counts clicks on buttons, links, and controls that behave like them, so the console can show which are used. It is always on for a website that runs the current SDK file; there is no setting to turn it off, and consent is honored (nothing is recorded when consent is explicitly denied).

Recorded per action: the page, the control's name, its kind, and for http and https links the destination's origin and path. Names come from data-vizoalica-action, aria-label, the visible text, title, or an image's alt. They are shortened to 80 characters, and email addresses, runs of six or more digits, and token-shaped words are replaced by [email], [number], and [token], in the browser and again at the backend.

Never recorded: anything typed or the value of any field, text inputs, passwords, payment fields, link queries and fragments, mailto: and tel: addresses, cookies, positions, or element identifiers. Site developers exclude a control or an area with data-vizoalica-ignore, and name a control with data-vizoalica-action (see the Browser SDK).

Identifiers in paths are grouped before storage (/orders/8841 is stored as /orders/:id), so record identifiers, which can be personal data, are not kept. The action collection review records the purpose, retention, and access boundary of each new field. Reports show aggregates only, never a visitor identifier.

Custom property rules

Custom event properties are limited to safe scalar values. Property names that look sensitive are rejected or removed, including names containing:

• password
• secret
• token
• api_key
• authorization
• cookie
• email
• phone
• credit_card
• card_number

Unsafe example:

client.track('signup_click', {
  properties: {
    plan: 'pro',
    password: 'do-not-send',
    accessToken: 'do-not-send'
  }
});

Safe example:

client.track('signup_click', {
  properties: {
    plan: 'pro',
    billing_period: 'annual'
  }
});

Backend enforcement

Client-side filtering is a convenience, not a trust boundary. The ingestion backend also validates privacy defaults before persistence and rejects events that contain sensitive-looking fields or unredacted URL query values.

Location

Only the visitor's country is recorded, as an aggregate count. The console shows it by full name and groups it by continent. Nothing finer (region, city, or language) and nothing about people (age, gender, interests) is collected. The audience attributes review records the decision for each and the conditions under which any of them could be considered later.

Deleting data

Deleting a website or project in the console is permanent. Events for it are rejected at once, and the daily cleanup removes its raw event batches and every database row for it, including its audit entries. pnpm vizoalica purge-deleted does the same immediately. Data that was never deleted follows the retention settings in the backend guide.

Logging

Operational logs and metrics must use safe reason codes and counts. They must not include raw event payloads or visitor-sensitive values.

Access keys and environments

Owner and analyst access keys are operator credentials, not visitor data, but they govern who can reach visitor aggregates. Each key is valid only for the one backend environment it was issued from; neither role can ever reveal the admin key, the website's signing secret, another key, or a raw credential hash. See the access keys review for the full decision record.