# Data Processing Agreement

The Art. 28 GDPR agreement for the visitor data TryFast processes on your behalf, with our technical and organizational measures and the visitor erasure procedure. It is part of our terms on every plan.

Last updated: 2026-10-25

This Data Processing Agreement ("DPA") pursuant to Art. 28 GDPR is concluded between the customer using TryFast (the "Controller") and subprocess.eu/company, Osloer Str. 83, 13359 Berlin, Germany (the "Processor"). It forms part of the [Terms of Service](terms-of-service.md) for every workspace and every plan and applies without a separate signature. A countersigned copy is available on request from legal@tryfast.eu; Enterprise customers can agree custom terms.

## 1. Subject matter and duration

The Processor provides A/B testing for websites operated by the Controller: delivering the TryFast script and experiment configuration to the Controller's visitors, collecting the events the script sends, and computing experiment results. The DPA applies for as long as the Processor processes personal data for the Controller, including deletion after the end of the contract (section 12).

## 2. Nature and purpose of processing

Assigning visitors of the Controller's websites at random to variations of experiments the Controller defines; applying those variations in the visitor's browser; recording exposures, page views and conversions; counting visitors and tested users; computing statistics; showing recent events to the Controller's team and the AI agents it connects; erasing data on instruction. The purpose is to let the Controller evaluate and improve its websites.

## 3. Categories of data subjects and personal data

| Data subjects | Personal data |
|---|---|
| Visitors of the Controller's websites that run the TryFast script | random visitor id and visit id; visit information (visit number, new or returning, traffic type, device class, browser family); page URLs reduced to origin, path and `utm_*` parameters; the referrer's origin; experiments and variations shown; conversions (goal key, and as defined by the Controller: revenue, currency, order id, up to 10 properties); timestamps. IP addresses and the user agent are processed only transiently (rate limits, bot filtering, device class) and are not stored. |
| The Controller's team members while they browse the Controller's website, including with preview and visual editor links | the same technical data; preview traffic is marked as test traffic and never counted in results, and the visual editor sends no events. Their TryFast account data is processed by the Processor as controller (see the [Privacy Policy](privacy-policy.md)) |

The Controller does not send special categories of personal data (Art. 9 GDPR) or direct identifiers such as names, email addresses or phone numbers in goal keys, event properties, order ids or URLs.

## 4. Instructions

The Processor processes personal data only on documented instructions from the Controller, including with regard to transfers to third countries. The Controller's configuration in the app, through the REST API or the MCP server (in particular each project's domains, consent mode, experiments, goals and the deletion and erasure functions) is the primary documented instruction; further instructions are given in writing to legal@tryfast.eu. The Processor informs the Controller without delay if, in its opinion, an instruction infringes data protection law.

## 5. Responsibilities of the Controller

The Controller is responsible for the lawfulness of the processing, in particular for choosing a consent mode that fits the law applicable to its visitors, obtaining consent where it is required (by connecting its consent banner to the TryFast script), informing its visitors in its privacy notice, and answering their requests. [Privacy and consent](../docs/privacy-and-consent.md) describes the options and the data in detail.

## 6. Confidentiality

Persons authorized by the Processor to process personal data are committed to confidentiality. Today this is a single named operator; see [Compliance: Personnel and Confidentiality](compliance.md#personnel-and-confidentiality).

## 7. Security of processing (Art. 32 GDPR)

The Processor implements the technical and organizational measures in Annex 1. It may update them as technology develops, provided the level of protection does not fall below the measures described.

## 8. Subprocessors

The Controller grants general authorization for the subprocessors listed at [Subprocessors](subprocessors.md). The Processor announces intended additions or replacements on that page and by email to workspace owners at least 30 days in advance. The Controller may object on reasonable data protection grounds within that period; if no solution is found, the Controller may terminate the affected service before the change takes effect. The Processor imposes data protection obligations on each subprocessor that are no less protective than this DPA and remains responsible for their performance.

## 9. Data subject rights

The Processor supports the Controller with technical measures to answer data subject requests:

- **Erasure** of one visitor through the visitor erasure procedure in Annex 2, applied within a minute.
- **Objection and opt-out:** visitors can stop all processing on a website by opening it with `?tf_optout=1`, or through `tryfast.optOut()` from the Controller's own opt-out control.
- **Withdrawal of consent:** when the Controller's banner calls `tryfast.consent(false)`, the script deletes its browser storage and stops sending data.
- **Access:** on request to support@tryfast.eu with the visitor id, the Processor helps the Controller answer within the deadlines of Art. 12 GDPR.

Requests that reach the Processor directly are forwarded to the Controller without undue delay; the Processor does not answer them itself unless instructed.

## 10. Assistance

Taking into account the nature of processing and the information available to it, the Processor assists the Controller with its obligations under Art. 32 to 36 GDPR, in particular data protection impact assessments, by providing the information on this page, the [compliance page](compliance.md) and the [ISMS FAQ](isms-faq.md) and by answering questions in writing.

## 11. Personal data breaches

The Processor notifies the Controller (the owners and admins of the affected workspaces) of a personal data breach affecting the Controller's data without undue delay and at the latest within 72 hours of becoming aware of it, with the information required by Art. 33(3) GDPR as far as it is available, and provides further information as it becomes available.

## 12. Deletion and return

During the contract the Controller can export its data at any time through the documented API and as CSV (see [Compliance: Migration and Data Export](compliance.md#migration-and-data-export)). Deleting an experiment, a project or a workspace deletes its data: the script of a deleted project does nothing from that moment on, data in the application database is deleted immediately and data in the event database within minutes. Deleted data leaves the backups of the application database within 2 days and the backups of the event database and the raw event logs within 35 days. Unless the Controller deletes it earlier, the Processor deletes visitor data on the retention schedule in Annex 1, and all remaining data of a workspace no later than 30 days after the end of the contract. Activity log entries (who changed what in the workspace) are kept for 2 years as an audit trail, unless the law requires otherwise.

## 13. Audits

The Processor makes available all information necessary to demonstrate compliance with Art. 28 GDPR, in particular this DPA, the [compliance page](compliance.md), the [ISMS FAQ](isms-faq.md) and the certificates of its hosting provider. The Controller may audit the Processor, including through inspections by an auditor bound to confidentiality, where this information is not sufficient: with at least 30 days notice, during business hours, at most once a year unless a breach occurred, without access to other customers' data, and at the Controller's expense.

## 14. Data location

The Processor stores and processes the Controller's visitor data in Germany: on its production server in the data center of Hetzner Online GmbH in Nuremberg, with backups and raw event logs in Hetzner Object Storage in Germany. The Processor does not transfer this data to third countries.

The only exception is personal data the Controller or its team choose to include in an email to the Processor, for example a visitor id in an access request (section 9). Such emails are received in the Processor's support mailbox at Google Workspace (Google Cloud EMEA Limited), where Google may process them outside the EU under the EU Standard Contractual Clauses of its Cloud Data Processing Addendum (see [Subprocessors](subprocessors.md)). The Controller includes no more personal data in such emails than the request needs.

## Annex 1: Technical and organizational measures

**Physical access control.** All systems run in data centers of Hetzner Online GmbH in Germany (the production server in Nuremberg, backups in Hetzner Object Storage in Germany), certified to ISO/IEC 27001, with access control, video surveillance and staffed security. The Processor operates no hardware of its own.

**System access control.** Server access only for the named operator, with SSH keys (no passwords). Multi-factor authentication on the hosting console, object storage management, domain registrar and code hosting accounts. Operator functions only on a loopback-only interface with a separate admin token. Users of TryFast sign in through login0, which requires two-factor authentication or a passkey for every user.

**Data access control.** Roles per workspace (owner, admin, member, viewer). API keys and AI agent connections with permission levels (read, build, full) that never exceed the current role of their creator and are revoked when the creator leaves the workspace. Launches by keys and agents without full access require a person's approval. Every read is filtered by the caller's workspaces inside the database query; another workspace's data answers "not found", covered by an automated test matrix.

**Separation control.** Each workspace's data is separated logically and checked on every request. The visitor id is a first-party value of each website, and the event database stores it only as a hash computed per project, so a visitor cannot be linked across projects or customers. Scripts for websites are served from a separate host, `cdn.tryfast.eu`, that never reads or sets cookies.

**Pseudonymization and data minimization.** Visitor ids are random (128 bits), not derived from personal data, and expire at most 390 days after creation; the event database stores them only as hashes, and raw event logs keep them for 30 days. No IP addresses are stored; no access logs are written. Page URLs are reduced to origin, path and `utm_*` parameters; referrers to their origin. Attributes set for targeting stay in the visitor's browser. Order ids are stored only as hashes for de-duplication.

**Transfer control.** All connections use TLS, with HSTS on tryfast.eu; backups are transferred over TLS. Secrets (API keys, OAuth tokens, recovery and invitation tokens, browser grant cookies) are stored only as SHA-256 hashes; session cookies are HMAC-signed.

**Input control.** Every change to a workspace (projects, experiments, launches, approvals, members, keys, agent connections, erasures) is written to the activity log with the actor and the time, kept for 2 years.

**Availability and resilience.** Daily copies of the application database and copies before every update; event database copies every 6 hours; raw event logs for 30 days to rebuild the event database; all copies kept in Germany, today on the production server, with copies to separate object storage in Germany being set up; documented restore drill. The script fails safe: if it cannot be loaded, visitors see the original pages, and the page is hidden at most for the anti-flicker timeout (800 ms by default). Rate limits and bounded queues protect the service under load.

**Retention.** Raw event logs 30 days; per-visitor experiment data while the experiment runs and 90 days after it stops; daily visit data 35 days; hashed order ids 90 days; the monthly tested-visitor list for the current month (the previous month until the 3rd); the recent events view 24 hours, in memory only. Totals without visitor data 400 days, experiment results until deletion.

**Regular testing and evaluation.** An automated test suite runs on every change, including tenancy isolation, CSRF, outbound fetch restrictions, code injection checks at publish time, OAuth flows and a schema test that no database column stores an IP address. Dependencies are few, pinned and updated on security advisories; operating system updates are applied regularly.

**Data protection by design and by default.** New projects wait for the visitor's consent and store nothing before it. Custom JavaScript is compiled and checked when saved; HTML changes may not contain scripts. Visitors can opt out on any website with `?tf_optout=1`.

## Annex 2: Visitor erasure procedure

1. **Find the visitor id.** On the visitor's device, open the website's browser console and run `tryfast.state().visitorId`, or read the `tf_vid` cookie of the website: the visitor id is the part before the dot.
2. **Erase.** An owner or admin of the workspace (signed in), or an API key with write permission, sends `POST https://tryfast.eu/api/v1/projects/{project_id}/visitors/erase` with the body `{"visitor_id": "<visitor id>"}`. The request answers `202` and is recorded in the activity log. Erasure is not available to AI agents through the MCP server.
3. **Effect.** Within a minute, the visitor's experiment assignments, conversions, daily visit rows and monthly tested-visitor row in that project are deleted. Totals already counted and final results are not recalculated. Raw event logs containing the visitor id expire within 30 days, backups within 35 days.
4. **Stop further collection.** Ask the visitor to withdraw consent in your banner or to open your website once with `?tf_optout=1`; otherwise a returning visitor with the same browser storage is counted again.

The same steps are described for developers in [Privacy and consent](../docs/privacy-and-consent.md#erase-one-visitor).