legal / privacy

Privacy Policy.

How personal data is collected, used, and protected under GDPR. The short version: Kehai is built to know as little as possible. Last updated 2026-09-20. Questions go to privacy@kehai.io.

Data controller

The controller responsible for personal data collected through kehai.io and the Kehai service is:

salecki.digital Mikołaj Salecki
ul. Gen. Jasińskiego 11/51
05-500 Piaseczno, Poland
NIP 1231052003 · EU VAT PL1231052003 · REGON 361948200
privacy@kehai.io

As controller, the operator determines the purposes and means of processing your personal data and is responsible for compliance with the General Data Protection Regulation (EU) 2016/679 ("GDPR") and applicable Polish data protection law.

No Data Protection Officer (DPO) has been appointed. The requirement under GDPR Article 37 depends on the core activities and scale of processing, including regular and systematic monitoring or large-scale processing of sensitive data. The operator documents this assessment and reviews it at least annually and when the scale, purposes or data categories change. Daily visitor codes do not by themselves remove that obligation.

Two roles, and they are not the same one. This policy covers the personal data the operator controls: your account, your billing, your inquiry, and the visitors to kehai.io itself. For that data the operator decides the purposes and the means, and is the controller.

For visitors to your registered sites, the operator is not the controller. You are, and the operator is your processor, acting on your instructions under GDPR Art. 28. That relationship, what is processed, where, for how long, and under which safeguards, is governed by the Data Processing Addendum rather than by this policy. Nothing here gives the operator a controller's discretion over your visitors' data.

The distinction matters when a request arrives. A visitor to your site who wants to exercise a right approaches you, not the operator, and the operator forwards to you anything that reaches it by mistake.

Personal data collected

Kehai processes the information you provide, the request data described below, and data returned by payment or sign-in providers and integrations you authorize. Kehai does not purchase or rent personal data.

Account holders

Account data includes your name, email address, organization where provided, registered sites, preferences, and account configuration. Authentication records include password hashes where used, sessions and their timestamps, linked sign-in provider identifiers and tokens, and any passkey credentials or encrypted authenticator secrets and recovery codes you configure. Access and selected account changes also create security or audit records. Kehai needs the relevant account and authentication data to provide the service.

Contact form

When you submit the contact form, Kehai collects: required: first name, email address, message content; optional: last name, phone number, website URL.

Providing the required fields is not a statutory or contractual requirement, but it is necessary to respond to your inquiry. The only consequence of not providing it is that we can't reply. The contact form sends your message through Resend to our Kehai address. Cloudflare Email Routing forwards incoming mail to the operator's Gmail inbox. Delivery records and the received correspondence have separate retention rules, described in sections 04 and 05.

The newsletter subscription record includes your email address and unsubscribe state. For new or renewed subscriptions confirmed through this form, Resend also holds the latest confirmation time and the version, text and hash of the confirmation notice. These fields help demonstrate the requested subscription; they contain no IP address, browser details or raw confirmation token. Earlier contacts do not receive invented confirmation dates. Submitting the form also involves the anti-abuse processing described in section 07. It is double opt-in: the address is signed into a confirmation link and mailed to you, and until you press Confirm subscription on that page it is on no list. Sending that mail is itself processing: the address and the message pass through Resend, which delivers it and keeps its own delivery log (see §05), and the link carries the address, signed, so that nothing has to be stored to remember the request. Opening the link only shows a confirmation page. Pressing Confirm subscription adds the address to a subscriber list held by Resend. Every issue carries a one-click unsubscribe, and no issue carries a tracking pixel: nothing records whether you opened it.

Providing the address is voluntary. The only consequence of not providing it is that you do not receive the notes. The form is guarded the way the contact form is (see §07).

Billing

Payments run on Stripe-hosted pages at pay.kehai.io. Kehai never sees or stores card numbers. Invoice data (name, address, tax ID) is processed under legal obligation and retained as Polish tax law requires.

Registration campaign attribution

When acquisition context is supplied with your registration, we may keep the registration path, its bounded query parameters, the five UTM campaign fields, and an external referring hostname with the signup and subscription. Before storage, Kehai applies the editable query exclusions of its configured analytics site; without that configuration, it stores no registration attribution. Unblocked click identifiers can therefore be linked to your registration and subscription. This measures signup sources and subsequent subscription revenue. When Checkout is created, the retained context is also sent to Stripe as Checkout and subscription metadata, so the payment integration can return it with supported sales. Stripe can copy subscription metadata into invoice records. Clearing Kehai's local attribution does not automatically erase those provider copies; they are handled separately under the provider relationship and applicable retention arrangements. It does not reconstruct an earlier visit or connect daily visitor or visit codes to your account. The referring page's path and query are excluded. Do Not Track and Global Privacy Control suppress this registration attribution on kehai.io.

This is account-related processing, separate from the daily visitor measurement below. Analytics receives permitted landing context, actual payment time where available, server-confirmed amounts and a random conversion identifier, without customer names, email addresses, payment-provider IDs or shop order numbers. An authorized administrator can export eligible sales for Google Ads campaign measurement, manually as CSV or through a separately configured protected HTTPS feed. This does not create an advertising audience.

Website analytics (Kehai, measuring itself)

kehai.io runs Kehai. It sets no cookie, writes nothing into your browser's storage, does not use a shared visitor code across websites, builds no advertising profile, and feeds no advertising audience.

What it does: your browser sends the address of the page and its permitted query string, the page you arrived from, your browser language, the size of your window and screen, and how long the page was visible. The performance measurements are switched on for this site, so the same script also sends three of them: largest contentful paint, interaction to next paint, and cumulative layout shift. This site also sends a few declared events of its own, each carrying only what it names: when the film is started and as it passes each quarter (the film's name and that percentage), when you open the demo, click Register, or complete a step of sign-up, when a contact message is sent, when a newsletter address is confirmed, and when you vote on a documentation page (the page and the vote). None carries what you typed. The server adds what it can read from the request itself: browser and its major version, operating system and its major version, device type, and the country, region, and city your IP address belongs to, worked out from a file held on the server with no lookup to anybody else. The IP address is used for that and to compute the visitor hash. Raw IP addresses are not written to the analytics database. Intake rate controls hold them in memory for up to three minutes. Human user-agent strings are parsed and discarded, but for requests classified as bots the first 512 characters are stored with the bot event for the site's retention window. A declared bot string can contain identifying information. The full list of every stored field is on the cookie and storage statement.

Query exclusions come from the editable site settings. The installation tag loads one script, the same bytes for every site; it carries no per-site configuration. Intake applies the current server-side exclusions before storage, and the tracker has no additional fixed query-name exclusions, so a list change takes effect on the next event that arrives - nothing to refresh, nothing to re-copy. Older tags with a copied exclusion list keep that list until replaced or updated. Unblocked query values, including campaign click and sharing identifiers, are retained within the 2,048-character URL input and 255-character query key/value limits for the site's retention window. Such values can link records independently of the daily visitor code. Historical rows containing only a 1 marker remain unchanged; Kehai cannot reconstruct the discarded click value.

How one visitor is told from another: nothing is written to your device. Kehai derives a one-way visitor code from the site, your network address, and your browser's user agent together with a random salt that rotates daily at 00:00 UTC. A separate visit code groups activity until 30 minutes of inactivity or midnight UTC, whichever comes first. For new measurements, Kehai does not carry either code or the visit's attribution into the next UTC day. Both codes are stored with event details for the site's retention window. Older rows can contain a visit code shared across more than one UTC day; those rows are not rewritten by this change. Times, paths, retained campaign click values, and customer-supplied properties may also link events independently of these codes.

How to switch it off: block the intake hostname in a content blocker and nothing is sent. Browser opt-out signals, Do Not Track and Global Privacy Control, are honored only on sites whose owner has turned that on in their snippet, so they are not a reliable way to opt out of every site running Kehai. kehai.io has turned it on for itself, so if your browser sends either signal this page does not measure you at all. The site works exactly the same either way.

Server logs

Cloudflare and hosting infrastructure process request metadata for delivery and security. Depending on the service, retained security records can include a network address, time, URL, method, response status, user agent, and referrer. This is separate from the analytics database. Kehai application logs rotate by size, with three log files per service; rotation does not set a maximum age. The operator must review logs against their security and debugging purpose and remove records that are no longer necessary. Provider retention is separate.

Error reports

When something breaks in the account panel or in the collector that receives measurements, the failure is reported to Kehai's own error tracker at err.tymbre.app. That tracker is software the operator runs on the same server in Warsaw as the service (OVH, see §05). The error tracker is operated by Kehai. Hosting and network providers can process the reports as part of running that infrastructure.

A report carries the error and the lines of code it came from, the method and path of the request that failed, the internal id of the person who was signed in, and the text of an error your browser's own console printed. Before a report leaves, the scrubber removes request headers, cookies, request bodies and query strings, limits account information to an internal ID, and redacts recognized address, email and secret patterns in text. Free-form error text and paths can still contain information those rules do not recognize. A report exists to fix the fault, and it is used for nothing else. Legal basis: legitimate interest in finding faults (see §03).

Data not collected

Kehai does not receive full payment card numbers. Billing can include tax identifiers. The analytics service does not ask for government identity documents or special categories of personal data under GDPR Article 9. Its filters cannot guarantee that a customer-supplied URL, event property, product label or declared bot string contains no such information. Customers must not send prohibited personal data. Passkey authentication stores credential metadata and a public key, not biometric measurements from the device.

When a customer enables a commerce integration, Kehai processes the selected provider account reference, connection settings, encrypted provider API keys and webhook signing secrets, and operational delivery records. Responses from Stripe, Wix and Squarespace can include billing and customer information while being processed; retained analytics use the supported commerce amounts, catalog fields and explicitly supplied acquisition context, not provider customer or order identifiers. Operational records keep source references, a financial consistency hash and delivery outcomes so retries and duplicate notifications can be handled. The WordPress plugin and PrestaShop module store their commerce key in the customer's installation; Kehai's public connection list never returns that key.

Legal bases for processing

Every processing activity rests on a valid legal basis under GDPR Article 6:

account & service deliveryPerformance of a contract with you, where the processing is necessary to provide it · Art. 6(1)(b). For account users who are not personally party to that contract: legitimate interest in providing and securing the business customer's account · Art. 6(1)(f)

responding to your inquirySteps taken at your request before entering a contract · Art. 6(1)(b)

follow-up on an active inquiryLegitimate interest: maintaining communication you initiated · Art. 6(1)(f)

newsletterConsent, given by confirming the link we mail you, and withdrawn by the unsubscribe link in any issue · Art. 6(1)(a)

registration campaign attributionLegitimate interest: evaluating the campaigns that bring subscriptions and their revenue, using limited campaign context rather than linking browser histories to an account. You may object to this processing · Art. 6(1)(f)

website analyticsLegitimate interest: knowing which pages are read. The tracker sets no cookie and writes nothing to your device. Device-access consent is a separate question from this GDPR basis and must be assessed for the actual installation under applicable law · Art. 6(1)(f)

network security (Cloudflare)Legitimate interest: protecting availability and integrity · Art. 6(1)(f)

server logs, error reports & debuggingLegitimate interest: debugging, abuse prevention, infrastructure security · Art. 6(1)(f)

legal & accounting obligationsLegal obligation: Polish Accounting Act and tax law · Art. 6(1)(c)

Where processing is based on consent, you may withdraw it at any time without giving a reason; withdrawal does not affect the lawfulness of processing carried out before it. Where legitimate interest is relied on, the operator must assess necessity and balance that interest against your rights and freedoms. This notice does not certify a completed balancing assessment. You may object at any time (see §09).

Data retention

account dataFor the life of the account. When a subscription ends the account stays readable for 30 days. Its sites then become due for erasure, normally performed by the scheduled sweep within a day, subject to the deletion deadlines in the Data Processing Addendum. Account closure removes or anonymizes the account fields covered by the closure process. Some records, including domain claims, audit history, and legally required records, remain. Requests concerning a person's sign-in records are handled individually, and each request is answered

contact form submissionsHeld in the receiving mailbox. Correspondence must be removed when it is no longer needed to resolve the inquiry or establish, exercise, or defend a related claim. Manual review is required; no fixed automatic deletion deadline is promised

newsletter addressUntil you unsubscribe or ask for it to be removed. An unconfirmed request is added to no list: the link expires after 48 hours, and what remains is the confirmation mail in your inbox and Resend's record of having sent it, under Resend's own retention

registration campaign contextUnsuccessful signup context is cleared after 30 days. Subscription context is kept while the subscription is active and cleared 90 days after it ends. Erasure requests are assessed separately. These limits do not extend the retention of website visitor codes or replace the distinct retention rules for invoices and commerce records

acceptance recordsThe version of the Terms and the Privacy Policy accepted at checkout, and the date, for the life of the contract and the limitation period after it

analytics statisticsKept as event rows for the site's retention window, then eligible for deletion by the database's background retention process. Backup copies have their own retention window. Each row stores a daily pseudonymous visitor code and a visit code. Current page measurements also store a view hash scoped to that site and UTC-day visitor, an update sequence, a measurement version, and whether a time interval was unknown. The original random view code is held only in page memory during collection and is not retained by the collector. Salt rotation does not delete the row or its recorded codes; kehai.io's configured window is 3,650 days (10 years)

server access logsThe criterion is whether a record remains necessary to investigate a fault, security incident, or abuse. Application logs rotate by size, not age. No service-wide fixed deletion deadline is configured; manual review and provider-specific retention controls remain necessary

error reportsThe error tracker is configured for a 30-day event retention window, followed by its scheduled cleanup. Backups have a separate expiration process

accounting & legal records5 years from the end of the relevant calendar year (Polish Accounting Act)

After the applicable period, the operator must delete the data or anonymize it where appropriate. Expiry and physical deletion are separate: database background work and the backup retention window can delay removal of every copy.

Customer commerce connection secrets are erased on disconnect. Processed integration inbox entries become eligible for deletion after 30 days. Prepared delivery payloads are cleared after successful delivery and unresolved payloads after 48 hours; scheduled work can delay physical cleanup. Minimal source and delivery identifiers remain for the site's lifetime to prevent duplicate payments from being replayed. These operational records are separate from the site's analytics retention. In the customer's WordPress installation, the optional WooCommerce adapter uses an existing shop session for available acquisition context, attaches it to an order for at most 90 days, and relies on WordPress cron and order privacy/deletion hooks for cleanup. It does not create a session cookie to reconstruct an earlier visit.

A commerce source removed at the provider leaves its analytics and operational records under the ordinary retention above; erasure of a particular order is handled as any other erasure request.

The PrestaShop module uses an existing cart for eligible acquisition context, with a 30-minute inactivity and UTC-midnight boundary. Order context and unresolved delivery payloads clear within 48 hours through cron; local suppression markers clear after 30 days. Wix and Squarespace attribution requires explicit order fields. These integrations do not reconstruct an earlier click from customer identity. Platform data and copies in the customer's shop remain subject to that platform and the customer's retention controls.

Recipients and international transfers

The following providers support the service. Their roles depend on the processing described below: some act on Kehai's behalf, while some also have independent controller purposes. Personal data is never sold or rented. The operator must retain the applicable Article 28 terms and verify transfer safeguards for each processing path. Provider terms alone do not prove that every account-specific step is complete.

OVH Sp. z o.o. (OVHcloud) · Poland, EU

Infrastructure: the Kehai service and this website run on an OVHcloud dedicated server in Warsaw. The application and analytics database are hosted in Poland. This does not describe the separate processing by the edge and email providers below.

Cloudflare, Inc. · USA, global edge

CDN, DNS, reverse proxy, TLS termination, and anti-DDoS on the public hostnames. Data processed: IP address, request URL, headers, user agent, the request body in transit, and security event data when a challenge triggers. Cloudflare may set the strictly necessary cf_clearance cookie only when a security challenge is presented. Cloudflare publishes a Data Processing Addendum with transfer provisions. The operator must verify which safeguards apply to the account and processing.

Resend (Plus Five Five, Inc.) · USA

Email service for transactional messages: the contact-form notification, account invitations, password links, billing notices about your subscription, and the newsletter's confirmation. The operator's own replies, written from hello@kehai.io, leave through the same service, so an outgoing message's content and its delivery record pass through Resend as well. It also holds the newsletter's subscriber list, as an audience, and sends the issues to it. Resend processes customer data, including message content and delivery logs, in the United States. A selected sending region does not relocate that storage. Its Data Processing Addendum incorporates Standard Contractual Clauses where applicable. The sending domain was verified as configured for an EU sending region on September 10, 2026. That setting does not establish account-specific contractual or transfer-assessment completion.

Google Gmail · incoming correspondence

Cloudflare Email Routing forwards mail addressed to hello@kehai.io, privacy@kehai.io, security@kehai.io, and demo@kehai.io to the operator's Gmail inbox. Google processes the sender and recipient details, message content, attachments, and delivery metadata for that mailbox. Google identifies Google Ireland Limited as its consumer-service provider for EEA users. Processing can take place outside the EEA. See Google's Privacy Policy and regional provider information. This correspondence is separate from visitor measurement. Kehai does not forward its analytics event stream to Gmail. The inbox copy remains subject to the correspondence retention criteria in section 04, independently of Resend's delivery records.

Stripe · payments

Stripe processes payments on its own hosted pages. Its DPA distinguishes processing on our behalf from its own controller purposes, including fraud prevention and legal obligations. Kehai receives confirmation of payment and invoice details, never card numbers.

Website analytics · Kehai and its infrastructure

Kehai runs its own analytics software. The software that counts page views is Kehai itself, on the dedicated server named in section 05. 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.

Campaign measurement and external exports

Kehai does not embed Meta Pixel, LinkedIn Insight Tag, a Google Ads conversion tag, or Google Analytics. Supplied campaign click and sharing parameters, such as gclid and fbclid, can remain in analytics unless excluded in the site configuration. Google Ads conversion exports are a separate administrator action: the file contains a GCLID, conversion action name, actual supplied conversion time, net value, currency and a random stable conversion identifier. Creating a protected feed authorizes anyone holding those dedicated credentials to retrieve that file, including Google when configured by the administrator. Revoking the feed stops future retrieval; it does not erase a file already downloaded or data already imported into Google. No advertising audience is uploaded.

Google user data

When an administrator connects Google Analytics, Kehai requests the Google account email and the read-only analytics.readonly scope. Kehai accesses the Analytics properties that account can read, property names and time zones, and aggregate GA4 metrics and dimensions selected for import.

When an administrator connects Search Console, a separate consent asks for the Google account email and the read-only webmasters.readonly scope, and nothing else. Kehai reads the list of properties that account can see and, for the property the administrator picks, the daily rows Google reports: search query, landing page address, country, device, clicks, impressions, and average position, backfilled up to sixteen months and pulled once a day after that. Those rows are stored under the site's retention window with their source label, shown on the Referrers screen, and available through the export, the API, and MCP like every other report. A query or an address that holds a person, an email address or a phone number, is replaced with a placeholder on the way in. Disconnecting stops the pulls and deletes the token; the rows already imported stay until the site's retention or an erase removes them.

Kehai uses this data only to let the administrator choose a property and to display the imported history and search terms in Kehai reports. It does not modify Google Analytics, use Google user data for advertising or credit decisions, sell it, send it to data brokers, or use it to train general-purpose AI or machine learning models.

The Google refresh token is encrypted with AES-256-GCM before storage. Access tokens are short-lived and are not stored. Imported aggregate report data is stored with its source label. Google user data is handled according to the Google API Services User Data Policy, including its Limited Use requirements.

Anti-spam protection

Two things guard the contact form and the newsletter form. Cloudflare Turnstile presents a challenge that decides whether a browser is a person, and it runs only on those two forms: on the landing page it loads once you reach for the newsletter field, not with the page. It may set the strictly necessary cf_clearance cookie described in section 05. Under its Turnstile Privacy Addendum, Cloudflare processes challenge data to protect the website and also acts as an independent controller when it uses that data to improve bot detection. This processing is separate from Kehai's analytics and is described in Cloudflare's published privacy terms.

Kehai applies a shared limit of five submissions an hour across the two forms, counted separately for each email address and network source. The in-memory counters use keyed hashes made with a random secret created when the server starts. They do not retain the plain email or network address. Only submissions from the preceding hour count toward the limit. Expired entries are removed during later requests, and a server restart clears the counters. These counters are not written to disk, logged, or shared. Delivered messages and newsletter subscriptions have the separate retention periods described above.

Legal basis: legitimate interest (Art. 6(1)(f)) in preventing spam, service disruption, and abuse of the forms. The rate controls use short-lived counters without profiling. The operator must assess necessity and balance this interest against your rights. You can object under Art. 21 at privacy@kehai.io.

Cookies and storage

Kehai measurement sets no analytics cookie and writes no visitor identifier to browser storage. Those technical properties do not by themselves establish an exemption from device-access consent. The applicable assessment must cover the actual collection and local law, as explained in the cookie and storage statement.

Signing in to the account panel does require cookies, and a few preferences are kept in the browser. Every one of them is named, with what it is for, in the cookie and storage statement. That page is the complete list, kept in one place so it cannot drift from a shorter copy here.

Security

Appropriate technical and organizational measures protect personal data against unauthorized access, accidental loss, alteration, and disclosure, as GDPR art. 32 requires.

What those measures are, how the service is run, and what is deliberately not in place are set out on the security page. It is written to be read by somebody assessing the risk rather than by somebody being reassured.

Your rights under GDPR

Access (Art. 15): request a copy of personal data held about you and how it is processed
Rectification (Art. 16): request correction of inaccurate or incomplete data
Erasure (Art. 17): request deletion when data is no longer necessary, when you withdraw consent, or when processing is unlawful
Restriction (Art. 18): request a pause in processing while you contest accuracy or object
Portability (Art. 20): receive your data in a structured, machine-readable format
Objection (Art. 21): object to legitimate-interest processing; it stops unless compelling grounds override
Withdraw consent (Art. 7(3)): any time, without affecting prior processing
No automated decisions (Art. 22): see §13 for how the analytics is used

For site visitors, the operator checks whether relevant rows can be found using the information available. A day's visitor code can be recomputed from the same network address and browser only while that day's salt is available. Once that day's salt has been discarded, that lookup is no longer available, but event rows remain for the site's retention window and other information may make them identifiable. We explain what can be found and any limits on handling the request.

How to exercise your rights

Email privacy@kehai.io with the subject line "GDPR request: [specify right]", or write to ul. Gen. Jasińskiego 11/51, 05-500 Piaseczno, Poland.

A response is provided without undue delay and within one month of receiving the request. Where its complexity or the number of requests requires an extension of up to two further months, the operator explains the extension within the first month (Art. 12(3)). Identity verification may be requested, typically by confirming the email address associated with your data. No fee is charged unless requests are manifestly unfounded, repetitive, or excessive (Art. 12(5)).

Right to lodge a complaint

If you believe your data is processed in violation of GDPR, you may complain to the Polish supervisory authority: Urząd Ochrony Danych Osobowych (UODO), ul. Stanisława Moniuszki 1A, 00-014 Warsaw, Poland · uodo.gov.pl · kancelaria@uodo.gov.pl.

You may also complain to the authority of the EU member state where you reside, work, or where the alleged infringement occurred. We encourage you to make contact first; concerns are taken seriously and resolved promptly.

Automated decision-making and profiling

Kehai does not use analytics reports to make decisions about a person that have legal or similarly significant effects solely by automated means. Traffic forecasts model aggregate history; they do not score a person's eligibility for services.

Profiling under GDPR Article 4(4) is a separate concept from Article 22 decisions. Kehai does not build cross-site advertising profiles or conduct behavior-based targeting. A customer's use of journey, geography or commerce reports must be assessed against its purposes and instructions, including whether it involves profiling. For new measurements, visitor and visit codes start fresh each UTC day. Retained page paths, times, campaign click values, or customer-supplied properties can still link events.

Minors

Kehai targets business professionals and is not directed at individuals under 16. Data from minors is not knowingly collected; if such collection is discovered, the data will be deleted promptly. Notify privacy@kehai.io if you believe this has occurred.

Updates to this policy

This policy may be updated to reflect changes in data practices, applicable law, or services used. The date at the top shows the last revision. Material changes will be communicated to account holders before taking effect.

For your obligations and limitations when using kehai.io, see the Terms of Use. For the processor relationship covering your visitors' data, see the Data Processing Addendum.