Countly считает события, но на главный продуктовый вопрос не ответит

MAATRIX

Countly ставят, когда надоедает платить за Amplitude или Mixpanel и хочется свой self-hosted счётчик событий без лимитов по MTU (monthly tracked users). Первую неделю всё радует: SDK для мобильных платформ подключается быстро, дашборд красивый, события текут, retention считается. А потом продакт-менеджер спрашивает «а покажи, сколько пользователей, пришедших через referral в марте, дошли до оплаты через онбординг B, а не A» — и выясняется, что честно ответить на этот вопрос штатными средствами Community-версии не получится. Разберём, где Countly действительно хорош, а где придётся либо мириться с ограничениями, либо смотреть в сторону более тяжёлого инструмента.

Что такое Countly и зачем на него вообще смотрят

Countly — open-source платформа продуктовой и мобильной аналитики: Node.js-бэкенд, MongoDB как основное хранилище, SDK под iOS, Android, веб, Flutter, React Native, Unity и ещё десяток платформ. Есть две ветки: Community Edition (CE) — бесплатная, лицензируется как открытый код, разворачивается на своём сервере без ограничений по числу событий; и Enterprise Edition (EE) — платная, с расширенным набором аналитических инструментов и вендорской поддержкой. В этой статье речь именно про CE — то, что реально ставят на свой VPS ради экономии на подписке.

Исторически Countly вырос из мобильной аналитики (крэш-репортинг, push-уведомления, сессии приложений), и это чувствуется в архитектуре: инструмент отлично знает, как считать сессии, устройства и версии приложений, но продуктовая аналитика веб-SaaS с сложным поведением пользователей — для него скорее приложенная функция, чем изначальный фокус. У Amplitude, Mixpanel и self-hosted PostHog фокус ровно обратный — они выросли именно из задачи «понять поведение пользователя в продукте», и там ветвящиеся воронки и когорты — центральная фича, а не то, что дописали позже.

Разворачивается Countly обычно через Docker:

git clone https://github.com/Countly/countly-server.git
cd countly-server
docker compose up -d

Стек поднимает несколько контейнеров: countly-api и countly-dashboard (Node.js-процессы), countly-nginx как reverse proxy и mongodb как хранилище всех событий. Это заметно легче, чем self-hosted PostHog с его ClickHouse, Kafka и Redis — сравнение того, что тянет за собой такой стек, разобрано отдельно, и на фоне этого Countly выглядит бережливее к ресурсам. Но у этой лёгкости есть цена — MongoDB как единственная точка хранения не даёт той гибкости аналитических запросов, которую даёт колоночная база вроде ClickHouse; почему для событийной аналитики обычно выбирают именно колоночные СУБД, разобрано в сравнении ClickHouse и PostgreSQL — логика там применима и к MongoDB как к менее подходящему варианту под аналитические агрегации.

Что Countly действительно считает хорошо

Начнём с честной части — из коробки Community Edition закрывает базовый набор метрик уверенно и без танцев с бубном:

• Сессии и активные пользователи — DAU, WAU, MAU, длительность сессий, частота возвращений, всё это на готовых графиках без настройки.
• Retention-кривые — сколько пользователей вернулось на день 1, 7, 30 после первого визита, стандартная когорта «по дате первого события» без ручной сборки запроса.
• Крэш-репортинг для мобильных приложений — стектрейсы, группировка похожих крэшей, привязка к версии приложения и устройству. Это сильная сторона именно потому, что Countly исторически мобильный инструмент.
• Push-уведомления — встроенный модуль отправки пуш-кампаний с базовой сегментацией по платформе и версии приложения.
• География, устройства, версии ОС и приложения — стандартные срезы, которые не нужно настраивать отдельно.
• Кастомные события с базовыми параметрами (segments) — можно отправлять event: "purchase", segmentation: {product: "pro", price: 49} и видеть эти параметры в дашборде.

Для команды, которой нужно «видеть, сколько людей открывает приложение, сколько падает с ошибками и сколько возвращается через неделю» — этого достаточно, и достаточно с первого дня установки, без написания SQL-подобных запросов и без чтения документации по продвинутым модулям.

Когортный анализ: есть, но статичный

Здесь начинаются ограничения. В Countly CE когорты существуют, но они устроены иначе, чем у Amplitude, Mixpanel или PostHog, где когорта — это динамический, постоянно пересчитываемый набор пользователей по произвольному поведенческому критерию («сделал событие X за последние 30 дней и не сделал Y»).

В Countly когорта в базовом виде — это набор условий (по событиям, сессиям, значениям пользовательских свойств), который применяется один раз к текущим данным и не пересчитывается автоматически при изменении поведения пользователей в реальном времени с той же гибкостью цепочек условий, которую дают специализированные инструменты. Комбинировать несколько поведенческих условий с логикой «и не делал» или «делал в определённом порядке» через интерфейс CE неудобно или не полностью доступно — часть таких сценариев прямо относится к возможностям Enterprise-версии (модуль когорт там значительно богаче) или требует ручных запросов напрямую к MongoDB через агрегационный конвейер (aggregate pipeline) — а это уже не аналитика для продакт-менеджера, а работа для разработчика, читающего внутреннюю структуру коллекций Countly.

На практике это означает: вопрос «как ведут себя пользователи, пришедшие в январе, по сравнению с пришедшими в марте» Countly CE ответит через retention-отчёт по дате первого визита. А вопрос «как ведут себя пользователи, которые сделали событие А, но ни разу не сделали событие Б за 14 дней» — уже требует либо ручной выгрузки из MongoDB, либо перехода на Enterprise, либо смены инструмента.

Воронки без ветвления и без гибкой временной логики

Funnels в Countly CE — это линейная последовательность шагов: событие 1 → событие 2 → событие 3 → событие 4, и процент пользователей, дошедших до каждого шага. Это рабочий инструмент для простых сценариев вроде «регистрация → подтверждение почты → первый вход → первая покупка».

Чего в базовой воронке нет или сильно ограничено:

• Ветвление — нельзя построить воронку вида «после шага 2 пользователь идёт либо по пути А, либо по пути Б, и оба пути ведут к конверсии» одним отчётом. Каждую ветку приходится считать отдельной воронкой и сопоставлять руками.
• Произвольное окно между шагами по каждому шагу отдельно — гибкость настройки временных рамок между шагами воронки заметно уже, чем в инструментах, спроектированных вокруг funnel-анализа как основной фичи.
• Оверлей воронки на сегмент "на лету" — построить воронку и тут же наложить на неё срез «только пользователи из органического трафика, использующие Android» без пересборки отчёта не всегда получается тем же способом, что в PostHog или Amplitude, где сегментация и воронка — это один конструктор.
• Сравнение нескольких воронок бок о бок — visually сравнить конверсию до и после релиза в одном экране не входит в стандартный набор виджетов.

Для интернет-магазина с одним прямым путём «корзина → оформление → оплата» это не критично — линейная воронка честно покажет, на каком шаге теряются пользователи. Но если у продукта несколько путей к целевому действию (например, онбординг с выбором роли, где дальнейшие шаги расходятся) — Countly даст только часть картины, и её придётся собирать вручную из нескольких отчётов.

Сегментация: работает, но только по тому, что заложено заранее

Это самое важное практическое ограничение, и оно системное, а не «просто недоделанная фича». Countly сегментирует события по параметрам (segmentation), которые вы явно передали в момент отправки события через SDK. Если при отправке события purchase вы не передали параметр plan, то ретроспективно построить отчёт «конверсия в покупку по тарифным планам» без этого параметра нельзя — данные просто не сохранены в нужном разрезе.

Это отличается от подхода инструментов вроде PostHog или Amplitude, где событие хранится как более широкий набор свойств пользователя и сессии, а срез можно строить постфактум по almost любому сочетанию сохранённых свойств, включая свойства, которые вы решили анализировать спустя месяцы после запуска трекинга. В Countly такая гибкость есть только частично — через свойства пользователя (user properties), которые обновляются во времени и доступны шире, чем свойства конкретного события, но глубокая ad-hoc сегментация «покажи мне срез по любому сочетанию из десяти параметров» в CE не тот сценарий, для которого интерфейс проектировался. В Enterprise Edition для этого есть отдельный модуль (в документации Countly он называется Drill) — конструктор произвольных запросов по сырым данным, но это уже платная функциональность, а не часть self-hosted CE.

Практический вывод: если вы ставите Countly, продумывайте схему событий и параметров сегментации заранее и подробно — «догнать» аналитику новыми срезами задним числом здесь сложнее, чем в инструментах с более сырым хранением событий.

Для каких команд и задач Countly реально достаточно

Сведём в таблицу, где Countly CE закрывает задачу полностью, а где скорее создаёт иллюзию продуктовой аналитики:

Если у вас мобильное приложение или простой сервис, и главные вопросы — «сколько активных пользователей», «где падает приложение», «сколько возвращается через неделю» и «дошли ли до оплаты по известному линейному пути» — Countly CE закроет это на self-hosted сервере без подписки и без переплаты за события. Ресурсы для такого сценария скромные: Node.js-процессы и MongoDB на VPS с несколькими гигабайтами RAM держат десятки-сотни тысяч событий в день без проблем, конкретные цифры зависят от объёма событий и глубины хранимой истории, это стоит проверять на своей нагрузке, а не полагаться на общий ориентир.

Если же команда растёт до продуктовой аналитики в полном смысле — постоянные эксперименты, сложная сегментация пользователей по поведению, ветвящиеся сценарии использования продукта, вопрос «почему конкретный сегмент не конвертируется» — Countly CE перестаёт хватать, и дальше два пути: платить за Enterprise Edition (там часть описанных ограничений снята) либо переходить на инструмент, изначально спроектированный вокруг гибких событий и сегментации, например self-hosted PostHog. О том, как его развернуть и во что это обходится по ресурсам, есть отдельный разбор установки PostHog на Ubuntu 24.04, а если непонятно, нужна ли вам вообще такая тяжёлая продуктовая платформа или хватит более лёгкого счётчика — механику выбора между простой веб-аналитикой и полноценной продуктовой платформой разбирает статья «Umami или PostHog: что выгоднее и когда» — логика выбора там применима и к паре «Countly или более тяжёлый инструмент».

Частые вопросы