Documentation
Coming from another tool
Reading the reports
Count what matters
Machine access
The answers your counsel will ask for.
Controller and processor, assessing consent, stored data and its limits, visitor requests, and your responsibility for the data you send.
Who is who, on paper
For your visitors' data, you are the controller and Kehai is the processor. The Data Processing Addendum is the article 28 contract, Sub-processors names every company that can reach personal data while the service runs, and Security says how it is run, including a section on what is deliberately not in place. When a visitor's request lands on your desk, Kehai assists with locating available records and answering the request under the DPA.
Assessing consent for your installation
Kehai sets no analytics cookie and writes no visitor identifier to browser storage. Its script reads page and device information, and the collector stores pseudonymous event rows. Device-access rules can apply without cookies. An exemption depends on the actual configuration and applicable law, so absence of cookies does not establish one. Use the cookie and storage statement to assess your installation with your counsel, including any consent mechanism your site needs.
What is held, and what never is
| Data | Treatment |
|---|---|
| network addresses | Used for geolocation and the daily code. Raw IP addresses stay in rate-limit memory for up to three minutes and are not written to the analytics database. Infrastructure processes them separately |
| raw browser strings | Parsed into browser, system, and device fields for human events, without storing the raw string. For requests classified as bots, up to 512 characters of the declared user agent are stored with the bot event for the site's retention window |
| a durable visitor identity | A salted visitor code scoped to one site and one UTC day. Visits end at midnight UTC; the event rows remain for the site's retention window |
| page titles | Never collected at all |
| click and sharing parameters, such as gclid or fbclid | Supplied values are retained unless blocked by the query-name filters, within the existing 255-character query key/value and 2,048-character URL input limits. They can link records to a click even after daily codes rotate |
| order, customer, and transaction identifiers | Refused as analytics fields at the commerce endpoint. Managed integrations retain minimal provider source references separately in their operational delivery ledger to prevent duplicates |
Older rows recorded with a 1 marker remain unchanged; Kehai cannot recover the discarded click value. New original values require an updated tracker and collector. Retaining them does not upload conversions to Google Ads or link a purchase to a browser visit automatically.
Optional commerce integrations also need connection settings and delivery records. Hosted provider credentials are encrypted and erased on disconnect; processed inbox entries expire after 30 days, prepared payloads on success or after 48 hours unresolved, and the minimal duplicate-prevention ledger remains for the site's lifetime. The customer-installed WooCommerce and PrestaShop modules store their keys server-side and may use an existing shop session or cart for acquisition context, without creating a new analytics cookie. Include that use in your installation assessment.
The tracker and storage inventory is the cookie and storage statement, written to be read rather than skimmed.
When a visitor asks what you hold on them
A daily code may be recomputed while its day's salt is available and the same inputs are known. Once that day's salt has been discarded, Kehai cannot use those inputs to look up the old code. Event rows still exist for the site's retention window, and information the customer holds, including times, page paths, retained click values, or declared properties, may make relevant rows identifiable. The operator checks what can be found and assists with the request rather than treating the loss of the salt as proof that no data is held.
Your half of the bargain
Kehai checks declared event names and properties for recognized identifier shapes. URL paths and unblocked query values do not receive that same value check. What only you can prevent:
- Identifiers in your URLs. A path or query carrying an email or a customer number goes into the data because your site put it there. Keep identifiers out of paths at the source. Add sensitive query parameter names under Settings, Site, Blocked query parameters. Changes apply to the next event that arrives, without repasting anything; intake applies the current site list to every incoming event.
- People in event properties. Send categories, never people: plans, variants, positions. The checks and their limits.
- Per-customer coupon codes. The commerce endpoint takes a campaign code at its word. A single-use per-person code is an identifier you chose to send.
When something got in that should not have: a rule excludes it from reports at once and retroactively, the Danger screen erases everything a site measured, and for anything narrower, one day or one path, write to the operator and it is handled through the audited path rather than by hand.
Where it all runs
Analytics is hosted in Warsaw, Poland, inside the EU. The backup tooling excludes visitor salts. The backups can still contain event rows and their recorded codes until the backup retention period ends. Cloudflare answers public requests at its edge and can read them, as described on Security with the backup mechanisms and their operational limits.