Сквозная аналитика в Битрикс24 для бизнеса в Казахстане: пошаговая настройка с Kaspi, WhatsApp и Instagram
Битрикс24 — самая распространённая CRM среди малого и среднего бизнеса в Казахстане, и в ней уже есть встроенный модуль «Сквозная аналитика». Казалось бы, задача решена из коробки: подключил рекламные кабинеты, подождал — и получил отчёт по ROI. На практике владельцы бизнеса в РК довольно быстро упираются в стену: половина клиентов платит через Kaspi Pay, значительная часть заявок приходит в WhatsApp и Instagram Direct, а встроенная аналитика Битрикс24 спроектирована прежде всего под российский рынок — с расчётом на банковский эквайринг, звонки и формы на сайте.
В этой статье — пошаговая настройка сквозной аналитики в Битрикс24 именно под казахстанские реалии: что делать с Kaspi-переводами, как правильно завести WhatsApp и Instagram-заявки, и в какой момент встроенных возможностей CRM уже недостаточно.
Что умеет и чего НЕ умеет встроенная сквозная аналитика Битрикс24
Прежде чем настраивать, стоит трезво понять границы инструмента — это сэкономит часы на попытках заставить модуль делать то, для чего он не предназначен.
Что Битрикс24 умеет хорошо: - Автоматически собирать статистику расходов из подключённых рекламных кабинетов (Яндекс.Директ, Google Ads, Facebook/Instagram Ads — там, где интеграция технически доступна) и сопоставлять её со сделками в CRM. - Строить отчёт по стандартной воронке: показы/клики → визиты на сайт → лиды → сделки → оплаченные счета, с разбивкой по источникам, если источники размечены через UTM. - Считать базовые метрики — стоимость лида, стоимость сделки, ROI — при условии, что данные о расходах и данные о доходах корректно попадают в систему. - Работать с телефонными звонками через встроенный коллтрекинг (при подключении АТС Битрикс24 или интеграции с внешними провайдерами телефонии). - Обрабатывать заявки с форм на сайте и виджета обратного звонка/чата, если сайт создан на Битрикс24 или на него установлен код отслеживания.
Чего Битрикс24 не умеет из коробки: - Автоматически распознавать оплаты через Kaspi Pay, Kaspi QR или прямые переводы на карту — это не банковский эквайринг с API-интеграцией, и система физически не видит факт такой оплаты, пока её не внесут вручную или не подключат через дополнительный коннектор. - «Из коробки» разбирать сообщения из WhatsApp и Instagram Direct на предмет источника — эти каналы не являются формами или звонками, и связка требует отдельной интеграции (Открытые линии Битрикс24 + подключённый провайдер WhatsApp Business API). - Корректно атрибутировать сделку, если путь клиента прошёл через несколько каналов (увидел рекламу в Instagram, искал в 2GIS, написал через сайт) — встроенная модель атрибуции упрощённая и рассчитана на прямой переход по одной ссылке. - Учитывать окно атрибуции гибко под конкретную нишу — стандартные настройки рассчитаны на усреднённый цикл сделки и не всегда подходят бизнесу с длинными переговорами в мессенджерах.
Вывод простой: Битрикс24 даёт хороший фундамент — единую точку сбора сделок и базовую связку с рекламой, — но для казахстанского бизнеса, где Kaspi и мессенджеры составляют значительную часть выручки, «из коробки» аналитика будет неполной. Дальше — как закрыть эти пробелы вручную и через доступные интеграции.
Подготовка: UTM, источники, окно атрибуции, реферальные домены
Прежде чем подключать каналы, нужно навести порядок в четырёх базовых настройках. Ошибка на этом этапе делает бессмысленной всю дальнейшую работу — отчёты будут собираться, но данные в них окажутся неточными.
UTM-разметка
Все ссылки на рекламу — в Instagram, Google Ads, Яндекс.Директ, TikTok Ads — должны вести на сайт с параметрами utm_source, utm_medium, utm_campaign, utm_content, utm_term. Без этого Битрикс24 не сможет связать визит с конкретной кампанией, даже если рекламный кабинет технически подключён.
Практический момент: заведите единый глоссарий обозначений каналов до того, как запустите первую кампанию — например, utm_source=instagram, utm_source=google, utm_source=whatsapp_organic, а не позволяйте каждому подрядчику или сотруднику придумывать свои варианты. В интерфейсе Битрикс24 (раздел CRM → Аналитика → Сквозная аналитика → Настройки → Правила определения источников) можно задать собственные правила сопоставления UTM-меток с источниками CRM, и если наименования разнятся, система будет плодить десятки псевдо-источников вместо аккуратной сводной таблицы.
Источники в CRM
В Битрикс24 источник сделки — это отдельное справочное поле (Источник), которое по умолчанию содержит стандартный набор («Реклама», «Существующий клиент», «Веб-сайт» и т.д.). Для нормальной аналитики этот справочник нужно расширить под реальные каналы бизнеса: «Instagram — таргет», «WhatsApp — прямой», «Google Ads», «2GIS», «Рекомендация», «Kaspi.kz — маркетплейс» (если продаёте через площадку) и так далее. Настраивается в разделе CRM → Настройки → Справочники → Источники.
Без детализированного справочника сквозная аналитика формально работает, но отчёты получаются слишком грубыми, чтобы принимать по ним решения о перераспределении бюджета.
Окно атрибуции
Окно атрибуции — это период времени, в течение которого конверсия (сделка) засчитывается за конкретный клик или визит. По умолчанию в Битрикс24 используется усреднённое значение, рассчитанное на классический цикл «увидел рекламу → купил в течение нескольких дней». Для бизнеса с длинным циклом сделки — недвижимость, B2B-услуги, дорогостоящее оборудование, где переговоры в WhatsApp могут растягиваться на 2–3 недели — стандартное окно слишком узкое, и часть реальных продаж просто не свяжется с исходным источником.
Настройка окна атрибуции доступна в параметрах сквозной аналитики (CRM → Аналитика → Сквозная аналитика → Настройки визитов). Рекомендация: перед настройкой посчитайте по своей CRM реальный средний цикл сделки за последние 3–6 месяцев (дата создания лида минус дата оплаты) и выставляйте окно атрибуции с запасом относительно этого значения, а не оставляйте значение по умолчанию.
Реферальные домены
Часть трафика приходит не по прямым рекламным ссылкам, а через сторонние площадки — 2GIS, Google Карты, агрегаторы, маркетплейсы. Битрикс24 умеет распознавать источник по реферальному домену (домену, с которого пользователь перешёл на сайт), но список доменов нужно поддерживать вручную в настройках правил определения источников, иначе такие визиты будут попадать в общую категорию «Переход по ссылке» без детализации, из какого именно каталога или карты пришёл клиент.
Подключение сайта и рекламных каналов
Когда подготовительный этап завершён, переходите к технической части.
Установка кода отслеживания. Если сайт не создан на конструкторе Битрикс24, на него нужно установить код сквозной аналитики (JS-скрипт), который генерируется в разделе CRM → Аналитика → Сквозная аналитика → Настройки → «Код для сайта». Скрипт должен быть установлен на все страницы сайта, включая посадочные страницы рекламных кампаний, иначе визиты с них не попадут в систему.
Подключение рекламных кабинетов. В разделе Сквозная аналитика доступно подключение Яндекс.Директ, Google Ads, Facebook Ads (через Business Manager) и ряда других источников через официальные интеграции — авторизация происходит через OAuth, после чего Битрикс24 автоматически подтягивает данные о расходах и кампаниях раз в сутки.
Важный нюанс для казахстанского бизнеса: доступность и стабильность интеграции с рекламными кабинетами Meta (Facebook/Instagram) может зависеть от региона аккаунта, валюты выставления счетов и текущей политики платформы в отношении конкретной страны — эти параметры стоит проверять на момент настройки, поскольку они периодически меняются и напрямую влияют на то, будут ли расходы на Instagram-рекламу подтягиваться автоматически или их придётся вносить вручную.
Проверка связки. После подключения обязательно протестируйте всю цепочку целиком: запустите тестовый переход по размеченной ссылке, убедитесь, что визит появился в отчёте, создайте тестовую сделку и проверьте, что источник в карточке сделки заполнился автоматически, а не остался пустым. Тестирование каждого канала по отдельности до массового запуска рекламы экономит недели на разборе задним числом, откуда взялись «сделки без источника».
Проблема Kaspi Pay и оффлайн-оплат — как заводить их в аналитику
Это центральная проблема, из-за которой сквозная аналитика в Битрикс24 «не работает» для многих компаний в Казахстане — и одновременно решаемая задача, если подойти к ней системно.
Почему это проблема. Kaspi Pay, Kaspi QR и прямые переводы на карту (Kaspi Gold, Halyk) — не банковский эквайринг с готовым API, интегрированным в Битрикс24 «из коробки». Когда клиент оплачивает через Kaspi, деньги приходят на счёт компании, но CRM об этом факте ничего не знает, если данные не внесены отдельно. В результате сделка технически может висеть в статусе «Ожидание оплаты» или «В работе» неделями после того, как деньги уже получены — а аналитика ROI строится именно по фактическим оплаченным счетам, и без этого шага она занижена или искажена.
Три уровня решения:
Уровень 1 — ручная фиксация (минимальный, подходит для старта). В сделке заводится обязательное поле «Способ оплаты» (Kaspi Pay / Kaspi QR / перевод / наличные / банковский эквайринг) и обязательный шаг воронки «Оплата подтверждена», который менеджер обязан проставлять вручную сразу после получения перевода. Это не требует технической интеграции, но требует дисциплины: без регламента и контроля менеджеры быстро начинают забывать про этот шаг, особенно при высокой загрузке.
Уровень 2 — автоматизация через выгрузку из Kaspi. Kaspi для бизнеса предоставляет выгрузку истории операций (через личный кабинет Kaspi Pay для бизнеса). Эту выгрузку можно регулярно сверять с суммами открытых сделок в Битрикс24 — вручную (для небольшого потока заявок) или через полуавтоматический скрипт, который сопоставляет суммы и номера телефонов из выгрузки с открытыми сделками CRM и подсказывает, какие из них закрыть как оплаченные. Это не полноценная интеграция в реальном времени, но заметно снижает ручной труд по сравнению с уровнем 1.
Уровень 3 — интеграция через API и автоматизацию без кода. Для компаний с более высоким потоком операций возможна связка через Битрикс24 REST API и автоматизацию бизнес-процессов: настраивается сценарий, который при поступлении данных об оплате (например, через вебхук от платёжного агрегатора, если бизнес принимает Kaspi-платежи через партнёрский сервис с API, а не напрямую) автоматически переводит сделку в статус «Оплачено» и фиксирует сумму. Такие сценарии сегодня можно строить и без привлечения штатного разработчика — через no-code/low-code инструменты автоматизации или через AI-агентов, которые подключаются к REST API Битрикс24 и к банковским выгрузкам напрямую, сверяя и разнося платежи без участия менеджера.
Практическая рекомендация: начните с уровня 1 (обязательное поле + регламент) уже сегодня — это даёт немедленный эффект и не требует бюджета на разработку. Параллельно оцените объём операций: если оплат через Kaspi больше 30–50 в месяц и ручная сверка отнимает заметное время сотрудника, имеет смысл инвестировать в уровень 2 или 3.
Подключение WhatsApp/Instagram-заявок
Мессенджеры — второй по значимости источник «слепых зон» для казахстанского бизнеса на Битрикс24, и подключается он иначе, чем реклама или сайт.
Механизм подключения. В Битрикс24 для этого предназначен модуль «Открытые линии» (CRM → Контакт-центр → Открытые линии). WhatsApp подключается либо через официальный канал WhatsApp Business Platform (Cloud API), либо через партнёрские интеграции — Wazzup, Gupshup, i2crm и аналогичные сервисы, которые выступают технической прослойкой между WhatsApp Business API и Битрикс24. Instagram Direct подключается через официальную интеграцию Битрикс24 с Instagram-профилем компании (Facebook Business Manager) или также через сторонние коннекторы, если требуется более гибкая настройка.
После подключения все входящие сообщения из WhatsApp и Instagram превращаются в карточки лида или сделки в CRM, попадая в общую воронку наравне с заявками с сайта и звонками.
Как передать источник заявки. Сам факт подключения открытой линии не решает задачу атрибуции — по умолчанию все сообщения в WhatsApp попадают в CRM с источником «Открытая линия» без разбивки на конкретную рекламную кампанию. Чтобы восстановить связь с источником, нужна разметка на входе: кнопка «Написать в WhatsApp» на сайте должна формироваться динамически, с UTM-параметрами, зашитыми в текст первого сообщения (подробный технический разбор этого механизма — в статье про сквозную аналитику WhatsApp). Когда сообщение с меткой источника приходит в подключённую открытую линию, интеграция (например, Wazzup) может автоматически парсить эту метку и проставлять её в поле «Источник» сделки, вместо того чтобы вся масса WhatsApp-заявок обезличенно сваливалась в одну категорию.
Специфика Instagram Direct. У Instagram есть дополнительная сложность: значительная часть обращений приходит не через явный клик по рекламе, а через переход в профиль после просмотра Reels или поста, и дальше — сообщение в Direct без чёткого referrer. В этом случае Meta предоставляет собственные инструменты атрибуции внутри рекламного кабинета (Ads Manager показывает количество сообщений, инициированных по конкретному объявлению), но связать это с конкретной сделкой в Битрикс24 напрямую сложнее, чем с WhatsApp, и часто требует ручной сверки по времени обращения и содержанию первого сообщения, либо использования вопроса-квалификатора («Как вы о нас узнали?») как резервного метода — подробнее об этом и других способах трекинга источника в мессенджерах мы писали в статье как отследить, откуда пришёл клиент в WhatsApp.
Что делать, если нужного источника нет: no-code через API и вебхуки
Рано или поздно возникает канал, для которого нет готовой кнопки интеграции в Битрикс24: например, заявки с маркетплейса, форма на лендинге, сделанном не на конструкторе Битрикс24, чат-бот в Telegram, или внутренний сервис записи на сайте.
REST API Битрикс24. У Битрикс24 есть открытый REST API, который позволяет создавать сделки, лиды и контакты программно — из любой внешней системы, которая умеет отправлять HTTP-запросы. Практически любой источник, у которого есть собственный API или возможность настроить вебхук (уведомление о новом событии), можно завести в CRM автоматически, минуя ручной ввод.
Механика через входящий вебхук. Самый простой способ для несложных случаев — создать в Битрикс24 входящий вебхук (Разработчикам → Другое → Входящий вебхук) с правами на создание сделок. Внешний сервис при получении новой заявки отправляет HTTP-запрос на этот вебхук с данными — именем, телефоном, источником, — и в CRM автоматически появляется новая сделка с уже заполненными полями, включая корректный источник.
Пример сценария. Заявки приходят через форму на Tilda-лендинге, который не связан с Битрикс24 напрямую. Настраивается связка: Tilda при отправке формы дёргает вебхук Zapier, Make или аналогичного no-code-сервиса автоматизации, который форматирует данные и передаёт их в Битрикс24 через входящий вебхук CRM, автоматически проставляя источник «Tilda — форма записи» и сохраняя исходные UTM-параметры, переданные вместе с формой.
Роль AI-агентов и Claude Code в этой задаче. Для более сложных или нестандартных сценариев интеграции (например, когда данные приходят в неструктурированном виде — текстом из чата, из PDF-счёта, из голосового сообщения) сегодня не обязательно писать классический код интеграции с нуля силами разработчика. AI-агенты, подключаемые через протокол MCP (Model Context Protocol) к REST API Битрикс24 и к источнику данных, способны сами разбирать входящие данные, приводить их к нужному формату и создавать сделки с корректно проставленными полями — это заметно сокращает время и стоимость разработки нетиповых интеграций по сравнению с классической разработкой.
Когда стоит привлекать разработчика или интегратора. Если поток заявок из нестандартного источника превышает несколько десятков в месяц и требует сложной логики обработки (например, объединение дублей, обогащение данных, многошаговая маршрутизация по ответственным), разовая настройка вебхука через no-code-сервис становится хрупкой, и целесообразнее выделить бюджет на полноценную интеграцию с обработкой ошибок и логированием.
Типичные ошибки атрибуции
Ошибка 1. UTM-метки настроены только для новых кампаний, а старые ссылки остаются без разметки. Часть трафика продолжает идти по «старым» неразмеченным ссылкам — в закреплённых постах, в описании профиля Instagram, в подписи на визитках — и такие визиты попадают в категорию «Прямой заход», искажая реальную картину источников.
Ошибка 2. Сделка создаётся вручную, а не через автоматический захват источника. Когда менеджер, получив заявку в WhatsApp, вручную создаёт карточку сделки в CRM (вместо того чтобы CRM создавала её автоматически через интеграцию открытой линии), он физически не видит и не заполняет техническую метку источника — эта информация просто теряется на этапе ручного ввода.
Ошибка 3. Разные сотрудники по-разному называют источники в свободном текстовом поле. Если справочник источников не настроен как выпадающий список, а используется свободное текстовое поле, за несколько месяцев накапливаются десятки вариаций написания одного и того же канала, и построить внятный отчёт по ним невозможно без ручной чистки данных.
Ошибка 4. Оплата через Kaspi не фиксируется вовремя, из-за чего сделка «зависает». Как только менеджер забывает отметить факт оплаты, сделка продолжает числиться в промежуточном статусе, и отчёт по ROI за текущий месяц занижает реальную конверсию и выручку, создавая ложное впечатление, что реклама работает хуже, чем на самом деле.
Ошибка 5. Окно атрибуции не пересматривается после изменения бизнес-процессов. Например, компания раньше продавала «в одно касание» (клиент сразу оплачивал через сайт), а затем перешла на модель с консультацией менеджера в WhatsApp перед покупкой — цикл сделки вырос, а окно атрибуции осталось прежним, и часть реальных продаж перестала засчитываться за исходную рекламу.
Ошибка 6. Игнорирование мультиканальных путей. Встроенная модель Битрикс24 засчитывает конверсию по определённой логике (обычно ближе к last-click), и если аналитик воспринимает эти данные как абсолютную истину без поправки на то, что клиент мог видеть несколько касаний до финального клика, решения о перераспределении бюджета могут быть основаны на неполной картине — особенно это критично для верхнеуровневых имиджевых каналов вроде брендовой рекламы в Instagram.
Когда Битрикс24 не хватает и нужен внешний BI
Встроенная сквозная аналитика Битрикс24 хорошо закрывает потребности малого бизнеса с относительно простой воронкой и умеренным потоком сделок. Но есть признаки, что пора смотреть в сторону внешних BI-инструментов (Power BI, Looker Studio, DataLens, или AI-дашбордов, собирающих данные из нескольких систем):
- Данные разбросаны по нескольким CRM или системам учёта, помимо Битрикс24 (например, отдельная система склада, бухгалтерия, другой инструмент для маркетплейсов), и нужен единый отчёт, объединяющий их все — Битрикс24 не предназначен для консолидации данных из внешних систем на уровне полноценного BI.
- Нужны нестандартные, глубоко кастомизированные визуализации и метрики, которых нет в стандартных отчётах Битрикс24, — например, когортный анализ по LTV клиентов, сложные воронки с ветвлениями, сравнение эффективности менеджеров с учётом весов сделок.
- Объём данных и сложность запросов превышают то, что удобно обрабатывать внутри CRM — когда отчёты формируются медленно, а фильтрация по множеству параметров одновременно неудобна в стандартном интерфейсе.
- Требуется автоматическая рассылка регулярных отчётов различным ролям в компании (руководителю — сводка по ROI, отделу продаж — операционные метрики, маркетингу — детализация по кампаниям) в разных форматах и с разной периодичностью — это можно настроить и автоматизировать через внешние инструменты быстрее и гибче, чем через встроенные средства CRM.
В таких случаях данные из Битрикс24 выгружаются через REST API или готовые коннекторы в BI-систему или AI-дашборд, где они объединяются с данными из рекламных кабинетов, Kaspi-выгрузок и других источников в единую картину. Это следующий логичный шаг после того, как встроенная сквозная аналитика настроена корректно и данные в CRM стали достаточно чистыми и полными, чтобы их имело смысл выгружать наружу — построение BI поверх грязных, неполных данных только усилит путаницу, а не решит её.
Сквозная аналитика в Битрикс24 — рабочий инструмент, но для казахстанского бизнеса её нужно донастраивать сверх стандартных возможностей: закрыть разрыв с Kaspi-платежами через регламент и/или автоматизацию, корректно завести WhatsApp и Instagram через открытые линии с передачей источника, и не полагаться слепо на встроенную модель атрибуции там, где путь клиента проходит через несколько каналов. Сделанная один раз аккуратно, эта настройка окупается тем, что решения о рекламном бюджете начинают опираться на реальные цифры, а не на ощущения.
Частые вопросы
Можно ли в Битрикс24 автоматически учитывать оплаты через Kaspi Pay?
Из коробки — нет: Kaspi Pay не банковский эквайринг с готовым API в CRM. Есть три уровня решения: обязательное поле «Способ оплаты» + ручная фиксация, сверка выгрузки операций Kaspi со сделками, либо автоматизация через REST API и вебхуки для перевода сделки в «Оплачено» без участия менеджера.
Как передать источник рекламы для заявок из WhatsApp и Instagram в Битрикс24?
Открытые линии сами не считывают UTM — источник нужно зашивать в текст первого сообщения на этапе перехода в WhatsApp, а интеграция (Wazzup, Gupshup и подобные) уже парсит эту метку и проставляет её в поле «Источник» сделки.
Нужно ли менять окно атрибуции по умолчанию?
Да, если цикл сделки длиннее нескольких дней — недвижимость, B2B, дорогостоящее оборудование. Стоит посчитать реальный средний цикл сделки по своей CRM за 3–6 месяцев и выставить окно атрибуции с запасом, а не оставлять значение по умолчанию.
Когда пора переходить с встроенной аналитики Битрикс24 на внешний BI?
Когда данные разбросаны по нескольким системам помимо CRM, нужны нестандартные визуализации вроде когортного анализа LTV, или объём и сложность запросов уже неудобно обрабатывать в интерфейсе CRM.