Privacy Policy

Open Analytics is operated by AGHAZADA LLC, a limited liability company registered in New Mexico, United States ("we", "us"). We provide privacy-first web analytics at getopen.so and its subdomains. For anything in this policy, write to support@getopen.so.

This policy covers three groups, and the rules differ for each:

• Visitors of our customers' websites. The sites that install our tracking script. Here the site owner is the data controller and we are their processor: we process this data only to produce their analytics, on their instructions, and it is never ours to use.
• Our customers. People with an Open Analytics account. For this data we are the controller, and sections 8 to 12 describe exactly what we hold.
• Visitors of getopen.so itself. We measure our own site with our own product, under the same rules as every customer site: no cookies, no personal data. What you see is what we get.

On a site that runs our script, we record, per event: the page URL, the referrer, campaign parameters (UTM tags), the browser and operating system family, the device type, the country and city, the time, and any custom events the site owner has defined (a signup button clicked, a checkout completed). From these we compute visit duration, bounce rate, and page performance metrics.

City and country are resolved on our own servers from the incoming IP address using a local copy of the GeoLite2 database. The IP address is used in memory for that lookup and for the anonymous identifier described in section 5, and is then discarded. It is never written to the analytics database and never sent to any third party.

• No cookies and no identifier stored on your visitors' devices. The script stores nothing that identifies anyone, and nothing it stores is read by us to recognise a visitor.
• No browser fingerprinting. The identity input derived from the browser is deliberately coarse (device type, browser family, OS family, no versions), and we never store raw IP addresses in analytics data.
• No cross-site or cross-device tracking. A visitor on one customer's site cannot be connected to the same person on another's.
• No keystrokes, no session replay, no screenshots, no form values. The value of an input field is never captured, at any layer.
• No advertising profiles. We do not sell, rent, broker, or share data with advertisers or data brokers, and there is no third-party ad code anywhere in the product.
• No collection beyond what the dashboard shows. If a number is not in your reports, we are not quietly gathering it.

To count unique visitors without identifying anyone, the collector derives a pseudonymous identifier on the server: a keyed hash (HMAC-SHA256) over six inputs. They are a derivation version, the key version, the site's ID, the current UTC calendar date, the coarse browser class (device type, browser family, and operating system family, with no versions), and the visitor's IP address, normalized. Because the calendar date is one of the inputs, the identifier for the same person changes at UTC midnight: rotation comes from the construction itself, not from replacing a key on a schedule.

The consequences are the point: the identifier cannot be reversed into an IP address (a keyed hash is one-way, and the key is held only by the service that computes it), the same person gets an unrelated identifier on every site (the site ID is an input, not a prefix), and every identifier expires at the end of the UTC day, so nobody, including us, can follow a visitor from one day to the next. This is the entire identity model; there is no second, more detailed record behind it.

One bounded exception, stated openly: a visit that is in progress at UTC midnight would otherwise be cut in half and counted twice. To avoid that, the sessionizer joins the two halves when, and only when, the events fall within a 30-minute window straddling that single midnight, carry a matching per-tab session hint, and are on the same site. A joined session is flagged in the data as joined, so the linkage is visible rather than implicit. It cannot reconstruct long-term tracking: it bridges one midnight, once, inside half an hour.

A site owner may attach their own pseudonymous user ID to events (for example an internal account number) through the script's identify call. That ID is chosen and controlled by the site owner as controller; our terms require that it not be directly identifying (no email addresses or names), and it is hashed before storage. Unlike the anonymous identifier, it does not rotate daily: that is its purpose, it is how a site recognises its own logged-in users across visits, and a site that uses it should say so in its own privacy notice.

The script honours two browser-level opt-out signals out of the box, and a consent state a site can set:

• Global Privacy Control. A visitor sending GPC is not measured. This is honoured twice: in the browser, and again at our servers, where a request arriving with the Sec-GPC header is discarded regardless of how the site configured its tracker.
• Do Not Track. A visitor sending DNT, in any of its spellings, is not measured by default. DNT has no legal force and its handling is a per-site setting; the out-of-the-box behaviour honours it.
• Explicit denial is final. A site that wires a consent banner to the script stops collection for a visitor who denies, regardless of any other setting, and a site may require consent before any collection with one attribute on the install snippet.

Every signal the script would send passes through a single decision point, so there is no path that quietly bypasses these checks.

If a customer connects the Stripe revenue integration, we receive transaction records from their Stripe account (amounts, currencies, timestamps, and Stripe's identifiers) and join them to the anonymous visit data to produce revenue reports. We request the minimum Stripe access the reports need, we act as the customer's processor for this data, and disconnecting the integration stops the flow immediately.

• Your email address and name, from the sign-in method you chose (Google, GitHub, or a sign-in link by email). This is required to have an account.
• One session cookie, HttpOnly and used strictly to keep you signed in to the dashboard. It does no tracking, and it is the only cookie we set.
• Your settings: timezone preference, site names and slugs, team memberships and invitations, funnel and event definitions, widget and share configurations.
• Billing status and invoices via Stripe. Card numbers never touch our servers; Stripe holds them.
• API keys and connected apps: keys are stored hashed, and the list of OAuth clients you have authorized (an AI agent, our CLI) is kept so you can see and revoke each one from your account settings.
• Support conversations, when you write to us.

The AI assistant in the dashboard sends your question, together with the aggregate numbers needed to answer it, to OpenAI. Your message is scrubbed for anything resembling a secret before the prompt is assembled, so a pasted API key never reaches the provider. Conversations are not stored on our servers; we keep only a count of questions asked for fair-use limits, and that count expires within 48 hours.

All analytics data, for every customer, is stored and processed on servers we rent from Hetzner in Helsinki, Finland, inside the European Union, and it does not leave that infrastructure. The application database (accounts, billing, settings) is managed Postgres hosted by Neon in Frankfurt, Germany. Operational metrics go to an EU Grafana Cloud stack. The dashboard application is served by Vercel. Payments, email delivery, optional sign-in, and the AI assistant involve the US-based providers listed below; visitor analytics data does not flow to any of them, with the single customer-initiated exception of the assistant's aggregate reads described in section 8.

We use a deliberately short list of providers. Each one processes data only for the purpose named here:

Geolocation deserves its own line: it uses a GeoLite2 database hosted on our own servers, so no IP address is ever sent to its maker (MaxMind) or anyone else; the only contact in that direction is our monthly download of the database file. We will update this list before adding a provider, and customers with a DPA in place receive notice as described there.

• Analytics data is kept for as long as the site exists, so your history stays useful.
• Test-mode and preview traffic is deleted automatically after 7 days.
• The ingest queue and its recovery copy expire within 7 days; they exist only so nothing is lost if a database has to be restored.
• Realtime “who is here now” state lives for 5 minutes.
• If a subscription lapses, data collection pauses after 24 hours and the site's data is retained for 90 days so you can come back; after that it is permanently deleted.
• Backups are encrypted archives held in the same EU region: daily copies for 30 days, weekly copies for 84 days. A deleted site disappears from backups as those archives age out, and if a backup ever has to be restored, deletions that happened after it was taken are re-applied before anything is served. A deleted site is never resurrected by a restore.
• Support conversations are kept for 24 months from the last message, then deleted.
• Deleting a site permanently removes its analytics data, keys, widgets, and share pages. Deleting your account removes everything tied to it, across every store we run, with the two named exceptions in section 12. Both are self-serve in the dashboard, and both are irreversible.

Two records are deliberate exceptions to deletion, and we would rather name them than let somebody find them.

The account security journal. Credential events, such as when an API key or connected app was created, rotated, revoked, first used, or first used from a new source, are kept indefinitely. The journal records a keyed fingerprint of the source address, never the address itself. It is retained because it is the record of who could reach an account's data, including the record of the deletion itself; a security journal that a compromised account can erase is not a security journal.

The free-trial record. The free trial is once per person, and enforcing that requires remembering that an address has used it. What is stored is a keyed hash of the email address, never the address; it cannot be reversed, only recognised by re-hashing an address at signup. When an account is deleted, the link to the person is severed and the hash stays: the row keeps no account reference, and what remains can answer exactly one question, whether this address has already had its free trial, and nothing else.

For customer data, we process on the basis of our contract with you (running the service you signed up for) and our legitimate interest in operating, securing, and improving it. For visitor data, the site owner is the controller and determines their own legal basis; we process solely on their instructions.

The tracker is built to operate without cookies, without persistent identifiers, and without personal data, which is precisely the design that lets many of our customers run it without a cookie consent banner. Whether your site needs a disclosure remains your decision as its controller, under the laws that apply to you. If you want ready-made language for your own policy, we publish a privacy notice template you can adapt.

Visitor analytics stays in the EU as described in section 9. Where a named subprocessor processes customer data outside the EU (Stripe, Resend, OpenAI, Google, GitHub, and Vercel in the United States; Telegram outside the EU), transfers rely on the European Commission's Standard Contractual Clauses or the provider's EU-U.S. Data Privacy Framework certification, as applicable.

Wherever you are, we extend the same set of rights: access to the data we hold about you, correction, export, deletion, portability, and objection to processing. Deletion of your sites and your account is built into the product, so you do not need to ask us to do it; for everything else, one email to support@getopen.so is enough, and we answer within 30 days. If you believe we have not resolved a concern, you may lodge a complaint with your local data protection authority.

Visitor data cannot be looked up per person, by design: with no cookie, no device identifier, no stored IP, and an identifier that changes every day and differs on every site, there is no key with which to find "your" rows, for us or for anyone else. This is not a refusal to comply; it is the strongest form of protection we know how to build. If a visitor contacts us directly, we will say exactly this and point them to the site they visited, which is the controller.

When we change this policy in any meaningful way, we will note it here with a new date and tell customers by email or in the dashboard before it takes effect. We will never weaken the commitments in section 4; they are the product.

AGHAZADA LLC, New Mexico, United States. Privacy questions, data requests, and everything else: support@getopen.so.