What we collect, what we discard, and who can reach it

Data minimisation by default

The cheapest way to protect data is not to hold it. These are defaults, not options you have to find.

• Request bodies, authentication headers and cookies are never stored
• Query strings are read from a campaign allowlist — utm_*, gclid, msclkid, fbclid — and unknown parameters are discarded or redacted rather than persisted
• Route templates replace identifiers in paths, so /orders/883729 is stored as /orders/:id and /users/8273 as /users/:id
• Raw IP addresses are not retained in analytics storage; derived signals such as country are stored instead
• Secrets, tokens and email addresses embedded in URLs by a customer's own application are redacted on ingest rather than archived

Why route normalisation matters more than it sounds

A URL is the most common accidental leak in analytics. Password reset links, invite tokens, pre-filled email addresses and order numbers all end up in paths and query strings, and a product that stores raw URLs stores all of them indefinitely.

Normalising to a template also collapses cardinality, which is why the page report stays readable on a site with two million order pages. The privacy benefit and the performance benefit are the same change.

Collection modes

Identity is a configuration decision, and the lowest setting is genuinely useful rather than a token gesture.

• Minimal — no persistent visitor identifier at all. Traffic, pages, referrers, campaigns, country, device, performance and traffic quality all work
• Visit — a short-lived first-party visit key where you configure it and your policy permits, which adds journeys, funnels and visit-level conversion
• Customer — a pseudonymous account key your own application supplies, which adds trial-to-paid, customer value and cohort analysis
• No fingerprinting is used or required in any mode

Tenant and site isolation

• Events, aggregates, indexes and assembled AI context are scoped to one tenant and site
• Cross-site comparison within an organization is an explicit permission, not a default
• The AI assistant receives only data the requesting user is authorised to see — the authorisation check happens before context assembly, not after
• Nothing from one customer's account can enter another customer's analysis

Prompt injection from the open internet

Referrers, URLs, campaign names, event properties and imported text are attacker-controlled. Anyone can send your site a request with a campaign name that reads like an instruction.

• All collected text is data inside a context packet, never system or tool instruction
• A referrer or campaign name that reads like “ignore previous instructions” cannot change the AI layer's authority or which operations it may call
• The model's tool surface is the approved metric and dimension set — it cannot author arbitrary warehouse queries, so there is no query it could be talked into writing
• Permissions bind to the asking user and the task, not to anything the retrieved content asserts

AI provider transparency

• Which providers and models may process data is disclosed on the subprocessors page
• Enterprise plans restrict which providers and models may be used at all
• Customer data is not used to train shared models without an explicit agreement
• Aggregates and metric results are what reach a provider — not raw event streams

Explainability and audit

An analysis you cannot reconstruct is an analysis you cannot defend in a meeting.

• Every AI analysis persists the question, the plan, the metric calls made, the result identifiers, the provider and model, and the final answer
• Structured analysis actions and evidence are retained; model chain-of-thought is not
• Retention for events, aggregates and analysis traces is configurable, with the window stated in the DPA

Availability boundaries

• Analytics collection is written aside from the request path, never inside it — a pipeline outage does not slow your site
• The marketing site you are reading holds no secrets and never queries the analytics plane
• Deep security investigation belongs in the edge console; Reveliqo summarises security traffic for analytics rather than duplicating a WAF

What Reveliqo is not responsible for

The boundaries worth agreeing before a security review rather than during one.

• Deciding what your jurisdiction requires — Reveliqo provides collection modes, not a legal determination, and the right configuration is yours and your advisers' call
• Operating your privacy notice or consent mechanism, though with a consent platform connected Reveliqo follows the consent state configured there
• Personal data your own application places into event properties or URLs — the schema is not designed to hold special-category data
• The accuracy of data supplied by a connected commerce, advertising or finance system, which Reveliqo reports as that system defines it

Related