Data Processing Agreement
The Article 28 GDPR terms under which the hosted service processes end-visitor event data on behalf of site and app operators.
1. Parties and roles
This Data Processing Agreement ("DPA") is between:
- The operator — the person or entity that creates a project on the hosted tgram-analytics service and integrates the SDK (or ingestion API) into their website or app. For the event data collected from their end-visitors, the operator is the controller within the meaning of Art. 4(7) GDPR.
- tgram-analytics — the provider of the hosted service at
tgram-analytics.com(see Who we are). For that same event data, tgram-analytics is the processor within the meaning of Art. 4(8) GDPR.
This DPA covers only the hosted service. If you self-host the open-source server, tgram-analytics processes nothing for you and this DPA does not apply. It also does not cover your own account data as a bot user — for that data tgram-analytics is a controller, as described in the privacy policy.
2. Subject matter, duration, nature and purpose
Subject matter. The processing of analytics event data submitted to the operator's project(s) through the tgram-analytics SDKs or ingestion API.
Duration. This DPA applies for the life of the operator's project(s) on the hosted service — from the first event received until all associated event data has been deleted in accordance with section 7.
Nature and purpose. The processing consists of: receiving events at the ingestion API; deriving coarse, non-identifying fields at ingestion (visitor hash, browser family, OS family, device type); storing events; aggregating them into counts, reports, charts, funnels, and alerts; and delivering those aggregates to the operator via Telegram and, where enabled, the read-only MCP interface. The sole purpose is providing audience-measurement and event-analytics functionality to the operator. The processor does not use event data for its own purposes — no advertising, no profiling, no resale.
3. Categories of data and data subjects
Data subjects: end-visitors and users of the operator's websites and apps.
Categories of personal data (described in full in What we collect):
- Event names chosen by the operator
- Session IDs (generated client-side, tab-scoped)
- Daily-rotating, truncated one-way visitor hashes (derived in-memory from IP and User-Agent, which are themselves never stored)
- Page URLs and referrers, for pageview events
- Coarse derived fields: browser family, OS family, device type
- Operator-supplied event properties (capped at 4 KB per event)
No special categories. The service is not designed for special-category data (Art. 9 GDPR) and the operator agrees not to submit it. The operator is responsible for what they place in event properties — see section 4 and the docs on keeping personal data out of properties.
4. Processor obligations
tgram-analytics, as processor:
- Processes only on documented instructions (Art. 28(3)(a)). The operator's instructions are: each event sent (process it as described in section 2), the project configuration set via the bot (retention window, alerts, funnels), and deletion or export requests. The processor will not process event data beyond these instructions unless required to by EU or member-state law, in which case it will inform the operator before processing unless that law forbids it.
- Confidentiality (Art. 28(3)(b)). Access to production data is limited to the single individual who operates the service (see Who we are), who is committed to confidentiality.
- Security (Art. 32 via Art. 28(3)(c)). The technical and organizational measures in place are the ones described factually in the privacy policy, in summary:
- All event data is hosted on a server in the European Union
- Raw IP addresses and User-Agent strings are never persisted — used in-memory at ingestion, then discarded
- Unique visitors are counted via daily-rotating salted one-way hashes; yesterday's salt is unrecoverable
- Visitor hashes are bound to a single project, preventing cross-project or cross-site correlation
- A PII-key tripwire drops event properties whose keys carry common PII names (
email,phone,password,token,credit_card, etc.) before storage - Server logs pass through a redaction filter that strips API keys and obvious PII before they are written
- Project API keys are stored only as SHA-256 hashes; raw keys are never persisted
- No onward disclosure. Event data is not sold, shared with, or made accessible to anyone except the sub-processors listed in section 5.
5. Sub-processors
The operator grants general written authorization (Art. 28(2)) for the sub-processors currently engaged:
- EU hosting provider for the server and database, managed via Coolify — this is where event data lives. Located in the EU.
- Telegram — message transport for delivering reports, charts, and alerts to the operator's chat. Telegram carries the aggregate outputs sent to the operator, not the raw event stream.
The authoritative, current list is the Sub-processors section of the privacy policy — specifically its "Bot and ingestion API" subsection, which covers the surface where event data lives. The processor gives notice of intended additions or replacements by updating that page (and its revision date) before the change takes effect, per its Changes section. An operator who objects to a change may terminate at any time by deleting their project(s), which erases all associated data immediately (section 7).
6. Assistance to the controller
Data-subject rights (Art. 28(3)(e)). Because the service is data-minimized by design — no stored IPs, no names, daily-rotating hashes — the processor generally cannot single out an individual end-visitor inside a project. Assistance is therefore structural: the operator can delete a project at any time from the bot, which immediately cascades to every event in it; the operator can lower the retention window; and the operator can request an export of their project data via email (see Your rights). Taking the nature of the processing into account, the processor will provide reasonable further assistance on request.
Breach notification (Art. 28(3)(f)). The processor will notify affected operators without undue delay after becoming aware of a personal-data breach affecting their event data — via the bot and/or the contact channels in the privacy policy — including the information reasonably available so the operator can meet their own Art. 33/34 duties.
7. Deletion and return of data
- Events are deleted automatically under the per-project retention window (default 90 days; the operator can lower it at any time). A nightly job removes anything older.
- The operator can delete any project at any time via the bot; deletion cascades immediately to every event in the project.
- On termination of the relationship (deletion of the operator's projects or account), all associated event data is deleted. Operators who want a copy first can request a JSON export beforehand, per Your rights.
8. Audit and information
In place of on-site audit rights — disproportionate for a free, single-operator service — transparency works like this: the server source code is public at github.com/tgram-analytics/server, so the ingestion pipeline, visitor hashing, PII tripwire, retention job, and deletion cascade can be inspected directly rather than taken on faith. In addition, the processor will make available on written request the further information reasonably necessary to demonstrate compliance with Art. 28 (Art. 28(3)(h)). Operators whose compliance framework requires contractual on-site audits or bespoke terms should self-host instead (section 10).
9. International transfers
The processor performs no transfers of event data outside the EU: ingestion, storage, aggregation, and chart rendering all happen on the EU-hosted server (see Where it lives). Delivery of aggregate reports and alerts to the operator's chat necessarily transits Telegram's infrastructure, as disclosed in the privacy policy — that delivery channel is inherent to the service the operator chose.
10. Liability, governing law, and alternatives
Liability. Each party is liable in accordance with Art. 82 GDPR and its role in the processing; nothing in this DPA excludes liability that cannot lawfully be excluded. Beyond that, the hosted service is provided free of charge and, to the maximum extent permitted by applicable law, without further contractual liability of the processor.
Governing law. This DPA is governed by the law of an EU member state. Where anything in this DPA conflicts with mandatory provisions of the GDPR, the GDPR prevails.
Special requirements. Operators who need a signed DPA, specific jurisdiction clauses, audit rights, or other bespoke terms have a clean alternative: self-host the open-source server on infrastructure of their choice, in which case no processing by tgram-analytics takes place at all. Questions about this DPA: rignanese.leo@gmail.com.