Privacy & GDPR
What personal data Improve processes about your visitors, so you can complete your own privacy policy, cookie notice, and DPA.
This page describes, precisely, what data Improve's SDK and dashboard collect about your website's visitors when you run tests, flags, and analytics, so you (or your legal/privacy team) can fill in your own privacy policy, cookie notice, and data processing agreement correctly.
This is a technical description of data flows, not legal advice. Whether you need consent, a legitimate-interest assessment, or neither depends on your jurisdiction and how you use Improve. Review this with your own counsel before publishing a privacy policy or cookie notice.
What Improve collects about your visitors
| Data | What it is | Source |
|---|---|---|
| Visitor ID | An opaque random token (visi_ + 26 random characters), not derived from IP, device fingerprint, or any personal data | Generated client-side or in your server middleware, stored in a cookie |
| Test/flag assignment | Which variant of which test or flag a visitor was exposed to | Recorded when your code reads a test/flag value |
| Device & browser | Coarse categories only: device type (mobile/tablet/desktop/…), browser family, OS family, a bucketed screen size, pointer type (coarse/fine) | Parsed from the User-Agent client-side; the raw User-Agent string and exact screen resolution are never sent or stored, only these buckets |
| Location | Country (ISO 3166-1 alpha-2) and, where available, a subdivision/region code | Derived server-side from your hosting edge's geo headers (e.g. Vercel's x-vercel-ip-country); the visitor's IP address is never read or stored |
| Events you send | Whatever you pass to postAnalytic(): an event name, a required scope, plus an optional value, currency, and a free-form params object | Entirely under your control: see below |
Cookies Improve sets
Improve's SDK sets first-party cookies on your own domain (never on obelism.studio); Improve's servers don't set cookies directly, since the API only receives POSTed events.
| Cookie | Purpose | Lifetime | Notes |
|---|---|---|---|
visitorId | Identifies a returning visitor so tests/flags/analytics stay consistent across their session | 30 days (client SDK default) or 7 days (Next.js middleware default), both configurable | Secure, SameSite=Lax. Deliberately not HttpOnly, since client-side code needs to read it; see the JavaScript SDK guide |
<test-slug> (one per server-side test) | Keeps a visitor on the same variant across repeat visits | Same defaults as visitorId, configurable per test via the Next.js middleware options | Same attributes as above |
The visitorId cookie isn't strictly required to render your page: it exists
to support testing and analytics. Depending on your jurisdiction, that likely
means it belongs in the "analytics" or "statistics" category of your cookie
notice rather than "strictly necessary," and may require consent before it's
set (for example under GDPR/ePrivacy in the EU). Confirm this classification
with your own counsel.
Events are your data too
The scope, value, currency, and params you pass to postAnalytic() (and anything you push through the GTM integration) are stored exactly as you send them; Improve doesn't inspect, validate, or filter their contents.
Don't put personal data in them. A page path (scope: '/pricing') or an order total (value: 72.05) is fine; a visitor's name, email address, or order contents with identifying details is not. If your events currently include anything like that, treat it the same as any other personal data your systems store, including for retention and erasure, described below.
Turning off the Google Tag Manager mirror
If you've enabled the GTM integration (on by default: dataLayer: true in your SDK setup), every event mirrors the visitor ID plus its value/currency/params onto window.dataLayer. Whatever GTM tags you've wired up to fire on that data (a GA4 or Google Ads tag, for example) will send it to Google as a sub-processor, including any params/ecommerce object you supplied.
Set dataLayer: false in your SDK setup args to disable this mirror entirely if you don't use GTM, or if you want to keep this data out of Google's hands.
Data retention
Improve does not currently apply an automatic retention limit: analytics and exposure rows persist until you delete them. If your privacy policy commits to a retention period, contact us and we'll help enforce it.
Right to erasure (data subject requests)
There's no self-service "delete this visitor" tool in the dashboard today. If a data subject asks to have their data erased, and you can identify their visitorId (e.g. from their cookie, if they contact you with it), contact us with it and we'll remove the matching rows for you.
Since the visitor ID has no independent link to a real person (it's not an email, name, or account ID), you'll generally need the visitor to provide their own visitorId; Improve has no way to look one up from "a person" on its own.
Sub-processors & data residency
- Hosting: Improve runs on Cloudflare Workers; edge geo lookups depend on Cloudflare's request headers.
- Database: Improve's PostgreSQL database runs on PlanetScale in Frankfurt, Germany (AWS
eu-central-1), EU-resident by default.
For a current, complete sub-processor list or a signed DPA, contact us at development@obelism.studio.
Checklist for your own privacy policy
- Disclose the
visitorId(and, if applicable, per-test) cookie: likely under "analytics"/"statistics," not "strictly necessary." - Decide whether you need consent before Improve's SDK sets its cookie, based on your jurisdiction.
- Audit what you're passing into
scope/value/params/ecommerce: make sure none of it is personal data you haven't accounted for elsewhere. - If you use the GTM integration, disclose Google as a sub-processor for that data (or disable it with
dataLayer: false). - Note that Improve doesn't yet auto-delete old data; factor that into your own retention commitments.
- Know how you'd handle an erasure request today (manual deletion by
visitorId).