ASKLAINFOC ONE CHAT
Admin Talk to us

Privacy

How ASKLA handles data

What ASKLA stores, for how long, and which services receive what. This page describes how the software works; your organisation's own privacy notice still governs your site.

What ASKLA stores

  • Questions and answers, after redaction, so your team can read the conversation and see what visitors asked.
  • Live chat messages: the visitor's after the same redaction, and your team's replies as they were written.
  • A rating of a chat with your team, when the visitor gives one, with its optional comment after redaction.
  • Contact form details, including the submitted name and email, when a visitor agrees to the form's consent statement. The exact consent sentence and the time are kept with the request.
  • A visit: the device type, the browser, where the visitor came from (such as a search engine or a link) and the page they landed on.
  • A returning visitor: the server stores a SHA-256 hash of the browser's random token, with visit and conversation records. This is browser-based continuity, not identity verification.
  • Analytics events: what happened (opened, answered, asked for a person), with allowlisted page paths, topic identifiers, counts and states. Message text is not an analytics property; conversation text is stored separately.
  • Optional live assistance, when the site enables it and the visitor permits it: a separate temporary visit identifier, approved page paths, source category, visibility and last-seen time. This lets an operator offer help. Sensitive paths and URL query strings are excluded. It does not record cursor movement, keystrokes, form contents or screen recordings.

What is removed first

When optional assistance and owner interest alerts are enabled, ASKLA ranks consented browsing using rules for pricing/contact pages, page variety, session span, returning browser identity and requests for a person. The score is an approximate interest signal, not identity verification or a prediction of a purchase. Owner email/webhook alerts contain the score and its reasons, without chat text or visitor contact details. On this site, use "Visitor assistance preferences" in the footer to allow or withdraw this separate purpose. Declining still allows chat.

ASKLA replaces detected email, phone, Singapore NRIC/FIN, payment-card and IBAN patterns in visitor questions and messages before passing them to the AI or saving the processed message. Detection is based on patterns and can miss information. Names, addresses and other sensitive details are not reliably detected. Visitors should avoid sharing personal details in chat. Typing a detected email or phone in the widget opens a prefilled contact form. It is shared with the team only after the visitor confirms consent. Email or phone can be provided; the AI does not receive those contact fields. Confirmed contact details remain visible to the visitor and authorized team. Contact forms retain the details submitted with consent; operator replies are not automatically redacted.

How long it is kept

  • Chat cleanup defaults to 30 days and is configurable by the operator. When the cleanup job is enabled, it runs at startup and approximately every six hours. Questions, answers, messages, ratings and analytics events become eligible by their age; inactive visits and conversations by their last activity. Deletion is not an exact 30-day deadline.
  • Server-side returning-visitor records become eligible for cleanup after the configured inactivity period, 180 days by default. Remembered browser records also have a renewable 180-day expiry. Conversation retention is separate.
  • Contact requests and content tasks: not part of this clean-up, because they are your team's follow-ups.
  • Optional assistance can include referral host and sanitized campaign labels. With the separate tracking permission and site enablement, trusted edge headers can supply approximate country and a public network address. Addresses are encrypted, masked by default, revealable by owners with an access record, and expire after at most seven days. Addresses and locations can belong to VPNs or proxies, not an identified person. No per-visitor third-party geolocation request is made. Arrival alerts contain no contact details, IP address or transcript. Optional assistance journeys: eligible for cleanup after the site's configured period, 30 days by default. Withdrawing tracking permission removes the journey and pending invitations; a revoked credential is retained briefly to prevent it being reused. Operator delivery events have a seven-day cleanup threshold. These cleanup routines must be enabled and running.

What a visitor's browser keeps

Depending on storage settings and consent, the browser keeps a visitor record containing the random token, current conversation identifier and expiry. It may also keep interface state, visit identifiers, sound preferences and suggestion-dismissal choices. Message text is not persisted in localStorage or sessionStorage; retained conversation text is fetched from the server into the page. A visitor can use "Clear this chat from this device" to clear that device's link. This does not delete the server transcript. When connected to ASKLA's consent API, your banner can disable remembered visitor records; the consent preference itself is remembered where browser storage is available.

Which services receive what

  • The AI provider, when AI answering is enabled, Anthropic's Claude unless the operator configures another provider, receives the redacted question, a few recent answers from the same conversation, and the passages from your pages. Approved-answer mode makes no model calls. Keyword search uses no embedding API. With Claude it uses your site's own Anthropic key, or the server's key if the operator allows that.
  • The embedding provider, when enabled by the operator, receives your pages' text when they are indexed, and the redacted question when ASKLA searches them. In keyword-only mode, search runs in PostgreSQL without an embedding provider.
  • Your email and webhooks, if you set them up, receive contact requests (name, email, consent and the questions attached) and content tasks. Live-chat webhooks carry no message text.
  • Google Fonts serves the widget's font to the visitor's browser, unless your site turns that off with data-fonts="false". ASKLA's product pages separately load their own fonts from Google Fonts.
  • Apple Push Notification service, when your operator uses the optional iOS app, receives a device token, a generic alert and opaque routing identifiers. It receives no transcript, email address or page URL in the notification payload. Conversation details are fetched from your ASKLA server after authentication.

The visitor widget uses browser storage rather than cookies. Optional assistance is off until the site enables it and the visitor's tracking choice permits it. Refusing this tracking still allows the visitor to start a chat. Native mobile sign-in and Microsoft sign-in use short-lived browser security cookies during their authorization flows. The optional native client stores its refresh credential and unsent reply drafts in device secure storage; the mobile web admin keeps its session in tab storage and reply drafts in memory. Native app signing, distribution and physical-device acceptance are separate from the web admin.

Where it runs

ASKLA's core application records are stored in PostgreSQL. Browser storage, model providers, optional delivery services, server logs and backups are separate locations. Self-hosted operators choose their infrastructure and retention settings; a database region does not determine where every provider processes data.

Questions about your data? Email the INFOC team.