We’ll connect analytics to your amoCRM in 5 steps
The account administrator grants access with one button in amoCRM and revokes it in the same place — revoking needs nothing from us. Then the history loads: 34 minutes on 7 years of history on the pilot, measured, not estimated. The administrator’s password never reaches us.
version 1.1.8 · amoCRM technical account since 26.08.2026 · the public build passed the validator; amoCRM does not publish review timelines
How the installation goes
Granting access via OAuth
System. We receive a token pair, register the account and refresh access ourselves from then on. The administrator’s password is never entered anywhere and never reaches us: amoCRM asks for it on its own side.
You. The administrator opens the installation link and clicks “Allow”. We issue the link on request: until the widget is in the marketplace, there is no public install button.
Result: the account is connected, and access renews from then on without you.
Initial history load
System. We fetch the reference data — pipelines, stages, users, fields — then deals and status history in date windows. Transitions are built from the history: from where, to where, when, who moved it, how long the deal sat on the previous stage.
You. Wait. The screen shows a percentage, not a spinner. If the process is interrupted, it resumes from the same point, not from the start.
Result: the account’s entire history is parsed, not just the last month.
Confirming the stage markup
System. The heuristic walks the history and suggests which stages are parking stages: deals there are not moving towards a sale but waiting for a call, a decision or the season.
You. The head of sales confirms the list or edits it. A person signs off, not the algorithm: on the pilot’s full history the heuristic got it wrong — the error explained. There is no “not a parking stage” button in the widget yet: you send the list by email, we apply it and recalculate.
Result: conversion runs along the sales chain, and waiting shows up as a block of its own.
Choosing analytics fields
System. We compute the completeness of every deal field and show it as a number. A field filled in on fewer than 30% of deals will not be used in a breakdown; between 30 and 60% it will, with a warning in the report header.
You. The administrator names the fields needed in breakdowns. By default nothing beyond system fields is synced: a field that could hold a name, phone or email never gets on the whitelist. There is no screen for this step yet — we set the flag from your email.
Result: breakdowns use only fields you can trust, and no personal data enters the database.
First report
System. All tabs are computed from one slice: pipeline, period, group, manager, deal field. Switching tabs resets nothing.
You. Pick a pipeline and a period. After that the questions are usually about the numbers, not the interface — the formulas are explained separately.
Result: funnel, managers and lead path — one slice, one window inside amoCRM.
estimate, not a measurement · granting access — 2 minutes, confirming the markup — 1 minute: pilot estimate; only the first load was timed
How long it takes
34 minutes on 7 years of history
Measured on the pilot account: 69,567 deals, 1,100,000 events, 240,031 transitions. A younger account loads faster — the time depends on the volume of history, not the size of the company.
Then 12 seconds every 5 minutes
The incremental sync fetches only what changed. Data freshness runs on a schedule: the webhook receiver is not written yet, and we do not promise an instant reaction to deal movement.
There will be no reports on half a history: until the first load finishes the screen shows a percentage, not half a funnel. The load is worth scheduling: the request limit is shared by every integration in the account — telephony, chats, other widgets.
measured 25.08.2026 · first full load of the pilot account (anonymised property developer account) · docs/РЕШЕНИЯ.md, пункты 37 и 40
Which permissions we request
The amoCRM access dialog shows 5 permissions. We request 1 permission and nothing else. The table below lists them all, and says for each what we do with it or why we do not need it.
| Permission | Requested | Why |
|---|---|---|
| Account data | yes | The only permission that opens the API: pipelines and stages, deals, status history, tasks, users, fields. Without it the widget has nothing to read. |
| File access | no | We neither open nor store deal attachments. |
| File deletion | no | Analytics never needs the right to delete anything. |
| Notification centre | no | The widget does not send notifications to staff inside amoCRM. |
| Amma | no | A permission for an amoCRM service. Our AI review works on our own aggregates and never calls the CRM. |
amoCRM has no separate “read-only” permission: “Account data” covers every API method, including writes. We do not hide behind a checkbox — the code enforces read-only: the amoCRM client has no write method, and a direct request bypassing the client fails the build check.
What exactly is read and what is in no table of the database — on the Data and access page.
permission list checked against the amoCRM developer documentation on 21.08.2026 · 5 permissions: “Account data”, “File access”, “File deletion”, “Notification centre”, “Amma”
If you are not the administrator — an email you can send
The text below answers everything an administrator will ask: what the widget is, which permissions, who guarantees read-only, how long it takes and how to disconnect. Select and copy.
Subject: access for the KLASTER analytics widget in our amoCRM Please connect the KLASTER funnel analytics widget to our amoCRM account. It counts conversion between adjacent stages and separately shows the stages where a deal is waiting rather than moving towards a sale. Only an administrator can install it: access in amoCRM is granted by a specific person. What is requested: 1 permission out of 5 — “Account data”. The rest are not requested: “File access”, “File deletion”, “Notification centre”, “Amma”. The widget is read-only. amoCRM has no separate “read-only” permission, so what to check is behaviour, not a checkbox in the access dialog: the widget code contains no method that writes to amoCRM. Names, phone numbers, email addresses and message texts never enter the widget database. The first history load takes 34 minutes on 7 years of history. This was measured on the pilot account, not estimated. After that a sync takes 12 seconds every 5 minutes. Access can be revoked at any time without our involvement: integration card, “Granted access” tab. The full permission list and what happens after revocation: https://klastercrm.com/widgets/analytics/install
The installation link is not in the email: it is issued per account. Request it from us — we send it within a business day.
What can go wrong
No item in the “Analytics” menu yet
Until the marketplace listing goes live the widget is installed as a private integration, and a private integration does not accept a menu item: a manifest with one is rejected on archive upload. The handler is already written and will switch on without changes once the review passes. For now the widget opens as its own page from the account’s widget list.
Access granted by someone who cannot see everything
The integration sees exactly what the granting person sees: if some pipelines are closed or dismissed staff are hidden, the transition history arrives incomplete. Grant access from an administrator with full visibility who will stay with the company.
Access was revoked
Revocation is an ordinary administrator action: integration card, “Granted access” tab, button. The widget shows “access revoked” and asks for re-authorisation instead of drawing zeros in place of numbers. What was loaded stays in the database and keeps being counted; coming back is step 1 again — we do not re-download the history.
The integration secret was reissued
Do not do this while the sync is running; amoCRM warns about it in plain text. The warning is literal: reissuing deletes every granted access at once, the “Granted access” tab goes empty and the load fails halfway. It has happened to us — a load that had run for several hours was cut off for exactly this reason.
Look before you grant access
The demo is open without sign-up and runs on anonymised data of the pilot account. It also shows the “Data quality” tab, the reason step four is on the list: on the pilot a breakdown by source is not built because the field is filled in on 19% of deals.
anonymised property developer account · July 2026 · completeness of the “Источник” field across the period’s deals