Критерий отбора
Списки «топ-10 систем аналитики» бесполезны, потому что сравнивают несравнимое: система для продуктовой аналитики и коллтрекинг решают разные задачи и не конкурируют.
Здесь инструменты сгруппированы по вопросу, на который они отвечают. Внутри каждой группы указано, где система перестаёт работать — это обычно важнее списка возможностей.
| Вопрос бизнеса | Класс системы | Обязательное условие |
|---|---|---|
| Откуда пришли и что делали на сайте | Классическая веб-аналитика | Установленный счётчик |
| Какая реклама принесла деньги | Сквозная аналитика | Заполняемая CRM |
| Что делают внутри продукта | Продуктовая аналитика | Размеченные события |
| Откуда звонят | Коллтрекинг | Пул номеров |
| Как собрать данные без cookie | Приватная аналитика | Свой сервер или хостинг вендора |
1. Классическая веб-аналитика
Отвечает на вопрос «откуда пришли посетители и что делали». Базовый слой, с которого начинают все.
Яндекс.Метрика. Бесплатна без ограничений по трафику. Сильные стороны для русскоязычного рынка: Вебвизор с записью сессий, карты скроллинга и кликов, встроенная связка с Директом, отчёты по роботности. Слабое место — данные о зарубежной аудитории заметно менее полные.
Google Analytics 4. Бесплатна, событийная модель вместо сеансовой. Сильные стороны: интеграция с Google Ads, выгрузка сырых данных в BigQuery, кросс-платформенность. Слабое место — порог входа: интерфейс и модель данных сложнее, чем у предшественника, и типовые отчёты приходится собирать руками.
2. Сквозная аналитика
Отвечает на вопрос «какая реклама принесла деньги». Связывает клик, заявку, сделку в CRM и сумму оплаты в одну цепочку.
К этому классу относятся Roistat, Calltouch, CoMagic и аналогичные платформы. Различия между ними в основном в глубине интеграций и модели тарификации, а не в принципе работы.
Обязательное условие — заполняемая CRM. Если менеджеры не доводят сделки до статуса и не проставляют суммы, система будет считать по неполным данным и давать уверенно неверный ответ. Это не проблема конкретного вендора, а свойство подхода.
Где ломается: длинные сделки с несколькими лицами, принимающими решение; офлайн-касания, которых нет в цифровом следе; повторные продажи, которые не привязываются к первому источнику.
3. Продуктовая аналитика
Отвечает на вопрос «что пользователи делают внутри продукта». Amplitude, Mixpanel и подобные системы построены вокруг событий и когорт, а не сеансов и источников.
Нужна там, где ценность создаётся внутри интерфейса: SaaS, приложения, личные кабинеты. Для сайта услуг избыточна.
Главное ограничение: качество данных определяется качеством разметки событий. Система не «видит» продукт сама — она показывает ровно то, что разработчики отправили. Плохо спроектированная схема событий делает дорогую систему бесполезной, и переделывать её задним числом дорого.
4. Коллтрекинг
Отвечает на вопрос «с какой рекламы позвонили». Подменяет номер телефона на сайте в зависимости от источника визита.
Нужен там, где значимая доля обращений идёт голосом: медицина, недвижимость, услуги с высоким чеком, B2B. Если звонков мало, расходы на пул номеров не окупаются.
Динамический коллтрекинг привязывает звонок к конкретной сессии и требует большого пула номеров. Статический закрепляет номер за каналом целиком — дешевле и достаточно, когда каналов немного.
5. Приватная аналитика
Отвечает на тот же вопрос, что классическая, но без cookie и с хранением данных на своей стороне: Matomo, Plausible, Umami.
Выбирают, когда требования к обработке данных или отказ от cookie-баннера важнее глубины отчётов. Компромисс честный: вы получаете меньше срезов и никакой записи сессий, но полностью контролируете данные.
Что выбрать: короткая схема
| Ситуация | Минимально достаточный набор |
|---|---|
| Контентный сайт, блог | Метрика или GA4 |
| Интернет-магазин | Метрика + электронная коммерция + GA4 для зарубежного трафика |
| Услуги с заявками | Метрика + CRM, сквозная аналитика при бюджете от заметного |
| Услуги со звонками | То же + коллтрекинг |
| SaaS, приложение | GA4 или продуктовая система + разметка событий |
| Жёсткие требования к данным | Matomo или Plausible на своём сервере |
По каким критериям системы отличаются на практике
Перечни возможностей у вендоров похожи: базовые отчёты есть у всех. Различия, которые дороже всего обходятся при смене системы, в этих перечнях обычно не указаны.
| Критерий | Что проверить до внедрения | Чем оборачивается потом |
|---|---|---|
| Модель данных | Сеансы или события, можно ли задавать свои параметры | Переход с одной модели на другую обнуляет сравнимость с историей |
| Доступ к сырым данным | Есть ли выгрузка событий, а не только готовые отчёты | Без выгрузки любой нестандартный вопрос упирается в интерфейс |
| Глубина хранения | Как долго доступна детализация, а не только сводки | Годовые сравнения перестают строиться, когда история обрезается |
| Расходы из рекламных кабинетов | Подтягиваются автоматически или переносятся руками | Ручной перенос ломается первым при росте числа кампаний |
| Переносимость разметки | Насколько схема событий пригодна для другой системы | Привязка к вендору живёт в коде сайта, а не в договоре |
| Место хранения данных | Инфраструктура вендора или свой сервер | Смена требований к данным превращается в проект, а не в настройку |
Первые два критерия весят больше остальных: они определяют, сможете ли вы задать системе вопрос, которого нет в интерфейсе. Прочее правится настройкой, а эти два — только переездом.
В каком порядке внедрять
Порядок не произвольный: каждый следующий шаг опирается на данные предыдущего и без него считает мусор.
- Счётчик и корректные цели. Пока цели настроены неверно, любая надстройка наследует ошибку и умножает её.
- Единая разметка ссылок. Без дисциплины в UTM-метках источники схлопываются в «прочее», и разбирать нечего независимо от выбранной системы.
- Ручная сверка с CRM за один месяц. Заявки в аналитике против сделок в базе, сравнение построчно. Расхождение показывает, где теряются данные, и обходится дешевле любой интеграции.
- Коллтрекинг, если доля звонков значима. Подмена номера имеет смысл после того, как остальные источники размечены: иначе звонки лягут в то же «прочее», только дороже.
- Сквозная аналитика. Связка рекламы с деньгами собирается из уже проверенных кусков. Внедрять её первой — значит автоматизировать неизвестное качество данных.
Третий шаг пропускают чаще остальных, и именно он обычно снимает вопрос о смене системы: расхождение оказывается не в инструменте, а в том, что часть заявок не доходит до базы.
Почему два счётчика не покажут одинаковые числа
Расхождение между двумя системами на одном сайте — норма, а не признак поломки. Причины складываются, поэтому разрыв растёт вместе со сложностью трафика.
Разные единицы измерения. Сеанс с таймаутом и событие с идентификатором пользователя описывают одно и то же по-разному. Полного совпадения не будет даже теоретически.
Разная фильтрация роботов. Каждая система отсекает автоматический трафик своими правилами и не раскрывает их полностью.
Блокировщики и ограничения браузеров. Часть скриптов не выполняется, часть идентификаторов живёт ограниченное время. Потери неравномерны, потому что домены загрузки у систем разные.
Момент отправки данных. Один счётчик срабатывает при загрузке страницы, другой — после отрисовки. Быстрые уходы попадают в отчёты по-разному.
Кросс-устройство. Один человек с телефона и с ноутбука — два посетителя, пока он не авторизован. Правила связывания устройств у систем свои.
Конверсий в рекламном кабинете больше, чем в аналитике. Кабинет считает по своей модели и своему окну, аналитика — по последнему клику. Сравнивать имеет смысл динамику, а не итоги; модель атрибуции выбирают до сравнения, а не после.
Резкий рост прямых заходов. Обычно потеря разметки: редирект срезает параметры либо ссылки в рассылках и мессенджерах уходят без меток. Проверяется прогоном цепочки переходов до конечного URL.
Заявок в отчёте больше, чем в базе. Цель повешена на клик по кнопке, а не на успешную отправку формы, и считает в том числе неудачные попытки. Лечится переносом цели на ответ сервера.
После переустановки счётчика числа изменились. На сайте остались два экземпляра кода — например, в шаблоне и в менеджере тегов. Дубли видно по удвоенным просмотрам при неизменном числе визитов.
Отсюда практическое правило: одну систему назначают источником истины для решений, вторую держат ради срезов, которых в первой нет. Спор о том, чьи числа правильные, решения не имеет — точных нет ни у одной.
Спорное место
Индустрия склонна решать проблему недоверия к цифрам покупкой ещё одной системы. На практике вторая система чаще добавляет второй набор чисел, который не сходится с первым, и спор о том, какому верить, заменяет работу с данными.
Дешевле сначала довести до порядка одну: проверить корректность целей, убрать роботный трафик из базовой линии, свериться с CRM вручную за один месяц. В большинстве случаев после этого потребность в новом инструменте отпадает — оказывается, что данные были, а доверия к ним не было по другой причине.
Частые вопросы
Можно ли обойтись одной системой?
Зачем нужна сквозная аналитика, если есть Метрика?
Сколько стоит внедрение?
Источники
- Web analytics — обзор подходов и метрик — Wikipedia