Privacy Policy

1. Who we are

OpenRevenue is operated by Egger, Inc., a corporation registered in Delaware, United States ("we", "us", "OpenRevenue"). Our mailing address is 2810 N Church St # 89471, Wilmington, DE 19802, United States.

We provide privacy-focused web analytics at openrevenue.com and related subdomains (including the dashboard, tracker, APIs, embeddable widgets, and documentation). For privacy questions and data-subject requests, write to support@openrevenue.com.

2. Three kinds of people, three kinds of data

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

• Visitors of our customers' websites. Sites that install our tracking script. Here the site owner is normally the data controller and we are their processor: we process analytics data to produce their reports, on their instructions, and we do not sell it or use it for advertising.
• Our customers. People and organizations with an OpenRevenue account. For this account, billing, and security data we are the controller.
• Visitors of openrevenue.com itself. We measure our own marketing site with our own product under the same product rules as customer sites. Logged-in app browsing on customer dashboards is configured so we do not inspect what customers view inside their project analytics beyond operational needs.

3. What the tracking script collects

On a site that runs our script, we may record, per event: the page URL/path, referrer, campaign parameters (such as UTM tags), browser and operating system family, device type, timestamps, visit duration, custom event names and properties the site owner defines, Core Web Vitals / performance timing when enabled, and approximate geolocation (country, region, city, and coordinates when available).

Geolocation is resolved at ingest from infrastructure request headers (for example Vercel edge geo headers). The visitor's IP address is used for geo resolution, abuse prevention, and (when needed) a server-side visitor identifier fallback. The IP address is also stored with the analytics event for operational and security purposes; it is not shown as a first-class field in customer dashboards.

Customers should not send passwords, payment card data, private messages, health data, government identifiers, or other sensitive personal information in paths, event names, or custom properties.

4. Identifiers, cookies, and browser storage

OpenRevenue is not an advertising network and does not use third-party marketing cookies for cross-site tracking. The tracker does use first-party storage so customers can measure visits and sessions:

• A first-party cookie (_ova_vid) and/or localStorage entry holding a random visitor identifier (long-lived, typically up to about two years).
• A sessionStorage entry (_ova_sid) holding a random session identifier for the current browsing session.
• When a site calls identify(), a hashed product user id in localStorage (_ova_uid). The raw id is hashed (SHA-256) in the browser before storage and send; customers must not pass emails or names.
• If the browser blocks storage, the collector may derive a daily-rotating server-side fallback identifier from a keyed hash over the UTC date, a coarsened IP prefix, and user-agent class. That fallback is designed to reduce long-term linkability when client storage is unavailable.

5. What we never do

• No advertising profiles. We do not sell, rent, broker, or share analytics data with advertisers or data brokers, and there is no third-party ad pixel in the OpenRevenue tracker.
• No cross-site visitor graph. A visitor on one customer's site is not joined to the same person on another customer's site by OpenRevenue.
• No session replay, keystroke logging, screenshots, or form-field capture. Input values are not recorded by the tracker.
• No intentional browser fingerprinting for advertising or cross-site profiling. Device signals used for analytics are coarse product analytics fields (browser/OS/device family), not an advertising fingerprint suite.
• No collection beyond what the product is built to report. If a metric is not available in the dashboard, APIs, or documented features, we are not quietly building a separate advertising dossier.

6. Opt-out signals and customer consent hooks

The tracker honors Do Not Track (DNT) and Global Privacy Control (GPC) in the browser: when the visitor's browser sends DNT or enables GPC, the script does not send events. The collector also ignores requests that include the Sec-GPC: 1 header. Customers remain responsible for any additional consent, notice, or regional requirements that apply to their sites.

Customers can further reduce collection with product controls such as allowed hostnames, blocked IPs, blocked or masked paths, and by choosing not to send identifying custom properties.

7. Revenue and other customer-connected data

If a customer connects a revenue provider (for example Stripe, Polar, or similar integrations offered in the product), we receive transaction metadata needed for attribution reports (amounts, currencies, timestamps, and provider identifiers) and join it to visit data where the customer has configured attribution. We act as the customer's processor for that connected data. Disconnecting the integration stops new flows.

Optional imports (for example Google Analytics or Plausible history) and search integrations (for example Google Search Console) only run when a customer connects their own credentials or uploads an export and chooses to import or sync. Those flows process only what the customer authorizes.

8. What we hold about you, the customer

• Account identity: email, name, profile image (optional), authentication sessions, email one-time codes, passkeys, and two-factor authenticator secrets/backup codes when enabled.
• Workspace and project settings: project names, domains, timezone, public stats and widget settings, team memberships and invitations, funnel/goal/event definitions, API key metadata (secrets stored hashed), SSO configuration for Enterprise customers, and notification preferences.
• Billing state and invoices via Stripe. Card numbers are handled by Stripe and do not need to be stored by OpenRevenue to run subscriptions.
• Support and contact messages you send us, and security-related logs needed to protect accounts.
• AI assistant usage: when you ask the in-product assistant a question, we send your prompt and the aggregate analytics context needed to answer to our inference provider (via Vercel AI Gateway). Do not paste secrets into prompts. Conversations are processed to answer your request; we may keep limited operational counts for abuse prevention and fair use.

9. Where data is processed

OpenRevenue is a cloud SaaS product. Analytics events are stored in our self-hosted ClickHouse cluster on Hetzner in Falkenstein, Germany (reachable in production as data.openrevenue.com). Account, billing, and configuration data live in managed Postgres (PlanetScale). The application and marketing site are hosted on Vercel. Object storage uses Cloudflare R2 for account avatars (public CDN URLs) and temporary private history-import uploads (Plausible ZIP exports — never publicly readable, deleted after a successful import). Transactional email uses Cloudflare Email Service. Payments use Stripe. Error monitoring uses Sentry. Maps in realtime views use Mapbox. Blog content is managed in Sanity.

Visitor analytics in ClickHouse therefore resides in Germany (EU). Other systems—including the application database, app hosting, email, billing, and optional AI features—may process data in the United States and other countries where those providers operate. Section 14 describes transfer safeguards for non-EU processing.

10. Subprocessors

We use a short list of providers to operate the service. Each processes data only for the purpose named here. Customer-configured connections (a customer's own Stripe/Polar account, Slack webhook, Google OAuth for GA/GSC, or Enterprise SSO identity provider) are chosen by the customer and are not OpenRevenue subprocessors in the same sense.

11. How long we keep things

• Account and project configuration data is kept while the account/project is active and as needed for billing, security, and legal obligations.
• Analytics retention follows product and plan practices. OpenRevenue is built for long-lived analytics history; deleting a project removes its analytics access path and associated project data according to our deletion workflows.
• Security logs, invoices, and certain abuse-prevention records may be retained longer when needed to protect accounts, meet accounting rules, or investigate misuse.
• Backups and replicas age out on operational schedules; deleted data disappears from backups as those copies expire.

12. Legal bases and cookie / ePrivacy notices

For customer account and billing data, we process on the basis of performing our contract with you and our legitimate interests in securing and operating the service, and where required by consent (for example certain emails).

For visitor analytics on a customer site, the customer is the controller and chooses the legal basis and notices that apply to their visitors. We process that data as their processor under our Terms and DPA.

Because the tracker uses first-party cookies and browser storage, customers should not assume that an EU/EEA/UK cookie banner is never required. Whether a banner or other disclosure is needed depends on the customer's implementation, jurisdiction, and features used (including identify calls or attributed revenue). OpenRevenue provides product controls and documentation; the customer remains responsible for their public notices and compliance.

13. Uploaded files and media

Website visitors cannot upload files through the tracker. Signed-in owners and admins may upload an account avatar (stored in Cloudflare R2), an optional project icon (stored with the project), and optional analytics history exports (for example a Plausible ZIP) via short-lived private upload URLs. History-import objects are not publicly readable, are keyed to the signed-in user and project, and are deleted after a successful import (or when discarded). Do not upload identity documents, passwords, or other sensitive files.

14. International transfers

Where personal data is transferred from the EEA, UK, or Switzerland to countries without an adequacy decision, we rely on appropriate safeguards such as the European Commission's Standard Contractual Clauses and, where applicable, a provider's EU-U.S. Data Privacy Framework certification.

Visitor analytics stored in ClickHouse is hosted on Hetzner in Falkenstein, Germany, and does not leave that analytics cluster for storage. Other processing (application database, app hosting, email, billing, optional AI) may occur outside the EU as described in section 9. Customers are responsible for assessing whether their overall use of OpenRevenue meets their own transfer and DPIA obligations.

15. Your rights

Depending on applicable law (including the GDPR and UK GDPR), you may have rights to access, correct, delete, restrict, export, or object to certain processing, and to withdraw consent where processing is consent-based. Many account and project changes are available in the dashboard. For other requests, email support@openrevenue.com. We may need to verify identity before acting.

Website visitors should contact the site owner (controller) first. For visitor analytics, OpenRevenue often cannot look up an individual across events the way a cookie-advertising profile could: identifiers may be first-party random IDs or daily-rotating fallbacks, and we do not operate a cross-site identity graph. When a visitor contacts us directly, we will explain this and point them to the site they visited.

You may lodge a complaint with your local data protection authority if you believe we have not handled a concern appropriately.

16. Security

We use technical and organizational measures appropriate to a SaaS analytics product, including TLS in transit, authentication (including optional passkeys and two-factor authentication), access controls, hashing of secrets, operational monitoring, and least-privilege internal access. No internet service is perfectly secure; we work to reduce risk and improve controls as the product evolves.

17. Children

OpenRevenue is a business service. It is not directed at children, and we do not knowingly collect account data from children under 16 (or the higher age required in your region) for the purpose of offering the service to them.

18. Changes to this policy

When we change this policy in a meaningful way, we will update the date above and, for material changes, notify customers by email or in the dashboard when practical. Continued use after the effective date constitutes acceptance of the updated policy where permitted by law.

19. Contact

Egger, Inc., 2810 N Church St # 89471, Wilmington, DE 19802, United States. Privacy questions and data requests: support@openrevenue.com.