Analytics runs on our own machines: a Postgres database per Project, a durable log, no third-party analytics vendor in the path and no sharing of your events with anyone. This page covers the Project settings that govern data, and what to do when someone asks to be deleted.
Data settings
All of these are fields of the Project's settings object, changed with one call:
curl -X POST https://t.intelligent.page/v1/projects/acme-shop/settings \
-H 'content-type: application/json' \
-H 'Authorization: Bearer ipa_sec_REPLACE_ME' \
-d '{ "settings": {
"retentionDays": 400,
"botFilter": true,
"timezone": "Europe/London",
"allowedOrigins": ["https://shop.example.com"],
"groupKeys": ["shop", "company"],
"blockedIpHashes": []
} }'
The call replaces the settings object with the normalised version of what you send, so send the whole object rather than one field. Unknown keys are discarded, and a value that fails its rule is dropped rather than rejecting the call: read the response back to confirm what was stored.
plan may be sent in the same request but is only honoured for a platform administrator. name may be changed by any manager.
What an event actually carries
Worth knowing before a privacy review asks:
The controlling fact: almost all the personal data in a Project is there because your client put it there. Email addresses, names and account ids arrive as ids, traits or properties. If you do not want a field stored, do not send it; there is no redaction pass that will find it later.
The IP hash is what blockedIpHashes matches, which is why that setting takes hashes rather than addresses.
Bot filtering
With botFilter on, events whose user agent parses as a bot are dropped during processing, before they are committed. They still count against the rate limit, because that guard runs earlier, but they do not reach a report and they are not counted in your monthly usage, which counts what was stored.
Turn it off only if you deliberately track headless traffic, for instance a synthetic monitor whose events you want to see.
Do Not Track and Global Privacy Control
The browser tracker we run in our own product refuses to send anything when navigator.doNotTrack is 1, when window.doNotTrack is 1, or when navigator.globalPrivacyControl is true. When it refuses, no id is persisted and no session is recorded either: there is no residue.
That gate is client-side. If you write your own browser client, the same check is three lines and worth copying. The service cannot do it for you: by the time a request arrives, the signal is gone.
Consent
Consent is yours to collect and yours to enforce, because only you know what you promised. Two arrangements work:
- Do not initialise the client until consent is granted. Nothing is sent, and no id is written.
- Initialise but hold the queue, and flush once consent arrives. You keep the pre-consent events if the person agrees, and drop them if they do not.
A Project token's limited power helps here. It can write events and nothing else: it cannot read a report, list people or change a setting. A consent banner that has not yet been answered leaks nothing by having loaded the script.
Retention
Retention is the age at which events are removed from the Project. Set it to the shortest period that answers your questions. Two years of raw events is a liability, and most reporting questions are answered by 13 months.
Retention applies to events. A person's profile and a group's traits are current state, not history, and are not aged out by the same rule.
Deleting a person
There is no self-serve deletion route yet. A Project's settings surface shows the request form with submission disabled while it is being built.
Today, a deletion or export request is handled by asking us, through your usual support contact, with the Project id and the distinct id, user id or email address of the person. We remove their events, their profile and their identity mappings from that Project's database. Because each Project has its own database, the work is bounded by your Project and touches nothing else.
Two things to know while planning for that:
- Bulk deletion by rule already exists. Data Drop removes events matching a rule and is the right tool for "we sent the wrong property for a week" or "remove everything from this test account".
- Send less. The cheapest way to answer a deletion request is to have never stored the field. An opaque internal id as
uid, with the email held only in your own database, turns a deletion into deleting one row of yours.
Where the data lives
- One Postgres database per Project on our own machines. A report's connection is chosen by the credential, so no query can reach another Project: there is no join that could.
- A durable log in front of the database, so an accepted event survives a restart. Messages are acknowledged only after the commit.
- The registry (which Projects exist, their keys, members and usage) lives apart from the event data and is never reachable with a Project token.
- No third-party analytics vendor, no advertising network, and no sale or sharing of your events. The only people who see them are your Project's members and the platform operators.