Data Processing Agreement (DPA)

This Data Processing Agreement (“DPA”) is made between Use Ampersand (the “Processor”; the provider’s details are set out in the Legal Notice) and the customer that has accepted the Terms of Service (the “Controller”). The Controller is identified by the customer account held with Use Ampersand.

1. Subject matter, duration, nature and purpose

The Processor processes personal data that the Controller submits through the HTTP endpoint POST https://useampersand.io/collect or its versioned form, together with the technical data generated when doing so. Processing covers receiving, storing, structuring, querying, analysing, displaying and deleting that data, as necessary to operate web and event analytics for the Controller. The purpose is to provide the Controller with the analytics service and its dashboard.

Processing starts when the Controller first submits data and ends when the Terms of Service end. Clause 7 continues to apply afterwards.

This DPA covers event data and related technical data processed on the Controller’s behalf. Account, sign-in and billing data that the Processor processes for its own contract with the Controller are outside its scope; they are described in the Privacy Policy.

2. Instructions and Controller responsibilities

The Processor processes personal data only on the Controller’s documented instructions. These are this DPA, the Terms of Service, the Controller’s configuration of its projects, and its submission of event data. If Union or Member State law requires other processing, the Processor will inform the Controller beforehand unless that law prohibits it. If the Processor considers an instruction to infringe data protection law, it will inform the Controller without delay and may suspend the affected processing until the matter is resolved.

The Controller is responsible for the legal basis of the processing, for transparency towards data subjects, for data minimisation and for the lawfulness of the data submitted. The Controller must not submit special categories of personal data under Article 9 GDPR, and must not use real names or email addresses as client_id. Optional properties and free-text fields must not contain personal data that is unlawful or unnecessary for the Controller’s purpose.

3. Categories of data and data subjects

The processing concerns in particular:

• pseudonymous identifiers chosen by the Controller, such as client_id, session ID and an optional account ID;
• event name, timestamps, page URL and referrer, technical error and usage data, and event properties chosen by the Controller;
• device, browser, operating system, geographic and campaign attributes, where the Controller sends them or they are derived as described below;
• IP address and user agent, only if the Controller chooses to send them in context.client.ip and context.client.user_agent. They are used solely to derive geographic and device attributes and are then discarded. They are not stored and not logged.

Data subjects are the Controller’s end users and customers whose activity the Controller measures through the service. The Controller determines the specific fields through the events it sends.

The Processor does not use event data for its own purposes. It does not sell it, share it with third parties other than the sub-processors in clause 5, or use it to train models.

4. Processor obligations

• The Processor ensures that everyone authorised to process the data is bound by confidentiality and accesses the data only as instructed.
• The Processor implements the technical and organisational measures in Annex 1 and reviews them at appropriate intervals.
• Taking into account the nature of the processing, the Processor assists the Controller in responding to data subject requests. The dashboard does not yet offer self-service functions for this. On request to the contact address below, the Processor will locate, export or delete the events of a specific client_id within 30 days.
• The Processor assists the Controller with its obligations under Articles 32 to 36 GDPR, taking into account the information available to it.
• The Processor notifies the Controller of a personal data breach affecting the Controller’s data without undue delay, and no later than 48 hours after becoming aware of it. The notice contains the information then available and is updated as further facts become known.
• The Processor makes available the information necessary to demonstrate compliance with Article 28 GDPR and allows for audits under clause 8.

5. Sub-processors and international transfers

The Controller gives general authorisation for the sub-processors listed below. The Processor binds each of them by contract to data protection obligations at least equivalent to this DPA and remains responsible to the Controller for their performance.

Resend (sign-in emails), Stripe (payments) and Cloudflare (DNS) do not receive event data and are therefore not sub-processors under this DPA. They are listed in the Privacy Policy.

The Processor will notify the Controller at least 30 days before adding or replacing a sub-processor, by email to the address of the customer account. The Controller may object on reasonable data protection grounds within 14 days of the notice. If the parties cannot agree on a solution, the Controller may terminate the Terms of Service before the change takes effect.

Event data is processed and stored in the European Union. Both sub-processors are established in the United States, so access from there — for example for support or operations — cannot be ruled out, and requests from senders outside Europe may first reach an edge location outside the EU. Any such transfer takes place only on the basis of Articles 44 et seq. GDPR — an adequacy decision, in particular the EU–U.S. Data Privacy Framework for certified providers, or the European Commission’s Standard Contractual Clauses.

6. Security of processing

Annex 1 describes the current measures. The Processor may develop them further, provided that the level of protection is not reduced. It will inform the Controller of changes that materially affect the level of protection.

7. Retention, return and deletion

While the Terms of Service are in effect, events are kept for the retention period of the project’s plan and then deleted automatically. The Controller can delete a project or its account at any time; this immediately deletes the associated events and API keys.

At the end of the Terms of Service, the Controller may choose between return and deletion. On request received before the account is deleted, the Processor will provide the Controller’s events in a common machine-readable format (JSON or CSV) within 30 days. Otherwise, and after any return, the data is deleted. Deleted data may remain in the database provider’s point-in-time recovery for up to 6 hours before it is overwritten; it is not restored from there except to recover from an incident. Statutory retention obligations remain unaffected.

8. Demonstration of compliance and audits

The Processor will provide the Controller with information and documentation needed to demonstrate compliance on request. On at least 30 days’ notice and no more than once per calendar year, the Controller may have an audit carried out by an independent auditor bound to confidentiality. An additional audit may be requested after a personal data breach or where there are reasonable grounds to suspect a material breach of this DPA. Audits take place during normal business hours, must not affect other customers and must protect trade secrets. Each party bears its own costs.

9. Final provisions and contact

This DPA is governed by German law. Mandatory data protection law and the powers of supervisory authorities remain unaffected. If this DPA conflicts with the Terms of Service on matters of data protection, this DPA prevails. Amendments require text form. If a provision is invalid, the remaining provisions remain in effect.

Contact for data protection matters and instructions: hello@useampersand.io.

Annex 1 — Technical and organisational measures

• Encryption in transit: all connections to the API and the dashboard use HTTPS; HTTP Strict Transport Security is enabled.
• Access control: sign-in uses one-time codes sent by email, with rate limits on how many codes can be requested. API keys are stored only as hashes keyed with a server-side secret and shown once when created; they can be revoked at any time.
• Separation: every dashboard query and every server action checks that the signed-in account owns the project; event queries are always limited to one project.
• Data minimisation: IP address and user agent are never stored; there are no database columns for them.
• Application security: a Content Security Policy and further security headers restrict what the browser may load and prevent framing of the dashboard.
• Confidentiality of secrets: production credentials are kept as encrypted environment variables of the hosting provider and are not accessible to customers.
• Availability: the database provider operates the database with redundancy and point-in-time recovery over the last 6 hours.
• Deletion: an automated daily job deletes events after the retention period of the plan; deleting a project or account deletes its data immediately.