Data Processing Agreement

These are the data-processing terms Simplytics offers every customer. They take effect when you start using the service and need no signature. If your organisation needs a countersigned copy, email nikhil@simplytics.dev and you will get one.

What this agreement covers

Our short-lived visitor hashes may be personal data while we hold them, so this agreement covers them. We keep that data to a minimum:

• No cookies and no cross-site identifier are set on your visitors.
• Visitors are counted by a keyed daily hash of a truncated IP address, the user-agent and your domain. It links visits within one site and local day; the hash changes across sites and days.
• Individual visit rows are deleted every night. Page-journey records used for funnels lose the visitor hash within two nights and are deleted after 90 days. What remains after that is daily counts and dimensions without the visitor hash. Page paths, referrers, campaign values, event names and outbound-link addresses can still contain identifying information if a site sends it. We filter outbound-link query parameters using known sensitive names and email-address or credential patterns. Personal data and secrets can still occur in paths or other free-form values, so keep them out of the links you track. The privacy policy describes the filter's limits and when the current version began applying.

The short lifetime of the hash limits what can be linked, but it does not make every stored value anonymous. The privacy policy describes the fields and retention periods.

This page describes what the product does and the terms offered. It is not legal advice, or a substitute for your own assessment of whether it meets your obligations.

1. Roles

For visitor data collected from your website, you are the controller and Simplytics is the processor. We process it to provide the service and on your documented instructions, including your use of the product and these terms. For Simplytics account data such as your email address and subscription, Simplytics is the controller, as the privacy policy states. We do not sell, rent or use your visitor data for our own purposes or to train anything.

Proving control of a domain changes which account collects future visits for that domain; it does not transfer analytics collected under a previous account.

History handoff. A handoff needs the previous account holder's documented authorisation for the recipient (the account that now verifies the domain) and that recipient's acceptance. If you hold an earlier collection period for a domain that another account now verifies, you may instruct us, with the Offer or Approve control, to reassign that period to that account. That action is your documented instruction under this agreement for the domain, recipient, period and contents shown on screen when you confirm it, and we keep a record of it. Nothing moves until the recipient accepts. From then on we process that period only as the recipient's processor under its own agreement with us, and your later instructions, including deletion, no longer reach it.

• Only finished reports and funnels move. Raw visit rows are deleted before a handoff can complete.
• Journey records, which by then carry no visitor hash, are deleted when the period moves unless it has funnels; then they are kept only to finish those funnels' daily counts and are deleted 90 days after the visit, as for any site. The recipient never sees them.
• You are responsible for being entitled to disclose that data to the recipient and for anything your visitors must be told; the recipient is responsible for its own lawful basis, notice and requests from then on.

2. What is processed

Scroll the table sideways to see the second column.

3. Our obligations

• Instructions. We process visitor data only on your documented instructions, including any transfer of it to a third country and any handoff of your analytics history to another account, unless the law requires otherwise; then we will tell you first unless the law forbids it. If we think an instruction breaks data-protection law, we will tell you straight away.
• Confidentiality. Everyone with access is bound to confidentiality. Today that is one person.
• Security. We apply the measures described on the security page, which also lists what is not in place. That page is part of these terms and is kept current.
• Assistance. We will help you respond to data-subject requests and to any prior-consultation or impact-assessment obligation, so far as the data we hold allows. Stored visit records lose the visitor hash within two days at most, so we usually cannot locate a specific visitor's data; that is a limit of the design, not a refusal. For a period that has been handed over, we will pass requests about that period, and notices of rectification or erasure under GDPR Article 19, between its former and current holder, without disclosing either party's details beyond what the handoff already showed.
• Breach notification. If we become aware of a personal-data breach affecting your data, we will tell you without undue delay and in any case within 24 hours, with what we know at the time. The clock starts when we become aware, not when the breach happened.
• Deletion and return. You can export the available analytics reports as CSV at any time, and delete your account and the analytics it still holds from the Account page.
  • We first cancel your subscriptions with our billing provider, which can take more than one attempt. Any subscription already cancelled stays cancelled, even if deletion is not yet complete. We keep your account data until we confirm billing has stopped. After each attempt, new checkouts and email changes are paused for up to 24 hours; if deletion does not complete, you may need to request it again.
  • Once deletion succeeds, your account record and its remaining analytics leave the live database immediately. An address-level suppression record may remain to prevent further mail after a bounce or complaint.
  • A completed history handoff belongs to the receiving account and is not erased by deleting the former holder's account. If the former holder deletes its account, we replace its account ID on the handed-over history and the handoff record with a one-way reference, which we remove six years after the handoff. The record's date, scope and confirmation wording stay with the history until the recipient deletes it.
  • Backups are the exception, and they are bounded. Cloudflare's point-in-time restore holds a rolling window of recent database states, at most 30 days and shorter on some plans. A weekly whole-database export is written to private EU storage, where a lifecycle rule deletes each export 90 days after it is written. So copies of the data removed by account deletion age out of those systems within 90 days. They exist only to recover from a disaster: we never use them to rebuild a deleted account, no feature reads them, and we read them only for a recovery, with one exception. Each week the job that writes a new export checks that it restores: it loads that export into a temporary database, counts its tables and accounts, and deletes the temporary database. The verification results we keep are table names, checksums, sizes and counts, not customer-row values. No older backup is read.
• Audit. We will make information needed to demonstrate our processor obligations available to you and allow audits, including inspections, as required by applicable law. Contact us to arrange a reasonable scope and time; we can answer written questions and provide records first.

4. Subprocessors

You give general authorisation for the subprocessors listed on the subprocessors page, which is the full list and is kept current. Each is bound by data-protection terms no less protective than these.

Before adding or replacing one, we email every account holder at least 30 days ahead and publish the change on that page and on the changelog. If you object on reasonable data-protection grounds, tell us before the date; if we cannot resolve it, you may cancel and we will refund the unused part of your subscription.

5. Where the data goes

• Database. The analytics database's primary storage is in the European Union (Warsaw).
• Requests are handled at the Cloudflare location nearest whoever makes them, which may be outside the EU. For a visit beacon, the work done there is the derivation described above and a per-IP rate limit, before the result is written to the database. Dashboards and CSV exports are assembled there from the database for whoever opens them, and a public dashboard's page can be cached at that location for up to 60 seconds.
• Operational logs. Simplytics keeps no Cloudflare Workers Logs from 2026-10-20. Earlier operational logs, which may be stored outside the EU, expire by 2026-10-23. Until 2026-09-29 at 15:09 UTC, Cloudflare kept a three-day entry for every request, including every visit beacon, with request metadata that could include an IP address, user-agent and country. The automatic request-log URL field included the query string until 14:50 UTC that day; later automatic entries omitted it. A separate cache-error message could still contain a full public-dashboard URL until 15:09 UTC that day. This page then said nothing was stored at the edge; that was inaccurate. Older entries will age out by the end of 2026-10-02 (UTC).
• Email is delivered through Amazon SES in eu-west-1 (Ireland).
• Weekly backups are stored in EU-jurisdiction storage; the job that makes and checks them runs on Cloudflare's network and is not guaranteed to stay in the EU.

Of our providers, only Cloudflare processes visitor data as part of the service. Its data processing addendum relies on the EU–US Data Privacy Framework and its UK extension and, where those do not apply, the Standard Contractual Clauses (Module 3) and the UK Addendum. The others hold account, billing or support data under the terms named on the subprocessors page; copies of their current terms are available on request.

Those terms cover our providers, not us. Simplytics is operated by one person based in India, and running the service means reading the EU-hosted database from India. For visitor data from EU customer controllers, the EDPB treats remote access by a third-country processor as an international transfer even if the database is in the EU, and India has no EU adequacy decision and is not covered by UK adequacy regulations. So that access is covered by the EU Standard Contractual Clauses (Module 2, controller to processor), incorporated into this agreement in annex A, with the UK Addendum for UK customers, and we publish our transfer assessment for India in annex B.

One limit: the EU clauses are designed for importers whose processing is not itself subject to the GDPR. Where a customer outside the EU uses Simplytics to measure visitors in the EU, our processing for that customer can be subject to the GDPR directly, and the Commission has not yet adopted the clauses meant for that case; we will move to them when it does. No EU or UK representative has been appointed. If either point is a problem for your own compliance record, tell us before you subscribe.

A history handoff to an account established outside the EEA or the UK can itself be an international transfer by the former holder to the recipient, even though the data stays in the same database. Any safeguard needed between the two of you is for you to put in place; we do not provide one.

6. Liability and precedence

These terms sit alongside the Terms of Service; where the two conflict on a data-protection question, this page wins. Liability is as set out in the Terms.

7. Changes

Material changes to this page are listed on the changelog with the date they took effect. If a change would reduce your protection and you have a subscription, you will be emailed before it applies.

Annex A. Standard Contractual Clauses for access from India

For visitor data subject to the GDPR, the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914, Module 2 (controller to processor), are incorporated into this agreement by reference, with the choices and annexes below. For customers in the UK, the ICO's International Data Transfer Addendum to those clauses (version B1.0) applies as well. If a clause conflicts with the rest of this agreement, the clause wins.

Scroll the table sideways to see the second column.

Annex I.A, parties. Data exporter: you, the account holder, identified by your account email address and the websites you add, as controller; you accept these clauses by using the service, and a countersigned copy is available on request. Data importer: Vemu Nikhil, trading as Simplytics, Kakinada, Andhra Pradesh, India, as processor; contact nikhil@simplytics.dev. The full postal address is given in the countersigned copy.

Annex I.B, the transfer.

• Data subjects: visitors to your websites.
• Personal data: the keyed daily visitor hash, stored at most 48 hours; per-visit page-journey records, which lose the hash within two nights and are deleted after 90 days; and page paths, referring hosts, campaign values, event names and outbound-link addresses, which can contain personal data if your site sends it. In the analytics database, country, device, browser and operating system are stored as daily counts only; a failed request from before 2026-10-20 can also appear, with request metadata that may include an IP address and user-agent, in Cloudflare's operational logs, which expire by 2026-10-23. Until 2026-09-29 at 15:09 UTC, every visit beacon left a request log entry whose metadata could include those fields. No special categories are requested or expected.
• Frequency: continuous.
• Nature: collection at the Cloudflare edge, storage in the EU-hosted primary database, aggregation and display to you and, if you make a dashboard public, to anyone who opens it, with its page cached at the serving Cloudflare location for up to 60 seconds, operational logs at Cloudflare until 2026-10-23, and remote administration from India.
• Purpose: providing website analytics to you.
• Retention: as in the privacy policy.
• Sub-processors: as listed on the subprocessors page.

Annex I.C, supervisory authority: as in clause 13. Annex II, technical and organisational measures: the measures on the security page, which also lists what is not in place. Annex III, sub-processors: the subprocessors page.

UK Addendum. Table 1: the parties above, starting on the date you accept these terms. Table 2: the Module 2 clauses with the choices above. Table 3: annexes I to III above. Table 4: neither party may end the Addendum when the ICO issues a revised version.

Annex B. Transfer assessment for access from India

This is our assessment as importer, for you to use in your own. It follows the EDPB's Recommendations 01/2020 on supplementary measures. It is not a legal opinion. Assessed 2026-09-23; updated 2026-09-29 for the operational-log correction.

• What is reached from India, and how. The operator reads the EU-hosted database over an encrypted connection to deploy, fix faults and answer support. No export or backup of it is kept on devices in India. What exists to be read is daily totals, plus per-visit page journeys that carry no visitor identifier after two nights and are deleted after 90 days; the visitor hash lives at most 48 hours, and the analytics database does not store the IP address or user-agent themselves. Until they expire by 2026-10-23, the operator can also open Cloudflare's operational logs from before 2026-10-20, which may include request metadata such as IP addresses and user-agents. Until 2026-09-29 at 15:09 UTC, those logs held an entry for every visit beacon. One correction: until 2026-09-23 the operator's AI coding tools sometimes read account data, and a little analytics data, from the production database and, on 2026-09-15, Cloudflare's request logs while debugging, and those results can remain in the tools' local logs. Since then those tools see only counts and database or log field names.
• Indian law that could reach it. Section 69 of the Information Technology Act 2000 lets the government direct interception, monitoring or decryption of information stored in a computer resource, and requires the person in charge of it to help. Directions are authorised by a senior civil servant and reviewed afterwards by an executive committee, not approved beforehand by a judge. Section 94 of the Bharatiya Nagarik Suraksha Sanhita 2023 lets a police officer order production of digital records for an investigation. Network interception under the Telecommunications Act 2023 reaches traffic in transit. Section 69B allows monitoring of traffic data, and CERT-In's incident rules can require system logs. The Digital Personal Data Protection Act 2023 is not yet in force for these purposes; its main duties start in May 2027. These are the main powers, not an exhaustive list.
• Our view of that law. Measured against the GDPR's standard, the lack of prior independent authorisation and of effective redress for people outside India means this law can reach the data without guarantees equivalent to EU ones. So we do not rely on it simply never being used.
• What limits the risk. Minimisation means an order could obtain almost nothing that identifies a person. Encryption in transit defeats network interception. No storage in India means there is no local copy to seize. Commitments under clause 15 mean we check any request's legality, challenge it where there are grounds, disclose the minimum, tell you unless the law forbids it, and keep a record.
• Requests so far: none. No public authority, in India or elsewhere, has asked for Simplytics data or access. We state the count on the security page and update it at least once a year.
• Conclusion. With the clauses and these measures, we consider the access can continue: the legal risk is real but narrow, and the harm to visitors if it happened would be low. UK customers can consider the UK “data protection test” met on the same basis.
• When we will reassess. We reassess yearly, and sooner if any of these happens: the Digital Personal Data Protection Act's main duties start in 2027, a court rules on section 69, the Commission adopts the clauses for importers that are already subject to the GDPR, what Simplytics stores changes, or we receive any request.