Privacy, retention and erasure

What is observed

A visitor is a browser, never a person. Each event the tracker sends carries what the browser states about itself and the page: the URL, path, host and title, the referrer and the session's first referrer, the click ids and UTM parameters on the current URL, the screen and viewport sizes and pixel ratio, the language, the timezone offset, the user agent, plus a session id, a visitor id and any custom data your site attaches. We add the address the event came from and the time we received it. Install the tracker lists every field.

Nothing is inferred about who is behind a browser. There is no cross-site profile and no identity graph; the id is random and belongs to one browser on one device. The address is kept whole, as the connection the event arrived through, with what is published about it: its approximate location (country, region, city, postal area and timezone), the address space it belongs to, its operator, its type, and whether it is a hosting range, a VPN, a proxy, a relay, Tor or a mobile carrier. Those are attributes for you to read, and the product attaches no judgment to any of them; the Connections screen shows them.

The first-party id

The tracker sets no cookie, first-party or third-party, on any visit. It keeps a random id in the browser's own storage, telling repeat visits from the same browser apart; it lasts until the visitor clears their storage. A second random id groups one browsing session's events and ends with the tab. The visitor id goes with the events to us and nowhere else. When storage is blocked, events go out without a visitor id. What it stores in the browser lists the three keys.

Consent

Your cookie banner is yours. The tracker reads no consent platform and never waits for a choice; the one way a choice reaches the product is the consent_update call, which Site settings hands you on its Installation page under "Events you send", in the "Consent" row:

window.iads('consent_update', {
  analytics: true,
  marketing: false,
  action: 'custom',
})

The row's help reads The visitor's choice on your own banner, recorded as an observed signal. It does not change what is collected. That is the whole rule: consent_update is an observed signal, not a permission for Intelligence/Ads. Page views, clicks and scrolls keep being sent whatever the choice was; the legal basis for collection sits with the site that installs the tracker.

What is recorded: analytics and marketing when they are exactly true or false, otherwise unknown; action when it is accept_all, reject_all or custom, otherwise unknown. When the site has reported one, a visitor's latest choice shows on its screen as a "Consent" chip, Marketing and Analytics each read as granted, denied or unknown. The tracking API covers the call in full.

Retention

The Privacy page of Site settings opens on "Retention", whose line reads How long this site's events are kept. Its one row, "Event history", shows Unlimited, with the help Kept for as long as the site exists, on every plan. Your plan decides how far back you can read, never what is stored.

Retention is unlimited on every plan. Every event we accept is kept; nothing expires on a timer and nothing is discarded to make room. What a plan governs is what you can read:

• The window, how far back a screen may read: 7 days on Free, 30 on Starter, 92 on Solo, 365 on Growth, 730 on Agency and 3,650 on Enterprise. Raising the plan reveals history that was always there, at once. Plans and billing has the grid.
• The event allowance, which gates the read, never the write. On Free, a month past its allowance has its tail withheld from the screens until the plan rises; on Starter through Agency nothing is withheld and the overflow is billed at €5 per started block of 10,000 events, and never more in a month than the next plan's monthly price (€49 on Starter, €99 on Solo, €249 on Growth and on Agency); on Enterprise the contract governs. Over the allowance says what each state shows.

Deleting a site is an erasure too: its events are erased (Site settings). A tag left in place keeps sending events under the old ids until it is removed. To stop collection while the site exists, turn off "Accept incoming events" on the Data collection page of Site settings.

Erase a visitor

You are the controller of the data about your site's visitors and Intelligence/Ads is the processor, acting on your instruction. A visitor's deletion request therefore goes to your site first, and you pass it on here.

The Privacy page's second section, "Erase a visitor", is lined Honour a deletion request from one person who visited this site. Its row, "Visitor ID", takes one id, and a "Request erasure" button stays disabled until something is typed. Pressing it turns the control into a red "Erase this visitor" with a "Cancel" beside it and the caption Every event of this visitor on this site, and its pin and note, will be deleted. This cannot be undone. Confirming records the instruction: the field clears and the line Instruction recorded — it appears in the ledger below shows.

The id to paste is the one the visitor's own screen shows under its title: the first twelve characters are printed, and the copy control beside them copies the whole id (One visitor). An id is between 1 and 64 characters.

• Who: an owner or an admin of the workspace. A member does not reach Site settings. The plan is not consulted: a Free workspace instructs an erasure like any other.
• What it covers: every event of that one browser on this site, and its pin and note. Nothing else. The daily baselines hold nothing that singles a browser out and are not touched.
• Twice: asking again for a browser whose instruction is still Instructed shows that instruction rather than adding a second.
• When: the instruction is recorded at once and the rows are gone after a later pass. Events from the last hours can take longer, which is why a new row reads Instructed rather than Erased.

The ledger

The page ends on a panel titled "Erasure instructions", with N on record at the far end of its bar when there are rows, filtered to this site. The same panel, unfiltered, sits on Workspace settings → General under "Erasure" (Workspace settings). Both are owner and admin surfaces and list the newest instructions first.

Each row names its subject the way the instruction was given, Browser followed by the visitor ID or This workspace, and carries a status pill at the right:

Under the subject, an Instructed row reads Instructed, the date it was recorded, and runs on the next pass; an Erased row reads Erased and the date; a Not completed row reads We've been alerted and it will be retried.

An empty ledger reads No erasure instructions on this site (or on this workspace) over Every event stays until someone asks us to remove it. When that happens, the instruction and what became of it appear here. When the read fails, the panel says The ledger could not be read just now and reminds you that instructions already given are unaffected.

Deleting a workspace

The other instruction is the workspace's own deletion, on Workspace settings → General, in the owner-only Danger zone: "Delete workspace", then a red confirm that names the workspace ("Delete", its name, "permanently"). The row's help reads Permanently removes the workspace and every membership in it. Its sites and their data stop being reachable in the product. Your personal workspace cannot be deleted; its row explains that instead of offering the button. A workspace with an active subscription is refused with a message to cancel it first in Billing → Manage billing. Workspace settings covers the screen.

Access ends at once and every event the workspace produced is erased on a later pass. This instruction's row is not readable in the product: the workspace and its memberships are gone, so no one is left who could open a ledger for it. Deletion does not uninstall your tag; remove it from the site.

What this page does not do

• It deletes nothing on its own. Retention is unlimited; every removal exists because someone asked for it.
• It takes two instructions and no other: one browser on one site, or a whole workspace (deleting a site, on Site settings, is the third). There is no erasure by address, by session, by campaign or by date.
• It shows no operator internals. The ledger carries the subject, the status and one date.
• It never hides. The panel renders when empty, and Not completed is named plainly.
• It gates nothing on consent, and nothing on the plan. A banner's choice is a recorded signal; an erasure is open to a Free workspace as to any other.
• It offers no undo. The confirm says so.