Privacy

Two kinds of data, and who decides about each

TeklTalk holds two quite different things, and it matters which one is being discussed.

• Your account. Your email address, your plan, your billing records. We decide what happens to this, so for this data we are the ones answerable to you.
• Your visitors’ data. The conversations people have with your widget and the form submissions they send you. We hold this for you, on your instructions. You decide what your widget asks for and how long it is kept; we only run the service.

That second point has a consequence worth stating plainly: if you embed TeklTalk on your site, your visitors are your visitors. Your own privacy notice needs to tell them that a chat widget is present, that their messages are processed to answer them, and — if you use the lead form — what you collect through it. We cannot make that disclosure on your behalf, because it sits on your domain.

What we store about your account

• Your email address, and either a hashed password or, if you signed in with Google, the account identifier Google returns. We never store a password in a form we can read.
• Your plan and usage counters — how much content you have indexed and how many conversations you have used in the current period, which is what the limits are enforced against.
• Billing records — the amount, currency, status and the payment provider’s reference for each charge. Card details are entered on that provider and never reach our servers, so we could not store them if we wanted to. If you installed TeklTalk from an e-commerce platform’s app store, the platform bills you on your own invoice and we hold only its record of which plan you are on.
• Login sessions — one row per active sign-in, holding only a hash of the session token, its expiry, and the account it belongs to.

The content you ask us to index

We fetch the pages you point us at — from a sitemap, a URL list, pasted text or an uploaded document — split them into chunks, and store those chunks alongside their embeddings so answers can be retrieved and cited. We do not crawl anything you have not asked us to.

If the pages you index contain personal information, it becomes part of what your widget can quote back to a visitor. That is your decision to make, not something we can detect for you, so index accordingly.

Conversations

Messages are stored per visitor thread so the widget can hold context within a conversation, and so you can see what people are asking. We do not ask visitors who they are, and the widget sets no advertising or cross-site tracking identifier.

We keep the text of a conversation for 7 days, then delete it. A scheduled job runs every night and erases the wording of every message older than that — what the visitor typed and what the assistant replied. It cannot be recovered afterwards, by you or by us.

What remains after those 7 days is the measurement, not the content: when the exchange happened, whether the bot answered, why it declined if it didn’t, how closely your content matched, how long it took, how many tokens it cost, and which of your own pages were cited. That is what keeps your analytics working over a longer period than the transcripts themselves.

Each thread carries a random identifier that the widget generates fresh on every page load. It is not written to the visitor’s device, does not survive a reload, and is linked to no identity — it exists only to group the messages of one sitting.

Conversation text is used to run the service and to show you your own analytics. We do not use it to train models, and it is never shared between accounts.

Form submissions and leads

If you use the lead form, what your visitor sends is stored so you can read and act on it: their email address and message, their name if your form asks for one, and any other fields your form includes — a phone number, a subject, whatever you have chosen to collect. We also record the IP address the submission came from and the page it was sent from, which is how a form of this kind is triaged for spam and how you can confirm a lead genuinely came from your own site.

Leads have no automatic expiry. Unlike conversation text, they are kept until you delete them or delete the project they belong to. They are yours to hold and yours to clear out, and if your visitors are in a jurisdiction that gives them deletion rights, acting on those requests is your responsibility as the site owner. Write to us if you would rather we removed something directly.

Our own contact form runs on this same mechanism — deliberately, so it breaks before a customer’s does. When you contact us through it, your name, email, reason for writing and message are stored in our database exactly as described above, rather than being emailed to an inbox.

Cookies and local storage

This site sets three kinds of cookie. The first is a session token, set only once you log in, that keeps you signed in: it is HttpOnly, so no script can read it, and it expires after 30 days or when you log out. The second is a product-analytics identifier, described in the next section, which lets us count a returning visitor as the same person rather than as a new one.

The third set belongs to Google. Google Analytics writes _ga and _ga_* to measure traffic, and our Google Ads tag writes _gcl_au. That last one is an advertising cookie, and we would rather say so plainly than bury it: it exists so we can tell which advertisement led to a signup, and so we can build remarketing audiences. If you would rather not carry it, any standard content blocker or tracking-protection setting stops it, and nothing in the product breaks when it is missing.

None of these are set on your visitors. Every one of them is confined to this site: none is written by the chat widget or by the embedded store admin, so putting TeklTalk on your site puts no cookie of ours — or of Google’s — on the people who visit it. We do not sell access to any of it.

The widget sets no cookies at all. It writes exactly one value into local storage on the site it is embedded in: a flag remembering that the visitor has dismissed the greeting bubble, so it is not shown again. It holds no identifier, is readable only by that one site, and is not sent to us.

Analytics

We measure how the pages of this site are used, so we can tell which parts of the product work and which quietly do not. Four tools do this, and they are deliberately different in what they keep.

The first counts visits in aggregate — page, referrer, rough country — and stores no identifier at all. The second is a product analytics service that records named events: an account created, a knowledge source added, a settings page saved, an error thrown in your browser. Once you are signed in, those events are linked to your account, and your email address, plan and role are stored alongside them so we can tell one account’s experience from another’s. It sets a cookie for this. We do not use this identifier to build a profile of you for advertising, and we do not share or sell it.

The third and fourth are Google’s, and they are a different kind of thing. Google Analytics measures traffic to our marketing and dashboard pages. The Google Ads tag is advertising rather than measurement: it is what lets us attribute a signup to the advertisement that produced it and include visitors in remarketing audiences. Google receives that data as a processor for us and also uses it for its own purposes under its own terms, which is the honest description and the reason it is named in the list below.

The same service records sessions on this site: a reconstruction of what a page looked like as it was used, so we can see where a flow goes wrong instead of guessing. Every form field is masked before the recording leaves your browser — passwords, API keys and payment details are never captured, in any form.

None of this runs inside the chat widget. All four are excluded from it in code, and the exclusion is enforced independently in each of them, so embedding TeklTalk on your site loads no measurement of ours onto your pages, sets no identifier on your visitors, and records nothing they type into the chat. The same exclusion covers the app screens shown inside a connected store’s admin.

If you would rather not be measured at all, a browser “Do Not Track” or tracking-protection setting will block it, and so will any standard content blocker. Nothing in the product stops working when you do.

Operational logs

Every API request produces one structured line recording what happened — which route, what status, how long it took, and the error if something failed. These are what we debug and monitor from, and they are kept for a limited period by our logging provider. They do not contain the text of conversations. A small number of them record an IP address, where that is the thing being investigated, such as a submission caught as spam.

Who else processes this data

We use a small number of providers, each for one job. Nobody on this list gets your data for their own purposes.

• Hosting, storage and database. The application runs on Vercel, which also stores the files you upload and the bot icons you choose; content, conversations and account records are stored in a managed PostgreSQL database (Neon).
• Page counts. Vercel’s analytics counts visits to our own marketing and dashboard pages. It sets no cookies, and it does not run on the chat widget, so it never measures your visitors.
• Product analytics. PostHog records the named events and session recordings described above, on servers in the United States. It covers our own site only — it does not run on the chat widget, so it never measures your visitors either.
• Measurement and advertising. Google Analytics measures traffic to our own pages, and Google Ads attributes signups to advertisements and builds remarketing audiences. Both set the cookies described above, both are confined to this site, and neither runs on the chat widget or in a connected store’s admin.
• Sign-in with Google. Handled through Google’s authentication service, and only if you choose that option. Signing in with a password does not involve it.
• The AI model provider. Answering a question sends the retrieved chunks from your own content and the visitor’s message to the model that serves your project. We currently use Google (Gemini) and Groq, and which one serves a given request may change as we tune quality and speed. Nothing is sent to a model provider unless a question was actually asked, and no provider is given your content to train on.
• Payments. For accounts that sign up here, Paddle is the merchant of record: it processes the payment, issues the invoice, handles sales tax and VAT, and holds the card details we never see. For an installation from an e-commerce platform’s app store, that platform bills you instead, on the same invoice as the rest of your subscription with them, and Paddle is not involved at all.
• Connected stores. Where you have connected a store, we read your catalog and content from that platform’s API and ask it which plan you are on. See the section below for what that covers and, more to the point, what it does not.
• Logging. Operational logs are shipped to Grafana Cloud, as described above.

Our hosting and logging providers run infrastructure in several countries, so your data is processed in the other countries where they operate. Using the service involves that transfer.

Connected stores

You can install TeklTalk directly from an e-commerce platform’s app store rather than signing up here. Doing so creates the account for you, so a few things work differently and it is worth being specific about which.

What we read from the store. Only what the assistant needs in order to answer: your products and their descriptions, your content pages, your published policies, and — solely to tell you whether the chat widget is switched on — whether our block is enabled in your published theme. All of it is read-only. We never write to your store, and we never edit your theme.

What we deliberately do not read. We do not request access to your orders or to your customer records, and we therefore hold none of them. That is a permission we have not asked for rather than one we ask for and use sparingly, which is a distinction you can check on the install screen: if it is not listed there, we cannot read it. One consequence is worth stating, because it sounds like an evasion and is not: when a shopper asks your store to delete their data and the platform passes that request to us, there is usually nothing of theirs for us to find, because we were never given it.

What we store. Your store’s domain, the plan you are on, the shop profile the platform returns when we connect (name, primary domain, contact email, currency and timezone), and an access token. The token is encrypted before it is written down and is never logged.

The account created for you. Installing creates an account you did not fill a form for, with a placeholder email address that cannot receive mail — that is deliberate, so nobody can request a password reset for a store they do not own. Everything else on this page applies to it exactly as it does to an account created here.

Where we email you. Because that placeholder cannot receive mail, the app asks you for an address to send notifications to — when your assistant could not answer a shopper, and a weekly summary. It is pre-filled with the contact address your store already publishes, and we store it only once you confirm it. If you enter a different one, we send that address a link and store nothing until it is clicked. This address is only ever a delivery address: it is never a way to sign in, it cannot be used to reset a password, and you can change or remove it from the app at any time.

Uninstalling. When you remove the app, the platform tells us, and we erase the access token immediately and cancel the subscription so you are not billed again. Your indexed content and conversations are erased when the platform sends the shop-deletion request that follows, or sooner if you ask us. Conversation text is on the same 7-day clock regardless.

Your shoppers are still yours. The chat runs on your storefront, so the point made at the top of this page applies unchanged: your own store privacy notice needs to tell your shoppers that a chat widget is present and that their messages are processed in order to answer them. We cannot make that disclosure for you.

Separation between customers

Every retrieval query is scoped to a single project at the database level, and project ownership is re-checked on each request rather than trusted from the client. Your content is never used to answer another customer’s visitors, and it is not used to train models.

Security

Passwords are hashed with bcrypt and never stored in readable form. Session tokens are stored only as hashes, so a stolen copy of the database could not be replayed as a valid login. Everything travels over HTTPS. Card details are handled entirely by Paddle.

No system is beyond reach, and we will not pretend otherwise. If you find a security problem, write to support@tekltalk.com and we will treat it as a priority.

How long we keep things

• Conversation text — 7 days, then erased automatically.
• Conversation measurements and citations — for as long as the project exists, so your analytics stay meaningful.
• Leads — until you delete them or the project.
• Indexed pages, chunks and embeddings — until you delete the source or the project.
• Login sessions — 30 days, or until you log out.
• Account details — while the account exists.
• Billing records — kept after an account closes, for as long as tax and accounting law requires us to be able to show what was charged.
• A connected store’s access token — erased the moment the app is uninstalled, not on a schedule.

Deleting things

Conversation text deletes itself after 7 days, which needs nothing from you. Deleting a project deletes everything else it holds: its pages, chunks, embeddings, conversations and leads.

There is no button yet for deleting an entire account, so that one is done by hand: email support@tekltalk.com from the address on the account and we will erase it, along with everything in it, keeping only the billing records the law requires us to hold. The same goes for a specific thread, page or lead you want removed ahead of its schedule.

If you installed from an e-commerce platform’s app store, you do not need to email us at all: uninstalling makes the platform send us the deletion request on your behalf, and we act on it. Requests that reach us that way are answered within 30 days, the same deadline as any other on this page.

Your rights

You can ask us for a copy of what we hold about you, to correct it, or to delete it. You can withdraw consent and close your account at any time. If you are unhappy with how we have handled a request, you are entitled to complain to the data protection authority in your country.

Write to support@tekltalk.com from the email address on the account. We will act on the request as quickly as we can, and within 30 days at the latest.

If you are a visitor to a site that uses TeklTalk rather than a customer of ours, the site owner decides what happens to your data — contact them first. Write to us if you cannot reach them, and we will pass the request on to the account holder.

Children

TeklTalk is not directed at children. We do not knowingly collect personal information from anyone under 18, and we will delete it if we learn that we have.

Changes to this policy

When this policy changes, the date at the top of the page changes with it. If a change materially affects what we do with your data, we will email the address on your account rather than leaving you to notice.

Contact

TeklTalk is responsible for the data described on this page. For anything here — including a request to see or delete your data — write to support@tekltalk.com, or use the contact form. Our terms explain the rest of the arrangement.