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 for the visitor stored on their device. Browser storage holds exactly four short-lived technical values: a per-tab session hint, an offline queue of events not yet delivered, the site's own consent state, and a five-minute cache of the site's tracker configuration. None identifies a person and none is readable by another site. The session hint is read to group one visitor's events within a single day, which is what it is for, and it cannot do more, because the identity it groups expires at UTC midnight. A site that wants none of it can run the script memory-only.
• 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. The identifier also changes when a visitor's IP address does, mid-visit, on a train or when a phone leaves wifi, which would cut one visit in half and count it twice. So the sessionizer joins two identifiers when they are on the same site, carry a matching per-tab session hint, and fall inside the same 30 minutes of activity. Where that join would cross UTC midnight it is allowed only across two adjacent dates, so the rule bridges one midnight, once, and never links a visitor from one day to a day before that. A joined session is flagged in the data as joined, so the linkage is visible rather than implicit.

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.

That call carries a consent obligation, and it belongs to the site. The audience-measurement basis that lets most sites run this script without a banner (section 13) is written around aggregate statistics, and recognising a named person across visits is not that. The script does not withhold the call on the visitor's behalf: it is invoked by the site's own code, the site is the controller for that invocation, and we do not hold a customer's own instruction against a consent state we cannot see. The hook exists, and a site that records a denial can stop collection entirely with it.

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.

Totals, and revenue by day or by channel, come from the payment provider and involve no visitor at all. Linking a purchase back to the visit that produced it is a separate thing, and a separate choice: it needs an order reference sent from the site's own page, and the script sends that only for a site that has turned attributed revenue on. It is off by default, so a site that never chose it cannot be linking by accident. Where it is on, the consent obligation is the site's, exactly as with the identify call in section 5. Without the reference the purchase is still counted, and simply has no journey attached.

• 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 the plan you are on, in our database; payments, invoices and your billing address with Polar (or, for payments made before September 22, 2026, with Stripe). Card numbers never touch our servers; the payment provider 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.
• 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 paid subscription lapses, data collection pauses after 24 hours and the site's data is retained for 30 days so you can come back; after that it is permanently deleted.
• If a free trial ends without becoming a paid subscription, the dashboard closes and collection stops immediately, and the data already collected is retained for 10 more days; 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 sets no cookies and stores no identifier for the visitor. What it does keep on the device is the four short-lived technical values named in section 4. Under ePrivacy the consent trigger is storage of, or access to, information on a visitor's terminal equipment, and those four values are within that description, so the basis is not that nothing is stored. It is that this is first-party audience measurement: the data produces aggregate statistics for the site's own operator and nothing else, it is never reconciled across sites or services, it is never shared onward, retention is bounded, and an opt-out is available and works. Those conditions are cumulative, and the design was built to satisfy all of them.

Two features fall outside that basis: the site's own user identifier and attributed revenue, both described above. A site using either should not rely on this section, and should say how it asks.

Whether your site needs a disclosure remains your decision as its controller, under the laws that apply to you. Where a banner is used, the script exposes a consent hook so it can be wired to it, a site may require consent before any collection by setting one attribute on the install snippet, and a site that wants nothing at all on its visitors' devices can run the script memory-only. 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 (Polar, 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.