CRM аналитика дашборд 2026: как собрать отчеты по продажам и не поверить грязным данным

CRM аналитика полезна только тогда, когда руководитель понимает, что именно считает дашборд: закрытые сделки, оплаченные деньги, pipeline, прогноз, повторные продажи или маркетинговую атрибуцию. Если эти определения не записаны, Power BI, Looker, Metabase, Битрикс24, amoCRM/Kommo и HubSpot покажут разные цифры и все будут выглядеть правдоподобно.

Для первого CRM-дашборда не нужен большой BI-проект. Часто достаточно выгрузить сделки в CSV/XLSX, согласовать 5-8 KPI, проверить дубли и собрать управленческий экран. Но production-отчет нельзя строить только на красивой воронке: нужны стабильные ID этапов, дата оплаты, дедупликация, правило атрибуции, свежесть данных и список строк, которые не попали в расчет.

Главное

CRM-дашборд должен разделять минимум три сущности: Closed Won, оплата и выручка в управленческом периоде. Это не одно и то же.
В Bitrix24 REST метод crm.deal.list поддерживает выбор пользовательских полей через UF_*, но возвращает страницы данных и next, если найдено больше 50 сделок. Одного запроса недостаточно для полного отчета.
В Kommo API есть лимит активности: не более 7 запросов в секунду; при превышении возвращается 429, а при повторных нарушениях возможен 403-блок.
В HubSpot revenue attribution зависит от closed-won deals, связанного контакта, заполненных Amount, Create date, Close date и выбранной модели атрибуции. Без этих условий часть выручки не попадет в отчет атрибуции.
В Metabase CSV append сохраняет повторяющиеся строки, если они есть между загрузками. Это удобно для пилота, но не заменяет дедупликацию CRM-сделок.
Power BI и Looker требуют явного правила refresh/cache. Иначе команда может смотреть на старые данные, думая, что экран живой.
SimpleDashboard подходит как быстрый слой для CRM-аналитики из CSV/XLSX/Google Sheets/API. AI ускоряет сборку, но формулы KPI и спорные строки должен подтвердить владелец продаж.

Эта статья для собственника, РОПа, коммерческого директора, маркетолога или операционного менеджера, которому нужен CRM-дашборд для еженедельных решений, а не общий список графиков из CRM.

В нашем тесте на обезличенной CRM-выгрузке первый полезный результат появился не в графике выручки, а в таблице ошибок: две won-сделки совпадали по телефону и сумме, у трех сделок не было даты оплаты, а один источник был записан как tg, telegram и Telegram Ads. В клиентских разборах первый спор тоже почти всегда возникает не про визуализацию, а про смысл поля. В CRM сделка закрыта как выигранная 28 числа, деньги пришли 3 числа следующего месяца, маркетинг хочет записать канал по первой UTM, РОП - по последней заявке, а бухгалтерия смотрит оплату и возврат. Если это не развести в словаре KPI, дашборд станет генератором конфликтов.

Что считать CRM аналитикой

CRM аналитика - это не просто отчет "сделки по этапам". Рабочий дашборд связывает данные CRM с управленческим действием:

Событие: лид создан, квалифицирован, переведен на этап, закрыт, оплачен, возвращен, продлен.
Источник: Bitrix24, Kommo/amoCRM, HubSpot, 1С, банк, рекламный кабинет, таблица.
Формула: что входит в KPI, что исключается, какая дата и валюта используются.
Качество данных: дубли, пустые даты, неизвестные статусы, несколько pipeline, сломанные связи contact-deal.
Решение: что делает команда, если KPI ушел за порог.

Главное правило: CRM-дашборд должен показывать не только красивые графики, но и причину доверия к цифрам. Минимум - дата обновления, формулы ключевых KPI и отдельный блок ошибок данных.

KPI-карта для CRM-дашборда

KPI	Формула для первого запуска	Какие поля нужны	Какое решение принять
Новые лиды / SQL	Лиды, прошедшие квалификацию за период	`lead_id`, дата создания, статус квалификации, источник	Проверить качество входящего потока и критерии SQL
Pipeline value	Сумма открытых сделок по этапам	`deal_id`, сумма, валюта, pipeline, stage ID, менеджер	Понять покрытие плана и где застряли деньги
Конверсия по этапам	Сделки, перешедшие дальше / сделки на этапе	История этапов или даты входа/выхода по этапам	Чинить конкретный этап, а не всю воронку
Win rate	Won-сделки / все закрытые сделки	Closed won/lost stage, дата закрытия, pipeline	Сравнить сегменты, менеджеров и каналы
Оплаченная выручка	Оплаты минус возвраты за период	`paid_at`, `payment_amount`, возвраты, валюта	Управлять планом, cash flow и бонусами
Closed won amount	Сумма сделок в won-стадии за период закрытия	`closed_at`, won stage, `amount`	Оценивать продажи, но не подменять оплату
Скорость сделки	Медианное время от создания до won/paid	Даты создания, этапов, закрытия, оплаты	Найти этапы с задержкой и stale deals
TTFR	Время от лида до первого ответа менеджера	Дата создания лида, первая активность/комментарий/звонок	Настроить SLA первого касания
Атрибуция выручки	Выручка по выбранной модели: first touch, last touch, deal create, closed won	UTM/referrer, контакт, сделка, дата, модель attribution	Оценивать каналы без смешивания моделей
Контроль данных	Дубли, пустые суммы, неизвестные этапы, сделки без контакта	Уникальные ключи, обязательные поля, справочники	Исправить источник до управленческого вывода

Для первого экрана обычно хватает 5-8 KPI: лиды, pipeline, конверсия, win rate, оплаченная выручка, скорость сделки, просроченные сделки и качество данных. LTV, ROMI и сложную revenue attribution лучше добавлять после нормализации клиентов, оплат и источников.

Риски, которые чаще всего ломают CRM-отчеты

Риск	Как выглядит в жизни	Что ломается	Как снизить риск
Дубли сделок	Один заказ создан как две won-сделки или сделка задублировалась при импорте	Выручка, win rate, pipeline, прогноз	Dedup по `deal_id`, внешнему `order_id`, телефону/email и сумме; список спорных строк
Дубли из-за join	Сделка умножилась на количество активностей, товаров или контактов	Количество сделок и сумма	Агрегировать активности до одной строки на сделку или считать distinct deals
Этапы воронки не определены	Менеджеры по-разному используют "КП", "Переговоры", "Счет"	Конверсия между этапами и time-in-stage	Словарь stage ID, критерии входа/выхода, запрет "технических" won-этапов в revenue
Сделка пропустила этап	Funnel report исключает или искажает такие сделки	Stage conversion	Решить, считаем "all stages" или "any stage", и подписать это в отчете
Closed won принят за оплату	Договор подписан в мае, деньги пришли в июне	Выручка, бонусы, cash flow	Развести `closed_at`, `paid_at`, `recognized_period` и не платить бонусы по спорной формуле
Возвраты не вычитаются	Возврат прошел отдельной операцией и не связан со сделкой	Net revenue, маржа, повторные продажи	Отдельное поле `refund_amount` и правило даты возврата
Несколько pipeline	Pipeline продаж, продлений и доставки все дают closed won	Revenue завышена, менеджеры сравниваются некорректно	Фильтр pipeline, тип сделки, zero amount для сервисных pipeline
Атрибуция без модели	Маркетинг считает first touch, продажи - last touch, HubSpot - revenue attribution	CAC, ROMI, канал продаж	Показывать model name рядом с графиком и хранить исходные UTM
API выгружает неполную выборку	Забрали первую страницу сделок и забыли pagination	Все totals ниже реальности	Постраничная загрузка, cursor/`next`, контроль количества строк
Rate limit и retry storm	Интеграция Kommo быстро повторяет запросы и ловит 429/403	Автообновление и ежедневный отчет	Throttling, backoff, инкрементальная выгрузка по `updated_at`
CSV append без дедупликации	Каждую неделю добавляется полный экспорт CRM	Выручка растет сама по себе	Загружать инкремент или заменять модель; проверять уникальный ключ
Старый кэш BI	Пользователь видит "сегодня", а данные из вчерашнего refresh/cache	Оперативные решения	Показывать `last_updated_at`, refresh history и freshness SLA

Community-сигналы подтверждают, что это не теоретические проблемы. В HubSpot Community обсуждают сценарий, где отчет показывает одну сделку несколько раз из-за активности; другой частый вопрос - является ли Closed Won оплатой или только подписанным контрактом. В обсуждениях funnel reports всплывает настройка "all stages": если сделка пропустила этап, conversion rate может считаться не так, как ожидает команда. Эти источники не доказывают лимиты платформ, но хорошо показывают реальные места, где CRM-аналитика ломается.

Что говорят официальные docs по CRM и BI

Bitrix24

Официальный REST метод crm.deal.list возвращает список сделок по select, filter, order и start. В select можно использовать маску * для стандартных полей и UF_* для пользовательских полей. Документация также указывает, что next появляется, если найдено больше 50 элементов, а CONTACT_IDS метод не поддерживает: для сделок со списком контактов предлагается crm.item.list.

Практический вывод: CRM-дашборд по Bitrix24 должен забирать все страницы, явно выбирать нужные поля и отдельно решать связь сделки с контактами. Для пользовательских полей полезно сначала получить схему через crm.deal.fields или crm.deal.userfield.list, а не полагаться на названия в интерфейсе.

Kommo / amoCRM

Kommo API требует работать с точным адресом аккаунта вида https://subdomain.kommo.com, а не с общим доменом. В limitations указано ограничение активности - не более 7 запросов в секунду. При превышении возвращается HTTP 429; при повторном нарушении возможен 403-блок. Метод leads list возвращает до 250 сущностей за запрос и поддерживает фильтры по pipeline_id, status_id, responsible user и датам создания, обновления и закрытия.

Практический вывод: для Kommo/amoCRM нужно строить инкрементальную выгрузку по updated_at, ограничивать скорость запросов и хранить не только названия этапов, но и pipeline_id/status_id. Иначе отчет легко сломается после переименования стадии.

HubSpot

В документации HubSpot default deal properties Amount описан как значение сделки в валюте сделки, а Closed amount - как Amount для deals, помеченных Closed Won. Для time-in-stage HubSpot использует свойства входа/выхода из этапов. В attribution docs HubSpot разделяет contact create, deal create и revenue attribution; для revenue attribution сделка должна быть closed-won, иметь связанный contact и заполненные Amount, Create date, Close date. В расчет попадает revenue from the deal's Amount property и связанные interactions.

Практический вывод: если в CRM "won" означает подписанный договор, а оплата живет в банке или 1С, HubSpot revenue report нельзя автоматически считать cash revenue. Для CRM-дашборда нужно отдельное поле оплаты или связь с финансовым источником.

Power BI

Microsoft Learn различает data refresh, OneDrive refresh, tile refresh и automatic page refresh. Для shared capacity scheduled refresh ограничен 8 разами в день, для Premium/PPU/Fabric capacity - до 48 раз в день в настройках. Документация также объясняет, что OneDrive refresh синхронизирует файл и метаданные, но не заменяет полноценное обновление исходных источников.

Практический вывод: если CRM-дашборд должен обновляться каждые 10 минут, одного scheduled refresh на Pro может быть недостаточно. Нужно заранее выбрать режим: API-инкремент, DirectQuery, отдельная витрина или ручной CSV-пилот.

Looker

Google Cloud Looker docs по caching and datagroups объясняют, что до истечения persist_for или max_cache_age повторный запрос может брать данные из cache. Даже при значениях 0 minutes кешированные данные могут храниться до 10 минут. Datagroups позволяют привязать cache reset к ETL-логике.

Практический вывод: для управленческого CRM-дашборда в Looker нужно явно подписывать freshness и синхронизировать кеш с загрузкой данных. Иначе отчет может быть технически корректным, но не тем "сегодня", который ожидает РОП.

Metabase

Metabase uploads позволяют создать, заменить или append CSV в модель. При append CSV должен иметь те же имена, порядок и типы колонок; если между загрузками есть duplicate rows, Metabase сохранит эти повторяющиеся строки. Metabase также добавляет _mb_row_id как технический первичный ключ для загруженного CSV.

Практический вывод: Metabase удобен для быстрого CRM-пилота, но не решает задачу "одна сделка - одна строка" автоматически. При еженедельной полной выгрузке нужно заменить модель или дедуплицировать по внешнему deal_id.

Как собрать CRM-дашборд через SimpleDashboard

SimpleDashboard подходит, когда нужно быстро превратить CRM-выгрузку в понятный экран: воронка, KPI продаж, менеджеры, источники, просроченные сделки и ошибки данных.

Шаг 1. Подготовьте выгрузку

Минимальный набор полей:

deal_id или другой стабильный ID;
pipeline_id, stage_id, человекочитаемое название этапа;
сумма, валюта, скидка, возврат;
даты: создание, переходы этапов, closed won/lost, оплата;
менеджер, источник, UTM/referrer;
contact/company ID или очищенный ключ клиента;
первая активность менеджера для TTFR;
внешний order_id или invoice_id, если есть связь с оплатами.

Если в файле есть телефоны, email, комментарии менеджеров или другие персональные данные, лучше убрать лишнее до загрузки. Для пилота часто достаточно обезличенного customer key.

Шаг 2. Зафиксируйте словарь KPI

Перед генерацией графиков запишите:

что значит "продажа";
чем Closed Won отличается от оплаты;
какие pipeline участвуют в revenue;
как считаются возвраты;
какая модель attribution используется;
что считается дублем;
какой freshness SLA у отчета;
кто владелец каждой формулы.

Это занимает меньше времени, чем потом объяснять, почему РОП, маркетинг и финансы видят разные цифры.

Шаг 3. Отправьте файл в Telegram

Загрузите CSV/XLSX или ссылку на таблицу в @coderboxbot и опишите задачу:

"Нужен CRM-дашборд: новые лиды, pipeline по этапам, win rate, closed won amount, оплаченная выручка, TTFR, stale deals, источники и отдельная таблица дублей. Closed won не считать оплатой. Атрибуция - first touch и last touch рядом".

AI предложит структуру экрана, фильтры, графики и список подозрительных строк. После этого человек проверяет формулы и контрольные сделки.

Шаг 4. Проверьте контрольные строки

Я не считаю CRM-дашборд готовым без ручной сверки:

5-10 сделок открыть в CRM и проверить суммы, этапы, даты, ответственных.
3-5 оплат сверить с банком, 1С или платежным сервисом.
Дубли посмотреть вручную, особенно совпадения по телефону/email/компании.
Проверить одну сделку, которая пропускала этап.
Проверить сделку, где Closed Won и paid_at находятся в разных месяцах.

Если эти строки проходят проверку, можно публиковать первый экран. Если нет - сначала чинится источник, потом графики.

Когда SimpleDashboard подходит, а когда нужен BI-проект

Сценарий	Что выбрать
Нужен первый CRM-дашборд из CSV/XLSX за день	SimpleDashboard
Нужно согласовать KPI перед большим BI-проектом	SimpleDashboard как прототип и словарь метрик
CRM-выгрузки небольшие, обновление вручную или раз в день	SimpleDashboard или Metabase
Есть Microsoft stack, DAX, semantic model, gateway, роли	Power BI
Есть DWH, LookML, datagroups, governance и self-service	Looker
Нужен self-hosted SQL BI с понятными dashboards	Metabase
KPI влияют на официальную финансовую отчетность или юридические обязательства	Отдельный ETL/BI-проект с аудитом
Нужны сотни ролей, row-level security, data catalog и lineage	Корпоративная BI-архитектура

Практическое правило: если компания еще спорит, что такое "выручка", покупка тяжелого BI не решит проблему. Сначала нужен словарь KPI, карта источников и контроль качества данных.

FAQ

Чем CRM-дашборд отличается от встроенного отчета CRM? Встроенный отчет обычно работает внутри одной CRM и ее модели данных. CRM-дашборд для руководителя часто объединяет CRM, оплаты, возвраты, рекламные расходы и правила KPI в один управленческий экран.

Можно ли считать выручку по Closed Won? Можно, если в вашей компании Closed Won означает именно признанную продажу по согласованному правилу. Но если оплата приходит позже или частями, лучше разделить closed won amount и paid revenue.

Как бороться с дублями сделок? Нужен уникальный ключ: deal_id, внешний order_id, invoice ID или комбинация customer key + сумма + дата. В отчете стоит показывать отдельную таблицу подозрительных дублей, а не молча удалять их.

Почему воронка в CRM и BI показывает разные конверсии? Чаще всего отличаются правила: "all stages" или "any stage", учет пропущенных этапов, фильтр pipeline, дата входа в этап, дата закрытия и исключение технических сделок.

Можно ли подключить Bitrix24 или Kommo по API? Да. Для Bitrix24 нужно учитывать pagination и UF_* для пользовательских полей. Для Kommo - лимит запросов, page/limit и стабильные pipeline_id/status_id.

Power BI лучше SimpleDashboard? Для зрелого Microsoft BI-контура - да. Power BI сильнее в semantic models, DAX, governance и enterprise refresh. SimpleDashboard полезнее как быстрый прикладной слой, когда надо согласовать KPI и получить первый рабочий экран без BI-команды.

AI сам найдет правильные формулы? AI может предложить структуру, найти аномалии и собрать графики. Но правильность "выручки", "оплаты", "won", "возврата" и "атрибуции" зависит от бизнес-правил. Эти правила утверждает человек.

Смотрите также

Стоимость

SimpleDashboard стоит 5 000 ₽/мес. Для первого разговора достаточно CRM-выгрузки CSV/XLSX и короткого описания: какие решения вы хотите принимать по дашборду каждую неделю.

Напишите в Telegram: @coderboxbot. Первый CRM-дашборд можно собрать как бесплатный пилот на одном наборе данных.

Попробовать бесплатно | SimpleDashboard

Источники и проверка

Официальные источники:

Bitrix24 REST: crm.deal.list
Bitrix24 REST: crm.deal.fields
Bitrix24 REST: crm.deal.userfield.list
Kommo Developers: Limitations
Kommo Developers: HTTP status code
Kommo Developers: Leads list
HubSpot Knowledge Base: HubSpot's default deal properties
HubSpot Knowledge Base: Attribution report definitions
Microsoft Learn: Data refresh in Power BI
Google Cloud Looker: Caching queries and datagroups
Metabase Docs: Uploading data

Community-сигналы, использованные только как индикаторы практических проблем:

HubSpot Community: Is "closed" paid or just contract signed?
HubSpot Community: Deal funnel with all stages - can't see conversion rate between stages
HubSpot Community: Report shows duplicate deals because of activity type
Reddit r/SaaS: How are you handling attribution from landing page to signup to revenue?

Материал обновлен 2026-05-05 для wave simple-dashboard-wave-4 по issue #113. AI-инструмент использовался для первичного исследования официальных CRM/BI docs, группировки типовых ошибок и черновой структуры. Финальные формулы KPI, ограничения инструментов, источники, выводы и продуктовые обещания проверил Александр Руин, основатель habab.ru.

О сервисе "AI-конструктор бизнес-дашбордов"

Платформа для создания аналитических дашбордов через AI-чат. Загрузите CSV/Excel или подключите API, опишите какие метрики нужны — получите готовый дашборд с графиками, KPI и фильтрами. Без программирования, за минуты.

Ключевые преимущества:

Не нужен программист или BI-аналитик
Дашборд готов за минуты, а не за недели
AI сам предлагает подходящие визуализации
Данные остаются на вашем сервере
Интеграция с любыми источниками через API
Автоматическое обновление и рассылка отчётов

Для кого подходит:

Руководители малого и среднего бизнеса Маркетологи и аналитики Руководители отделов продаж Финансовые директора Продакт-менеджеры стартапов

Сценарии использования:

💡 Дашборд продаж с воронкой и KPI

💡 Маркетинговая аналитика (трафик, конверсии, ROI)

💡 Финансовый дашборд (выручка, расходы, прогнозы)

💡 Мониторинг операций (заказы, склад, логистика)

💡 CRM-аналитика (лиды, сделки, pipeline)

💡 Управленческие отчёты для руководителя

💡 Воронка продаж — визуализация этапов и конверсий

💡 KPI менеджеров по продажам — план/факт и рейтинг

💡 Сквозная аналитика — от рекламы до сделки

💡 Отчёт менеджера по продажам — ежедневный/недельный

💡 Дашборд отдела продаж — сводка по команде

Связанные ключевые слова

crm аналитика дашборд crm аналитика amoCRM аналитика Битрикс24 отчёты crm crm дашборд продаж bi аналитика битрикс24 power bi amocrm

📰 Промо-статьи наших решений

Изучите детальные обзоры наших технологических решений для различных отраслей:

Работаю до результата и бизнес-ценности, быстро корректирую подходы в процессе. Использую современный стек для качественного и быстрого решения задач.