Privacy policy
This translation is provided for reference; the Russian version prevails.
This document is written from the database schema and the service code, not from a template. It makes one central claim: there is no personal data in any of our tables — not because we promised not to store it, but because no columns exist for it.
1. Scope of this document
KLASTER is a funnel analytics widget for amoCRM (version 1.1.8) and the website klastercrm.com with an account area. This document describes three data flows: what goes from your amoCRM into our database, what you leave on the website yourself, and what the providers without which the service cannot operate receive.
Your CRM data is processed on your instructions and in your interests: you define the scope through the field whitelist, and access is granted and revoked by the account administrator. We do not combine data of different clients, do not build industry samples from it and do not transfer it to third parties other than those listed in section six.
2. What we take from amoCRM
- Pipelines and stages: names, order, archived-pipeline flag
- Account users: identifier, group, administrator flag — without the name
- Deals: identifier, pipeline, stage, responsible user, amount, dates of creation, modification and closing
- Status change history: from which stage, to which stage, at what second and who moved it
- Values of analytical fields — only those the administrator has added to the whitelist
Today the list ends there. Tasks and their deadlines, Calls, their duration and outcome, Chat and email correspondence are not part of synchronisation: the schema has room for them, but there is no code that fetches them and no reports on them in the widget. If they appear, they will appear in the list above.
You define the field whitelist. By default none of the custom fields are synchronised: the administrator marks breakdown fields by name, and only list values are taken, never free text. A field that could contain a name, phone number or email address is not added to the list. On the developer’s pilot account the list looks like this (field names as they appear in the account): Причина отказа, Название проекта, Источник, Цель приобретения, Бюджет сделки, Страна запроса, Тип апартамента, Отделка — attributes of the property and the enquiry, not a single contact field.
The scope has been checked against the database schema (tables fact_lead, fact_transition, fact_task, dim_*) and the amoCRM client, widget version 1.1.8.
3. What we never take
- Customer names, company names and job titles
- Phone numbers, email addresses, messengers
- Texts of notes, correspondence and comments
- Attachments, files and deal documents
- Call recordings and their transcripts
- Names and contact details of account employees
There is nowhere to write this, so there is nothing to delete. This is verified not by trust but by the list of columns: the schema has no fields for full names, phone numbers, email addresses or free text.
Employee names in a report are filled in by the reader’s browser. When a manager opens the list of deals behind a figure, the names and titles are requested by their own browser directly from amoCRM, under their own session and their own permissions. They are not sent to our server and do not end up in logs.
4. Access permissions: read only
Every call to amoCRM is a read. Not a single call in the synchronisation code creates, changes or deletes anything in your CRM; the only write-method request in the entire project is the exchange of the authorisation code for a token on amoCRM’s service endpoint. On connection a single permission is requested — “Account data”. The other permissions in the access grant dialog are not requested: File access, File deletion, Notification centre, Amma.
amoCRM has no separate “read only” permission, and we do not promise one: the restriction lies on our side, not in a checkbox at installation. Exactly what we see and what we do not see is described in detail on the Data and access page.
Permissions checked against the amoCRM developer documentation on 21.08.2026: there is no separate “read only” permission in the list.
5. What you leave on the website yourself
CRM data is covered above. Separately — the little that a person enters themselves; we name it rather than hiding it behind an “other data” clause.
- Enquiry from the website. The contact detail you entered in the form, your amoCRM subdomain if you provided it, the plan and currency you were viewing, and your comment. We ask neither for a name nor a company: the contact detail is all that is needed to reply.
- The form sender’s address. Recorded solely to detect flooding of the form from a single address. Purged on schedule with the same retention period as everything else: 90 days.
- Signing in to the account area. The email address whose ownership is verified by the sign-in provider, and the provider’s stable identifier. We neither see nor request your amoCRM password.
- Saved reports. The slice name and its settings: pipeline, period, manager, group, tab. The author is marked by the amoCRM user identifier, without a name.
- Licence key verification log. Account, key, time, address and verification result. Needed to see when one key is used in several accounts.
6. Where the data is stored
Managed Postgres on AWS, region eu-central-1 (Frankfurt). Accounts are isolated at row level: every row carries an account identifier, and a query without one is not executed. The account context is set from the verified signature of the amoCRM request, not from the request body or URL — an account identifier sent by the client is never accepted.
Access tokens for your amoCRM are kept in secure storage and refreshed automatically. Keys and tokens never appear in links: a report URL you share grants no access to the data.
7. Who else touches the data
| Provider | Purpose | What it receives |
|---|---|---|
| Neon | Managed Postgres, AWS eu-central-1 | Anonymised transitions, aggregates, pipeline and stage reference data |
| Vercel | Hosting of the website, the reports API and the widget page | Request traffic. It carries no request bodies containing personal data |
| Account sign-in provider | Verifying ownership of the email address on sign-in | The account owner’s email address. Receives no CRM data |
| AI model provider | The “AI review” tab, only when the user clicks | Numeric aggregates of the slice. Managers appear under masks M1…Mn |
The list is exhaustive. The widget has no advertising or analytics trackers that would receive your CRM data. If a new provider appears, it will appear in this table too.
8. AI review: names never leave the browser
The aggregates for the review are assembled in the user’s browser. There, manager names are replaced with masks M1…Mn, and there they are restored in the finished answer. Of the CRM data, only numbers go to the model provider: stage entries, conversions, time medians, field completeness, stage and field names. Neither the model nor our server sees names from your CRM.
Your own question is a separate matter. If you type a question in your own words, it is sent to the model verbatim, together with the aggregates. This is the only place in the entire service where human-written text reaches the model provider, and we cannot anonymise it: it is your text, not a CRM field. Do not include names, phone numbers or email addresses in the question — they are not needed for an answer. The same notice is shown in the widget itself, above the question field.
The call is made when the user clicks, not in the background. The request size is limited so that the tab cannot be turned into a channel of arbitrary volume, and the rate is limited so that it cannot be used as someone else’s gateway to the model. Without a connected model the tab keeps working: the insights are computed by code; the model only explains them.
The procedure can be verified in the code: aggregate assembly and masking — web/lib/ai-aggregate.ts; sending — web/app/api/v1/ai/route.ts.
9. How long the data is kept and how to delete it
- Revoking access. The administrator revokes access in amoCRM, in the “Granted access” section, with a single button and without our consent. Synchronisation stops immediately: no new data comes in.
- Data accumulated before disconnection. We keep it for 90 days, then delete it. The period was not chosen for convenience: clients come back, and losing the history over a week of downtime is worse than waiting. Need it deleted sooner — write to us and we delete it on your email.
- End of the paid period is not disconnection. Reports close 3 days after the period ends (the grace period), while synchronisation keeps accumulating history: when you come back, the data is there.
- Deletion on request. An email to hello@klastercrm.com from the subdomain or from the account administrator. We delete the account’s rows in full, including saved reports and the licence key verification log, and confirm the deletion by email.
- Export. Reports can be exported from the widget to Excel at any time. An export of the raw transitions for the account is made on request, by the same email.
10. What this document does not claim
- We hold no information security certificates, have not undergone an audit and do not claim “compliance”.
- There is no separate data processing agreement as a standalone document. We are preparing one for the first corporate client; on request we discuss it right away.
- The operator’s legal details are not given here until the legal entity is registered. Invented details — even as an example — will not appear here either.
- The list of what we cannot do yet is kept in the open: what we cannot do yet.
11. How to contact us
Questions about data processing, deletion requests, export requests, security questionnaires — by email to hello@klastercrm.com. We reply in writing, point by point; if the answer is “we do not have this”, that is what we will write. Telegram and WhatsApp for urgent matters are on the Support page.