1. Parties and scope
This Data Processing Agreement (“DPA”) is between the customer who holds a traffic.cx account (“you”, the controller) and Karthick, operating traffic.cx from Erode, Tamil Nadu, India, [Full postal address] (“traffic.cx”, “we”, the processor). It forms part of the terms and applies whenever traffic.cx processes Customer Personal Data. A countersigned copy is available on request from support@traffic.cx.
“Customer Personal Data” means personal data that traffic.cx processes on your behalf through the service: analytics collected on your websites, revenue data from your integrations and the payments API, and Search Console data you connect. It does not cover information about you and your teammates as traffic.cx customers, such as account, billing and support records, for which traffic.cx is the controller under its privacy notice.
Terms such as “controller”, “processor”, “personal data”, “data subject” and “personal data breach” have the meanings given in the EU General Data Protection Regulation (“GDPR”). Where other data-protection laws apply, including the UK GDPR, the Swiss Federal Act on Data Protection and India’s Digital Personal Data Protection Act, 2023, this DPA is read to meet their equivalent requirements. If this DPA conflicts with the terms, this DPA wins for Customer Personal Data.
2. Details of the processing
- Subject matter and purpose: providing web analytics and revenue attribution to you, including collection, enrichment (approximate location, browser and device, traffic source), storage, aggregation into reports, live views, exports and APIs, backups, and the security and abuse protection the service needs.
- Nature: collection, recording, organisation, storage, pseudonymisation, retrieval, use, transmission to you, and erasure. Processing is automated.
- Duration: for as long as you use the service, and afterwards until the data is deleted or returned under section 11.
- Data subjects: visitors to your websites and apps; your customers whose payments reach traffic.cx through your integrations or the payments API; anyone whose details you choose to send in event properties.
- Categories of data: page addresses and referrers, campaign tags and click identifiers, timestamps, events and their properties, engagement and scroll depth, screen width, browser, operating system and device type, approximate location (country, region, city), pseudonymous visitor and session identifiers, and in optional cookie mode a first-party visitor cookie. IP addresses and user agents are processed in memory to derive location and visitor identifiers and to filter abuse; they are not stored in analytics records. Revenue data covers payment and order identifiers, amounts, currencies, refunds, subscription events, keyed customer identifiers and masked display hints, and any customer details your payment provider includes in its webhooks while they are processed.
- Special categories: none are intended. You must not send special-category data, or data about children that requires parental consent, through analytics events or properties.
3. Processing on your instructions
We process Customer Personal Data only on your documented instructions. This DPA, the terms, your settings in the dashboard (such as tracking mode, kept query parameters, IP exclusions and connected integrations) and your use of the API are your complete instructions. Other instructions need our written agreement.
We do not sell Customer Personal Data, use it for advertising, combine it across customers, or use it for our own purposes, except to keep the service secure and working. If an instruction appears to infringe data-protection law, we will tell you. If the law requires us to process Customer Personal Data in another way, we will tell you first unless the law forbids it.
You are responsible for having a lawful basis for the processing, for the notices you give your visitors and customers, and for obtaining any consent your tracking choices require.
4. Confidentiality
Today the operator is the only person with access to Customer Personal Data. Anyone given access in future will be bound by a written duty of confidentiality and will receive access only as their work requires.
5. Security
We maintain the technical and organisational measures described in Annex: security measures, taking into account the nature of the data and the risks of the processing. We may change them as the service evolves, but not in a way that lowers the overall level of protection.
6. Sub-processors
You give general authorisation for traffic.cx to use sub-processors. The current ones are on the sub-processor list. We impose data-protection obligations on each one that are no less protective than this DPA, as far as the service they provide allows, and remain responsible to you for their performance.
We email team owners at least 30 days before a new sub-processor starts processing Customer Personal Data. You may object on reasonable data-protection grounds within that period by writing to support@traffic.cx. We will discuss a reasonable alternative with you. If we cannot find one, you may end your subscription before the change takes effect and receive a refund of prepaid fees for the unused period.
7. International transfers
traffic.cx is operated from India and stores Customer Personal Data on a server in Mumbai, India. Requests reach that server through Cloudflare’s global network, and backups are stored in Western Europe. Sub-processors may process data in the locations shown on the sub-processor list.
To the extent Customer Personal Data subject to the GDPR is transferred to a country without an adequacy decision, the Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914 (“SCCs”) apply and are incorporated into this DPA by reference. Module Two (controller to processor) applies, with you as data exporter and traffic.cx as data importer. In the SCCs: the optional docking clause 7 does not apply; option 2 of clause 9(a) applies, with the notice period in section 6; the optional wording in clause 11 does not apply; the supervisory authority under clause 13 is the one competent for you; clauses 17 and 18 choose the law and courts of [EU member state]. Annex I of the SCCs is completed by sections 1 and 2, Annex II by the security annex below, and Annex III by the sub-processor list.
For UK personal data, the International Data Transfer Addendum issued by the UK Information Commissioner applies to the SCCs. For Swiss personal data, the SCCs apply with references to the GDPR read as references to the Swiss Federal Act on Data Protection, and the Swiss Federal Data Protection and Information Commissioner as a competent authority.
8. Data-subject requests
If a visitor or customer of yours contacts us about their data, we will pass the request to you and not answer it ourselves unless you ask us to. We will help you respond to requests to access, correct, delete, restrict or object, taking into account the nature of the processing.
In the default cookieless mode, visitor identifiers change every day and cannot be recalculated once the daily secret is deleted, so analytics records usually cannot be linked to a person who asks. Where a request includes an identifier we can match, such as a cookie-mode visitor ID, an event property you set, or a customer identifier from your payment provider, we will find and delete the matching records on your request.
9. Assistance
We will give you the information about the processing you reasonably need for data-protection impact assessments, prior consultations with a supervisory authority, and records of processing.
10. Personal data breaches
We will notify you without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data. The notice goes to the team owners’ email addresses and describes, as far as we know at the time, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. We will add details as we learn them, take reasonable steps to contain the breach, and help you meet your own notification duties.
11. Deletion and return
When you stop using the service, you can export your reports through the dashboard and the Stats API. On your written request to support@traffic.cx, we will delete Customer Personal Data for your sites within 30 days, or first provide an export of it, unless the law requires us to keep some of it. Copies in backups expire within a further 30 days.
Deleting a site in the dashboard disables it but does not by itself erase its history; ask us to erase it. We confirm in writing when deletion is complete.
12. Information and audits
We will make available the information needed to show that we meet this DPA, including written answers to reasonable security questionnaires. traffic.cx holds no independent security certification today.
Where that information is not enough, you or an independent auditor bound by confidentiality may audit our compliance with this DPA, on at least 30 days’ notice, no more than once a year unless a supervisory authority requires it or after a breach, during business hours and without access to other customers’ data. Each party bears its own costs.
13. Term and changes
This DPA lasts as long as traffic.cx processes Customer Personal Data for you. We may update it to reflect changes in law or the service and will show the revision date on this page; we will email team owners before a change that reduces your protection, and such a change will not apply to you until 30 days later.
Annex: security measures
These are the measures in place today. They describe a small service run by one operator and will grow with it.
- Network: the application and its databases (PostgreSQL, ClickHouse and Valkey) run in containers on the server with no port open to the internet. Public traffic reaches the API and the event collector only through an outbound Cloudflare Tunnel, and the collector accepts events from Cloudflare’s edge only with a shared secret. Public endpoints use HTTPS; connections inside the server’s private container network are not encrypted.
- Separation: the production stack and its data are separate from development and test databases. The server is shared with other, unrelated applications of the operator in separate containers with resource limits; a dedicated server is planned.
- Access control: dashboard access requires an account, with sign-in by email link or Google and optional two-factor authentication. Team roles (owner, admin, editor, viewer) limit what members can see and do, and every API request is checked against the team that owns the site. Sign-in is rate-limited, and sessions expire after 30 days without use. Platform administration requires a proven second factor, and administrative changes are written to an audit log.
- Data minimisation and pseudonymisation: cookieless visitor identifiers are keyed hashes of the site, IP address and user agent with a daily secret that is deleted after 48 hours and never backed up. Analytics records hold no raw IP address or user agent. Query strings are removed from page addresses except campaign tags and parameters you choose to keep. Location is kept only to city level; the live map’s rounded coordinates are never stored. Revenue records use keyed customer identifiers and masked display hints.
- Secrets: payment-provider keys and Search Console tokens are encrypted with AES-256-GCM. Production secrets live in files readable only by the server’s administrator, never in source code. Incoming webhooks are verified by signature.
- Backups and recovery: the databases are backed up every night to Cloudflare R2 in Western Europe with a key limited to that bucket and to the server’s addresses, and backups older than 30 days are deleted. Restores are tested by restoring into throwaway copies and comparing them.
- Abuse protection: the collector rate-limits by address and site, and filters known bots, data-centre traffic and spam referrers.
- Software: dependencies are pinned by a committed lockfile, and changes are run through automated checks and tests before they are deployed.