Data Processing Addendum.

01

Roles and scope

For personal data of visitors to your registered sites, you (the customer) are the controller and the operator of Kehai is your processor under GDPR Art. 28. This Addendum forms part of every subscription automatically and needs no signature round-trip. A countersigned PDF for procurement is available from privacy@kehai.io.

For your own account data (name, address, billing details), the operator is an independent controller rather than your processor. That processing is covered by the Privacy Policy and this Addendum does not govern it. The two roles are separate throughout: nothing here gives the operator a controller's discretion over visitor data, and nothing in the Privacy Policy makes you the controller of your own account record.

Terms used here carry the meaning given to them in the GDPR, Regulation (EU) 2016/679. Where this Addendum says the operator, it means salecki.digital Mikołaj Salecki, the entity named in the Privacy Policy.

02

Instructions

The operator processes visitor personal data only on your documented instructions, including as to transfers to a third country. Your instructions are: this Addendum, the Terms of Use, and the configuration you set in the panel, which is where you choose retention, exclusions, goals, and what a site records. Configuring the product is instructing the processor, and no separate instruction document is required.

The operator processes on another basis only where EU or Polish law requires it. In that case you are informed of the requirement before processing, unless that law prohibits the notice on important grounds of public interest.

If the operator considers an instruction to infringe the GDPR or another data protection provision, it will inform you without delay, as Art. 28(3) requires. The operator may suspend the affected processing until the instruction is withdrawn or confirmed.

03

Confidentiality

Every person authorized to process visitor data is bound by an obligation of confidentiality that survives the end of their engagement. Access is on a need-to-know basis and is limited to what the person's work requires.

The operator is a sole trader. In practice this means the set of authorized persons is small and named rather than a role that anybody can hold, and selected administrative changes are recorded in the account audit trail. This is not a log of every infrastructure access.

04

Security

The operator implements the technical and organizational measures required by Art. 32, described in Annex II. Those measures take into account the state of the art, the cost of implementation, and the nature, scope, context, and purposes of the processing, as well as the risk to the rights and freedoms of natural persons.

Pseudonymization here is structural rather than added. A visitor identity is a one-way hash over the site, the network address, and the user agent, salted with a value that is replaced every day at 00:00 UTC. Raw network addresses are used during processing and may remain in intake rate-control memory for up to three minutes. Human user-agent strings are parsed and discarded after processing. Declared bot strings can be retained for the site's retention window, as section 12 explains. Infrastructure providers process requests separately. No reverse lookup table is maintained, but the same inputs can reproduce a day's visitor code while that day's salt remains available.

The operator may update a measure at any time, provided the level of protection is not reduced.

05

Sub-processors

You give general written authorization for the operator to engage sub-processors. The sub-processors engaged at the date of this Addendum are listed in Annex III.

The operator binds each sub-processor by contract to the data protection obligations required by GDPR Art. 28(4), including sufficient guarantees for appropriate technical and organizational measures. Where a sub-processor fails to fulfil those obligations, the operator remains fully liable to you for the performance of that sub-processor's obligations.

The operator gives you at least 7 calendar days' notice by email before a planned addition or replacement of a sub-processor. You may object on reasonable data protection grounds within that period. If the objection cannot be resolved, you may terminate the affected subscription and export your data without penalty, and fees for the unused remainder of the term are refunded.

06

Data subject requests

The operator does not respond directly to a visitor exercising rights against you. A request that reaches the operator is forwarded to you without undue delay, and the operator tells the visitor to approach you.

The operator assists you, by appropriate technical and organizational measures and insofar as this is possible, in fulfilling your obligation to respond to requests under Chapter III of the GDPR.

For visitor requests, the operator first checks whether the relevant event rows can be located using information already available or supplied with the request. Once that day's salt has been discarded, Kehai cannot recompute that day's visitor code from the original address and user agent. That does not mean no records are held: rows remain for the site's retention window, and the customer may be able to identify relevant rows from their own information. The operator will explain any limits on identification and assist with the request.

Where a request concerns a period still within the identity window, the operator assists with the technical means available. Assistance is provided at no additional charge unless a request is manifestly unfounded or excessive.

07

Personal data breach

The operator notifies you without undue delay, and in any event within 48 hours of becoming aware of a personal data breach affecting visitor data processed under this Addendum. Notice goes to the account owner's address and to any security contact you have registered.

The notice describes the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where the information cannot be provided at once, it is provided in phases without further undue delay.

The operator cooperates with you and takes reasonable steps to mitigate the effects. Notifying the supervisory authority under Art. 33 and the data subjects under Art. 34 remains your obligation as controller, and the operator does not make either notification on your behalf without your instruction.

08

Impact assessments

Taking into account the nature of the processing and the information available to it, the operator assists you with your obligations under Arts. 32 to 36: security of processing, breach notification and communication, data protection impact assessments, and prior consultation of the supervisory authority.

Assistance for an impact assessment means the operator provides what it knows about the processing: what is collected, what is stored, where, for how long, and under what measures. Much of that is already published in this Addendum and its annexes, which is deliberate: an assessment should not require a support ticket.

09

International transfers

The primary application and analytics databases run in Warsaw, Poland. They use the operator-managed OVHcloud server. Backup object storage is also configured in the Warsaw region. Stored location does not confine all processing to Poland. OVHcloud's published terms permit authorized group support outside the EEA, including in Canada and the United Kingdom, and provide safeguards for onward transfers. The edge and email processing described below are separate paths.

Public requests pass through an international edge network. The intake hostname sits behind Cloudflare, which terminates TLS and provides reverse proxying and denial of service protection at edge locations worldwide. The whole request, including its body, transits that edge before reaching the operator's servers: Cloudflare terminates TLS, so the network address, the user agent, the requested address, the headers, and the event itself are readable there. Nothing is stored by Cloudflare as an analytics record. Cloudflare, Inc. is established in the United States.

International transfers must have a valid basis under GDPR Chapter V. The operator must keep the applicable contractual and transfer-assessment records. Cloudflare's published DPA forms part of its service terms and includes transfer provisions. Where Standard Contractual Clauses apply to Kehai as a processor using a sub-processor, Module Three is the relevant relationship.

The transfer assessment must account for the whole request at the edge, including the raw network address, user agent, URL, headers, and body. Hashing later at intake does not remove that earlier processing or make the raw request anonymous. The operator must assess the provider's processing and safeguards rather than relying on salt rotation alone.

If the operator receives a legally binding request from a public authority for visitor data, it will challenge the request where there are reasonable grounds, disclose only the minimum permitted, and notify you unless legally prohibited from doing so. Where notice is prohibited, the operator will seek a waiver and will inform you as soon as it is permitted to. The operator holds pseudonymous event rows and aggregates. A visitor code can be recomputed from the same inputs while its day's salt is available. After that salt is discarded, this lookup is unavailable, but retained attributes or information held by the customer may still identify relevant rows.

Enabled email reports have a separate international processing path. An enabled alert or digest is sent through Resend and can carry the site's name, the selected filters and aggregate figures. It does not attach raw event rows or visitor codes. Resend stores message content and delivery logs in the United States. Its DPA includes applicable Standard Contractual Clauses, and the operator must retain the contractual and transfer evidence that applies to this processing. Optional Google connections have separate purposes and terms described in the Privacy Policy and sub-processor list. They read the selected Google data and do not send Kehai's event stream to Google.

10

Audit and information

The operator makes available to you all information necessary to demonstrate compliance with Art. 28 and allows for and contributes to audits, including inspections, conducted by you or an auditor you mandate.

In practice: once in any twelve month period, on 30 days' written notice, and starting with a written questionnaire and the documentation in these annexes. An on-site inspection follows where the questionnaire does not answer a specific and reasonable concern, at a time agreed between us, under a confidentiality undertaking, and without access to any other customer's data or to the operator's own confidential material.

You bear your own costs. The operator bears its own costs for the first audit in a period, and may charge its reasonable time for any further audit in the same period unless that audit follows a personal data breach or a material finding.

More frequent audits are permitted where a supervisory authority requires them.

11

Return and deletion

At your choice, on termination or expiry, the operator deletes or returns visitor data and deletes existing copies, unless EU or Polish law requires storage.

The mechanics are fixed so nothing depends on a support request. The account remains readable for 30 days after the subscription ends, during which retained analytics data can be downloaded in open formats through the panel. The reporting API exports the reports it supports. Account credentials and secrets are not part of these exports. After the 30-day export window, the site becomes due for erasure. The scheduled hourly sweep normally removes its analytics data within a day. The contractual deadline is 30 days after the export window ends, including recovery from a failed sweep. The product backup tooling prunes a seven-day rolling window. The object-storage lifecycle separately makes backup objects eligible for expiration after eight days, followed by the provider's deletion processing. The security page describes the current configuration and verification limits. Copies of deleted data must leave within their applicable backup window and, in any event, within 90 days of the account's deletion, which is the ceiling this Addendum commits to.

The operator certifies deletion in writing on request.

12

The thin-processing principle

The processing under this Addendum is deliberately thin, and the consequence is contractual rather than rhetorical.

Raw IP addresses are used for geolocation, daily identity, and rate controls. Rate controls hold them in memory for up to three minutes. Human user-agent strings are parsed and discarded after request processing. For requests classified as bots, up to 512 characters of the declared user agent are retained with the bot event for the site's retention window. Infrastructure providers separately process the request, including its body at the edge. The visitor hash uses a salt replaced at 00:00 UTC. What is stored is an event row: the time, a path and its query string minus the blocked names, a referrer hostname, campaign parameters, a country, region, and city, a browser and operating system family, a device class, the page's field performance, whatever events and properties you chose to declare, the orders your server sent, and two random-looking numbers, the day's visitor code and a visit code. The rows stay for the site's retention window. The browser tracker writes no cookie and places nothing in browser storage. For new measurements, a visit ends after 30 minutes without activity or at midnight UTC, whichever comes first; neither its code nor its attribution is carried into the next UTC day. The day's salt is no longer used for counting after that boundary. Historical rows, including older visits that crossed midnight UTC, remain for their retention window, and earlier exports and backups are not rewritten. Recorded times, paths, and declared properties may provide other ways to link events.

The analytics store contains pseudonymous event rows, not a directory mapping daily codes to named visitors. Rows, including declared-bot user agents, paths, query parameters, and event properties, can still contain identifying information. Access requests are assessed against available information. Neither salt rotation nor a missing lookup table establishes that no personal data is held.

The operator does not sell visitor data, does not share it for cross-context behavioral advertising, does not use it to build advertising profiles, and does not send analytics data to a model for its own purposes. Customer-authorized assistant access and exports remain under the customer's instructions. This includes eligible Google Ads conversion files containing supplied GCLIDs, action names, actual conversion times, net amounts, currencies and random conversion identifiers. A customer can download the file or explicitly create dedicated HTTPS credentials for a recipient to retrieve it. The recipient is selected by the customer; no advertising account connection or transfer is enabled by default. Revocation stops future retrieval and does not withdraw copies already transferred. These are commitments, not descriptions of current practice that could change quietly.

Optional commerce integrations also require connection credentials and operational identifiers. Kehai encrypts stored provider API keys and webhook signing secrets, and removes them on disconnect. Provider responses from Stripe, Wix and Squarespace are processed to extract the supported commerce fields; raw customer profiles and provider responses are not retained in analytics. Source references, account identity, a financial consistency hash, delivery timestamps, bounded failure categories and canonical retry records are processed to validate and deliver the customer's supported orders. Processed inbox entries are retained for up to 30 days; prepared payloads are cleared on success or after 48 hours unresolved. The minimal source/delivery ledger remains for the site's lifetime to prevent duplicate replay. Scheduled cleanup and backups have their separate deletion windows. Provider customer and order identifiers remain outside the analytics payload. The customer-installed WooCommerce and PrestaShop adapters may use existing shop sessions or carts and order records for bounded acquisition context. They create no new analytics cookie or cart solely for attribution and remain subject to the customer's configuration and lawful instructions. Wix and Squarespace receive attribution only through explicit order fields. Shop-side retention and platform copies have their own deletion controls.

A commerce source removed at the provider leaves its analytics and operational records under the deletion windows above. An administrator downloads the report for the store owner to handle the request. Erasure is marked complete only after the linked analytics and operational records have been removed and checked. Minimal keyed suppression hashes remain to prevent the erased source from being imported again after reconnection. They do not retain the original customer or order identifier.

13

Liability, precedence, and law

Liability under this Addendum follows the limitation in the Terms of Use §16, except where GDPR Art. 82 or other mandatory law provides otherwise. Nothing here limits either party's liability to a data subject.

Where this Addendum conflicts with the Terms of Use on a data protection matter, this Addendum prevails. Where it conflicts with the Standard Contractual Clauses, the Clauses prevail.

Governing law and jurisdiction follow the Terms: Polish law, and the courts of Warsaw. The competent supervisory authority is the President of the Personal Data Protection Office (Prezes Urzedu Ochrony Danych Osobowych), Warsaw, Poland.

annex i

Details of Processing

Set out in the structure the Standard Contractual Clauses expect, so it can be attached to them without rewriting.

A. Parties

B. Description of the processing

C. Competent supervisory authority

The President of the Personal Data Protection Office (Prezes Urzedu Ochrony Danych Osobowych), ul. Stanisława Moniuszki 1A, 00-014 Warsaw, Poland.

annex ii

Technical and organizational measures

The measures the operator has implemented under Art. 32. Each one is a description of what is in place, not an aspiration.

Pseudonymization and minimization

• ·A visitor code is a one-way hash over the site, the network address, and the user agent, salted with a random value that is replaced daily at 00:00 UTC. For new measurements, visits end after 30 minutes without activity or at midnight UTC, whichever comes first. The previous day's salt, visit code, and attribution are not used to continue activity into the next UTC day.
• ·The network address is used for daily identity, geolocation, and rate controls. Rate-limit memory holds raw addresses for up to three minutes. The analytics database stores no raw IP address. Infrastructure logs are a separate processing path described in the Privacy Policy
• ·The browser tracker sets no cookie and writes no visitor identifier to browser storage; an optional shop integration can use an existing shop session as described above
• ·Page titles are not collected. Intake removes the current editable site list of blocked query parameter names. The installation tag loads one script, the same bytes for every site; it carries no per-site configuration, so a list change takes effect on the next event that arrives. Older tags with copied exclusions keep those values until replaced or updated. Unblocked query values, including campaign click and sharing identifiers, are retained within the URL and query limits and can link records independently of daily visitor codes
• ·Commerce events carry amounts, item lines, a coupon code, and the supplied landing context. They may also carry an explicitly supplied actual conversion time and a separate random conversion identifier generated by Kehai for stable export deduplication. That identifier is not the customer's shop order number or the private collector acceptance identity. Intake refuses transaction_id, order_id, customer_id, and email outright, and refuses a coupon or an item name carrying an email address, a phone number, or a network address. A shop issuing per-customer codes sends a campaign code instead, which the Terms require

Encryption

• ·TLS from the visitor's browser to the intake host and to the panel, terminated at the edge and again at the operator's own proxy. The databases are reachable only from inside the machine that runs them and from no network address outside it
• ·Modern cipher suites only, with HTTP Strict Transport Security and preloading on the public hostnames
• ·Authenticator secrets and backup codes are encrypted at rest with XChaCha20-Poly1305. The credentials the service holds for a customer's analytics imports and Stripe commerce connections use AES-256-GCM. Tokens from signing in with Google or Apple are stored by the authentication library without that additional layer
• ·Passwords are stored as salted hashes using a memory-hard function, never in a reversible form

Access control

• ·Administrative access is limited to authorized persons. Selected account and configuration changes enter a hash-chained audit trail. Changing a recorded entry without recomputing its later chain is detectable, but this is not an independent record of every infrastructure access. A second factor is available to every account and is not yet enforced for administrators
• ·Roles inside a customer account are separated: reading a report, changing a site, and managing billing are distinct permissions
• ·Every read of analytics data is scoped to the customer account that owns it, checked in the configuration database before the analytics database is queried
• ·The application services run in containers as non-root users. Some service credentials and infrastructure remain shared between Kehai components

Separation

• ·The customer account is the isolation boundary. Configuration and account identity live in one database and analytics rows in another. The application resolves an authorized site to its analytics-store identifier before querying its data
• ·An identifier supplied by a caller never becomes the identifier used to query analytics data
• ·Measured values and modeled values never share a numeric column, so a projection cannot be read as a measurement

Availability and restoration

• ·The coordinated product backup tooling captures both databases at one recovery point, excludes visitor salts, checks archived objects and prunes a seven-day rolling window. Backup storage is configured in Warsaw with a separate eight-day object-expiration rule. On September 10, 2026, isolated exercises restored synthetic product data through object storage, existing production cloud archives, and fresh database captures from the corrected machine backup script. This did not boot all applications on a rebuilt host or validate every historical archive
• ·Every archived object is checksummed as it is streamed, so a truncated copy fails before it can overwrite anything
• ·Restoration is run by a person and never automatically, because an automated restore is a way to lose data twice
• ·The coordinated product backup excludes visitor salts, and the machine backup's logical database dumps are configured to exclude them too. This does not certify every older archive or storage copy. Event rows and their recorded codes remain until their backup window ends.
• ·Readiness of both databases is checked continuously and an instance that cannot reach them stops receiving traffic

Testing and change control

• ·Every change passes an automated gate before it can be released: type checking, linting, a unit suite, database integration suites against real PostgreSQL and ClickHouse, and a production build
• ·Schema changes are versioned migrations with a checksum ledger. An applied migration cannot be edited, and production refuses one that has changed
• ·Dependencies are pinned to a committed lockfile and reviewed by hand; no automated scanner runs against them yet. The collection script ships with no runtime dependencies at all
• ·Releases are verified after deployment by confirming that the running revision is the intended one and that both databases answer

Organizational

• ·Confidentiality obligations for every authorized person, surviving the end of the engagement
• ·Credentials are held outside the source repository and never appear in code, in a commit, or in a log
• ·Sub-processors are bound by written data protection terms as required by GDPR Art. 28(4), and the list is published rather than provided on request
• ·Incidents are recorded with what happened, what caused it, and what changed as a result

annex iii

Sub-processors

The direct providers engaged for visitor-data processing at the date above. Their published lists identify the providers they use in turn. The service-provider page separately describes account, payment, communication and optional sign-in processing.

OVHcloud · storage in Poland

Cloudflare, Inc. · United States

Plus Five Five, Inc. (Resend)

Parties that are not sub-processors under this Addendum

Stated explicitly, because their absence from the list above is a fact worth relying on rather than an oversight. Stripe processes the customer's payments to Kehai and related billing data outside the visitor-processing instructions of this Addendum. Separately, when a customer connects its own Stripe account for commerce reporting, Kehai reads the authorized payment records under that customer's instructions covered by this Addendum. Stripe is the customer's selected source service; Kehai does not send its collected analytics rows back to Stripe.

Kehai runs its own analytics software. The software that counts page views is the operator's own, on the dedicated server named in Annex III. Kehai does not sell analytics data or send it to a model for its own purposes. Infrastructure providers process the data needed to run the service. Customers can authorize shared reports, exports, API access, and their own assistants.