VibeMetrics

Data processing agreement

Last updated Nov 7, 2026

How we handle your visitors' data for you, as GDPR article 28 requires. It's part of our terms and applies to every account. For a signed copy, fill in your details below and download it.

Get a signed copy

Which tracking mode do your apps use?
  • Standard: your app keeps a random ID in the visitor's browser. We can see that someone who came from Reddit on Monday paid on Thursday. In the EU you may need to ask visitors for consent first.
  • Cookieless: nothing is stored in the browser. We recognise a visitor for one day only, so a Monday visit and a Thursday payment can't be linked, and a full page reload starts a new visit. Payments are still matched when your app tells us who signed up.

You can switch later in Settings. Not legal advice: check with someone who knows the rules where your visitors live.

The PDF is made in your browser. We don't receive or store these details.

Preview: the agreement below updates as you type.

1. Parties

Controller (the customer): [company name], [registered address].

Processor: Arman Mkhitaryan, Prague, Czech Republic (IČO 12345678), operating VibeMetrics at https://www.vibemetrics.app/.

This agreement is part of VibeMetrics' terms of service and covers the personal data we process for the controller. This version is for standard mode. If it and the terms disagree on data protection, this agreement wins.

2. Words we use

  • Controller: the customer. It decides to measure its apps and websites, and why.
  • Processor: us. We handle the data only to run VibeMetrics for the controller.
  • Sub-processor: a company we use to help us do that, such as our host.
  • Visitor data: the personal data about the controller's visitors and users that VibeMetrics records.

3. What we process, and why

Purpose: to show the controller where its visitors, signups and paying customers come from, in its dashboards and weekly email. We don't use visitor data for anything else, we don't sell it, and we don't combine it across customers.

Data subjects: visitors and users of the controller's apps and websites.

Visitor data:

  • A random visitor ID that our script keeps in the visitor's browser (local storage) for up to a year, and a visit ID kept for the browser session.
  • Pages viewed (without query strings), the referring website and campaign tags.
  • Country, looked up from the IP address while the request is handled; the IP address itself is never stored. Device type, browser and operating system.
  • Events the controller's app sends, and the app's own user ID for a person if the controller links it.
  • From the controller's Stripe account: payment amounts, currency, time and Stripe's customer and invoice IDs.

In standard mode our script stores a random ID in the visitor's browser. Under EU rules on device storage (the ePrivacy Directive), the controller may need its visitors' consent before the script runs.

No special categories of data are processed, and the service rejects values that look like email addresses.

4. The controller's duties

  • Have a lawful basis for measuring its visitors.
  • Tell its visitors about it (for example in its privacy notice), and ask for consent where the law requires it.
  • Not send data that directly identifies a person, such as names or email addresses, in events.
  • Answer its visitors' requests about their data; we help (section 5).

5. Our duties

  • We process visitor data only on the controller's documented instructions: this agreement, the terms and the settings it chooses in VibeMetrics. We say so if we think an instruction breaks data protection law.
  • Everyone who can access visitor data is bound to confidentiality.
  • We protect visitor data with the measures in section 10.
  • We help the controller answer requests from data subjects, and with security, breach notifications, impact assessments and consultations with authorities (GDPR articles 32 to 36), as far as we reasonably can.
  • We tell the controller about a personal data breach without undue delay, and within 48 hours of learning of it.
  • We give the controller the information needed to show compliance with GDPR article 28, and allow reasonable audits: at most once a year, with 30 days' notice, at the controller's cost.

6. Sub-processors

The controller allows us to use the sub-processors below. We email the controller at least 30 days before adding or replacing one; it may object, and if we can't resolve the objection, end the agreement and close its account. Each sub-processor is bound to the same data protection duties.

  • Supabase, Inc.
  • Vercel, Inc.
  • Resend, Inc.
  • Cloudflare, Inc.

7. Transfers outside the EU

Some sub-processors are in the USA. Where data goes to a country without an EU adequacy decision, the transfer relies on the EU-US Data Privacy Framework where the recipient is certified, and otherwise on the EU's standard contractual clauses.

8. How long we keep visitor data

  • While the controller has an account. A plan's history limit only hides older data from the dashboard; it doesn't delete it.
  • Deleting an app or the account deletes its visitor data at once.
  • If a trial or plan ends without a new plan, the data is deleted 365 days after the end, unless the controller picks a plan.
  • When the agreement ends in another way, we delete the remaining data within 30 days, unless the law requires us to keep it.
  • The daily secrets used in cookieless mode are deleted after two days.

9. Seeing and getting the data

The controller sees its visitor data, summarised, in its dashboards. There's no API or raw event export yet. For a data subject's request, the controller writes to [email protected] and we look up and send, or delete, what we hold about that person.

10. Security measures

  • Encryption in transit (HTTPS) for all traffic.
  • Database-level access control: each customer can only read its own data (row-level security); server keys never reach the browser.
  • IP addresses are never stored; sensitive URL parameters are removed and email-like values rejected before storage.
  • Secrets for integrations are stored only as hashes; Stripe access tokens aren't stored at all.
  • Protection against attacks and abuse in front of our servers (Cloudflare), and rate limits on every public endpoint.
  • Backups and infrastructure security by our sub-processors.

11. Liability, law and contact

Liability follows the terms of service. This agreement is governed by the law of the Czech Republic. Contact for data protection: [email protected].