Database and compute in Amsterdam, consent required by default.
Where data is processed, what the script does before and after the visitor agrees, how long everything is kept, and who can access it.
Database and compute in Amsterdam, with Scaleway, in the European Union.
The database and the application that receives events run in the same place. Each service that processes data is listed below, with its location when specified. Depending on the feature used, Mistral may temporarily transfer data outside the European Union to the subprocessors it publishes; its data processing agreement limits these transfers to countries the EU recognizes as adequate, or covers them with standard contractual clauses. Stripe transfers payment data to Stripe, LLC, in the United States, under the Data Privacy Framework and, failing that, standard contractual clauses. Whatever region is chosen, Sentry may keep the data of Probant’s Sentry account (members, settings, audit log, project descriptions) in the United States; reported errors stay in Frankfurt.
Scaleway Always active
Hosting of the website and the application, including event collection; database; storage of images uploaded from the editor; domain names.
Location: Amsterdam, Netherlands (nl-ams region), in the European Union
Brevo Always active
Sending Probant’s emails: sign-in emails (address confirmation, forgotten password), support emails (reply notification, alert to the team), alerts for workspaces that have an “Email” destination, and the Monday update for people who receive it.
Location: European Union: servers in France and Germany, encrypted backups in Belgium (Google Cloud), according to Brevo
Mistral AI Optional
Language model behind the editor assistant, “Ask Probant”, and session summaries; optional, available to signed-in users only.
Location: European Union by default (European API endpoint), according to Mistral
Depending on the feature used, Mistral may temporarily transfer data outside the European Union to the subprocessors it publishes; its data processing agreement limits these transfers to countries the EU recognizes as adequate, or covers them with standard contractual clauses.
ClickHouse Optional, not in use
Optional storage for visitor events, replacing the Postgres table when volume requires it.
Location: Option not in use: it is not connected in production, and visitor events stay in the Postgres database, at Scaleway, in Amsterdam.
Stripe Optional
Payment for paid plans: checkout page, subscription, invoices, payment method, and cancellation (Stripe portal).
Location: Contract with Stripe Payments Europe, Ltd. (Ireland); data transferred to Stripe, LLC (United States), according to Stripe
Stripe transfers payment data to Stripe, LLC, in the United States, under the Data Privacy Framework and, failing that, standard contractual clauses.
Sentry Optional
Optional reporting of server errors, so they can be fixed.
Location: European Union: Frankfurt (Germany), including backups, according to Sentry
Whatever region is chosen, Sentry may keep the data of Probant’s Sentry account (members, settings, audit log, project descriptions) in the United States; reported errors stay in Frankfurt.
Visitor’s country: when an audience or a geo test uses it, and only then, it is read from the request’s IP address, using a table kept inside the application. The address is neither stored nor sent to a third party. IP Geolocation by DB-IP.
The data involved, service by service: subprocessors.
If Probant doesn’t respond, your site stays yours.
A Probant outage doesn’t change what your visitors see; it only costs you measurements. And your data leaves with you.
The script doesn’t block rendering
It loads without blocking rendering. If Probant does not respond, no variant is applied: your visitors see your site as it is, and only the measurements for those visits are missing.
The server helper doesn’t wait for Probant
It keeps the configuration in memory for 1 minute and waits 1 second at most for Probant. If Probant does not respond, it serves the last known configuration, or your original page if it has none, and only retries after 10 seconds.
The quota doesn’t cut anything off
Once the month’s volume is reached, your running tests and rollouts continue for all their visitors. Only new tests wait for the next month or a larger plan.
Your data goes with you
The owner can export the whole workspace at any time as a JSON file (format probant-export/1), erase a visitor’s data on request, and delete the workspace and its content when leaving.
The script waits for consent.
Requiring consent is a workspace’s default setting. The visitor’s choice is passed on every page, as soon as your consent tool knows it.
Before consent, nothing happens.
In a workspace that requires consent, until the visitor agrees, the script sets no cookie, assigns no one, applies no change, and sends nothing. If they agree once the page is displayed, it does not change in front of them: their variant starts on the next page. If they agreed on a previous visit, their variant applies on load, and nothing is sent before your consent tool confirms.
// accepted: assignment and measurement, without switching the page on screen probant.consent(true); // refused or withdrawn: cookie and local traces deleted probant.consent(false);
A refusal clears the traces.
probant.consent(false) deletes the cookie and local traces, empties the send queue, and stops observing the page, even in a workspace that does not require consent.
After probant.consent(false)
probant_idcookie deletedprobant_explocal storage clearedprobant_seensession storage clearedprobant_filepending queue cleared- send queueemptied
- page observationstopped
An opt-out link, and no exemption claimed.
A visitor can object to measurement from the site’s privacy policy, with the button Probant provides: the script, the journey module, and the server helper then assign nothing, whether or not the workspace requires consent, and a later approval from the consent tool does not lift this objection.
The self-assessment tool of the CNIL (the French data protection authority) for consent-exempt audience measurement (July 2025) lists among the features to disable by default “any creation of user cohorts to present them with differentiated content, whether membership of such a cohort is defined randomly” (our translation): that is the very principle of an A/B test. Probant therefore asks for consent by default and claims no exemption. Source: CNIL self-assessment tool (PDF, in French), checked on November 8, 2026.
Opt-out link, in the privacy policy
probant_oppositionrefusal kept 390 daysprobant_idcookie deleted- identifier’s datadeleted at Probant
- back-office orderskept, detached from the identifier
One identifier, first-party, never extended.
The script and the server helper read the same identifier: a visitor sees the same variant however they were assigned.
- Name
probant_id- Scope
- First-party to the store’s site, shared by its subdomains, SameSite=Lax, Secure over HTTPS.
- Content
- A random identifier, generated in the browser or on your server. It contains no name and no email address.
- Duration
- 390 days at most after the first visit, which is under 13 months. When your server sets it again with the server helper, it keeps the same expiry: it is never extended.
- Local traces
- The tests seen (
probant_exp, local storage) and the exposures already sent during the session (probant_seen, session storage), to attribute each conversion to the right tests.
Details of the cookies set by the website, the application, and the script: cookies.
Events are deleted after 13 months.
An event records that a visitor came, saw a variant, converted, or measured something, with the context of their visit.
What an event contains
The workspace, the type (visit, exposure, conversion, or measurement), the visitor’s random identifier, the test and variant, the metric and its value, the sent date, and the received date. The context of the visit: device type, new or returning visitor, source category, campaign, and landing page path. For an exposure, the browser family (Safari iOS, Chrome Android…), derived on receipt from the User-Agent header, which is not kept: it is used to diagnose a sample ratio mismatch. No IP address, no User-Agent header, no referrer.
The purge
Every night, events received more than 13 months ago are deleted. The date used is the receipt date, set by the server: a browser cannot backdate an event to keep it longer.
Accepted dates
The API rejects an event dated more than 7 days in the past or more than 5 minutes in the future.
Deletion on request
Deleting a workspace from its settings erases its tests and its events. A visitor’s data is erased on request, from their identifier.
One key per use, a database closed by default.
Each workspace has a key for the browser and keys for your servers. The database can only be read by the application, server-side.
Public key pk_…
In your pages: it reads the public configuration (running tests, rollouts, consent) and sends events. As with any browser script, it is visible. You can restrict it to your site’s domains in the workspace settings. The API also limits the number of calls per key and per address.
Secret key sk_…
For your servers only: back-office orders, management API, MCP server, feature flags. A management key is created as read or write, never exceeds the rights of the person who created it, and stops working if they leave the workspace. Presented to the public API, it is rejected.
Connected assistants
Claude, ChatGPT, and other assistants connect to the MCP server without a key: you authorize each one on a Probant screen, for a workspace and an access level that never exceed your role. PKCE is required; access tokens last 60 minutes and are valid only for the MCP server; the refresh token is replaced on every use, and the whole connection is revoked if it is presented twice. Only their hashes are kept; each connection can be cut off in the settings.
Key storage
192 bits of randomness. Only the SHA‑256 hash, a non-secret prefix, and the last four characters are kept; comparison runs in constant time.
Closed database
No database key is sent to the browser: the application connects to it server-side and checks the session on every page. Row-level security is enabled on every table, with no policy.
Encryption, backups, incidents.
What is established today, and what remains to be specified.
- Encrypted secrets
- Two-factor keys and backup codes are encrypted with the sign-in key. Integration secrets (Shopify and Stripe webhooks) and alert destinations are encrypted with AES-256-GCM and bound to their workspace: copied to another workspace, they cannot be decrypted.
- Error reporting
- When error reporting is on (Sentry), no headers, cookies, or request bodies are sent; email addresses and API keys are masked in messages.
- Encryption in transit
- The app, the API, and the script respond only over HTTPS; the app’s connection to the database requires TLS.
- Stored sensitive data
- Passwords are hashed (scrypt), and API keys and access tokens are stored as SHA-256 hashes, never in plain text. Disk encryption at the hosting provider is not yet specified in Probant’s documents.
- Backups
- Automatic database backups are enabled at the hosting provider. Their frequency, retention period, and exact location are not published yet.
- Incident or breach
- In the event of a data breach, Probant notifies the customer without undue delay after becoming aware of it, as the GDPR requires (Article 33) and the data processing agreement restates. A specific deadline and the detailed procedure are not set yet.
- Security contact
- Report a vulnerability or incident to contact@clivio.app; we reply within 48 hours. The same address is published in /.well-known/security.txt.
Every action has an author.
On a live site, the team knows who launched, stopped, or rolled out what, and the owner decides what each person can do.
Two-factor authentication
With an authenticator app, plus 10 single-use backup codes. The owner can require it for the whole workspace: without it, the workspace stays locked, including actions.
Audit log
Who did what, to what, and when: launches, stops and decisions, rollouts, keys, members, settings, data exports, and deletions. Filterable, exportable as CSV, kept for 13 months.
Roles and permissions
Fixed roles and roles built from named permissions. No one can grant more than their own rights; billing, roles, and deleting the workspace stay with the owner.
Reviewed launches
A launch can require approval from another member. Writing a variant’s JavaScript is a separate permission, and every change is recorded in the audit log.
Assignment can happen on your server.
For a flicker-free display, the server helper assigns the visitor before rendering, on your server or at the edge. It receives the visitor’s choice as a parameter and assigns no one without it when the workspace requires consent. The script stays on the page to measure.
Read the documentationassignRequest({ cookieHeader, url, userAgent, config, consent })
// → { visitorId, setCookie, assignments }Legal documents.
For a security or compliance questionnaire, a set of standard answers is sent on request.
Conclusive Or not yet…
Create your workspace, or explore the demo first with data from a fictional store.
- Open demo, no sign-up
- Free to start, no overage charges
- Database and compute in Amsterdam, with Scaleway