Data Processing Agreement

Annex to the RealStat Terms of Service. Version 2026-09-17.

Between Доманська Дарина Юріївна, individual entrepreneur (ФОП) registered in Ukraine, tax number 3772111103, Україна, 09108, Київська обл., Білоцерківський р-н, місто Біла Церква, ("RealStat", "we") and the customer accepting the Terms of Service (the "Customer", "you").

This agreement is accepted at sign-up and forms part of the Terms. Where it conflicts with the Terms on matters of personal data, this agreement prevails.

In sections 3 to 12, "Processor" means RealStat and "Controller" means the Customer. Those sections were written for the processing described in section 1.2; where they are applied to the jointly controlled processing in section 1.1, they are read as obligations RealStat owes the Customer in addition to, and not instead of, the allocation in section 1.4.

1. Roles

The processing carried out through RealStat is not all of one kind, and a single label would misdescribe it. It splits into three layers, each with its own allocation of roles.

1.1. Attribution — joint control (Art. 26 GDPR)

For the processing that makes attribution work — collecting the click, matching it to a join, and transmitting the resulting conversion event to the advertising platforms — you and RealStat are joint controllers.

We say so because it is accurate rather than convenient. You determine the purpose: which channel to connect, which ad account to report into, which event to report as, and why. But we determine essential means: which categories of data are collected, how the click and the join are matched, how identifiers are hashed before transmission, and how long each category is retained. Where two parties jointly determine purposes and means in this way, Art. 26 applies, and describing the arrangement as processor-only would not survive scrutiny.

1.2. Messaging, exports and dashboards — processing on your instruction

For welcome messages, broadcasts and drip series, subscriber exports, and the statistics shown in the dashboard, you are the controller and RealStat is the processor. Here we determine nothing: the audience, the content, the timing and the frequency are yours, and we act only on your documented instruction. Configuring a project, a welcome message or a broadcast in the RealStat dashboard constitutes a documented instruction.

Sections 3 to 12 of this agreement apply to this layer in full, and apply to the layer in section 1.1 to the extent compatible with joint control.

1.3. Your own account — our controllership

For the data of the Customer as such — account, login, billing, support correspondence, service security — RealStat is the sole controller, under its own Privacy Policy. This agreement does not apply to that data.

1.4. The joint control arrangement (Art. 26(1))

The respective responsibilities of the parties are allocated as follows. This table is the arrangement required by Art. 26(1), and its essence is published in our Privacy Policy as Art. 26(2) requires.

Point of contact for data subjects. The Customer is the point of contact, because it is the Customer's channel the data subject joined and the Customer's privacy notice they were shown. RealStat's contact details are nevertheless published, and a request reaching us is forwarded under section 7.

1.5. What the arrangement does not do (Art. 26(3))

The allocation in section 1.4 governs the relationship between the parties. It does not limit the rights of data subjects.

Under Art. 26(3) GDPR, a data subject may exercise their rights against each of the joint controllers, irrespective of how responsibilities are allocated between them. Neither this agreement nor the indemnity in the Terms of Service changes that, and neither party will represent to a data subject or to a supervisory authority that it does.

Between the parties, the indemnity in section 3.1 of the Terms of Service applies: where a claim, complaint or penalty reaches RealStat because a responsibility allocated to the Customer above was not met, the Customer bears the resulting cost.

2. Subject matter

Categories of personal data: Telegram user identifier (chat_id), username, first and last name as provided to Telegram; join, leave and block timestamps; advertising click identifiers (fbclid, ttclid) and advertising cookies (_fbp, _ttp); IP address; user agent; landing page URL; campaign, ad set and ad names.

Special categories: none. The Controller undertakes not to introduce special categories of data through campaign names, creative names or message content.

3. Processor obligations

1. Process personal data only on the Controller's documented instructions, including for transfers to third countries, unless required otherwise by law — in which case the Processor informs the Controller before processing, unless that law forbids it.
2. Ensure that everyone authorised to process the data is bound by confidentiality.
3. Implement the measures in section 5.
4. Engage sub-processors only under section 4.
5. Assist the Controller in responding to data subject requests, taking into account the nature of the processing (see section 7).
6. Assist the Controller with security, breach notification and data protection impact assessments, taking into account the information available to the Processor.
7. At the Controller's choice, delete or return all personal data at the end of the service, and delete existing copies unless legally required to keep them.
8. Make available the information necessary to demonstrate compliance, and allow audits under section 8.

4. Sub-processors

The Controller gives general authorisation for the sub-processors listed in списку субпроцесорів, which is incorporated by reference.

The Processor will notify the Controller by email at least 30 days before adding or replacing a sub-processor. The Controller may object on reasonable data-protection grounds within that period; if the objection cannot be resolved, the Controller may terminate the affected service and receive a pro-rata refund for the unused period.

The Processor remains fully liable to the Controller for its sub-processors' performance.

5. Security measures

• Encryption in transit: TLS for all connections.
• Encryption at rest for credentials: advertising-platform and bot tokens are encrypted with Fernet (AES-128-CBC with HMAC-SHA256), with keys held outside the database and supporting rotation without downtime.
• Secret hygiene: tokens are never rendered back into the dashboard, and are stripped from error messages and logs before storage.
• Data minimisation at source: the service reads only the Telegram updates it needs. It does not read channel content or subscriber correspondence.
• Pseudonymisation on transfer: identifiers sent to advertising platforms are hashed with SHA-256 and are not reversible.
• Access control: production access is limited to named individuals with individual accounts.
• Resilience: daily backups, encrypted, with documented restore.
• Testing: an automated test suite covering the attribution and credential-handling paths runs on every change.

6. Retention and erasure

On the Controller's instruction, the Processor erases specified personal data within 30 days, including from backups at their next rotation.

7. Data subject requests

Data subjects will normally contact the Controller, since it is the Controller's channel they joined and the Controller's privacy notice they were shown.

Where a data subject contacts the Processor directly, the Processor acknowledges the request within 5 working days and forwards it to the Controller without undue delay. For processing under section 1.2 the Processor does not respond substantively, because it has no authority to do so. For the jointly controlled processing under section 1.1, the Processor does not refuse the request on the ground that the Controller is the point of contact — Art. 26(3) does not allow that — and the two parties cooperate so that the request is answered within the one-month period of Art. 12(3), the Controller leading.

The dashboard lets the Controller export and delete an individual subscriber's data without involving the Processor's staff, which is how most requests should be satisfied.

8. Audits

The Processor will respond to reasonable written information requests about its data protection practices within 30 days.

The Controller may audit on 30 days' written notice, no more than once per year, during business hours, without disrupting the service, and subject to confidentiality. The Controller bears the cost unless the audit reveals material non-compliance.

9. International transfers

The Processor's infrastructure is located in Франція.

Conversion events are transmitted to Meta and TikTok, which are established in the United States. These transfers rely on the EU Standard Contractual Clauses and/or the EU-US Data Privacy Framework where applicable, and are made into the Controller's own advertising account, using credentials the Controller supplied — the Controller is the party with the direct relationship with those platforms and accepts their terms independently.

10. Breach notification

The Processor notifies the Controller without undue delay and in any event within 48 hours of becoming aware of a personal data breach, providing the nature of the breach, categories and approximate number of data subjects and records affected, likely consequences, and the measures taken or proposed.

11. Liability

Liability under this DPA is subject to the limitations in the Terms of Service, except where those limitations are not permitted by applicable data protection law.

12. Term

This DPA takes effect when the Controller accepts the Terms and remains in force while the Processor processes personal data on the Controller's behalf. Sections 6, 8 and 11 survive termination.