Firebase, Mixpanel или Amplitude: детальное сравнение систем аналитики для приложений

Обычно всё начинается с Firebase: он бесплатен, ставится за вечер, автоматически собирает базовые события жизненного цикла — и в первые недели кажется, что вопрос закрыт. Проблема приходит позже. Продукт растёт, маркетинг требует ответов на вопросы вроде «где именно отваливаются пользователи в онбординге» или «какая когорта показывает лучший retention на третий месяц», и тут выясняется: Firebase эти ответы даёт, но часто через ручную выгрузку в BigQuery. Mixpanel и Amplitude отдают значительную часть таких отчётов прямо в интерфейсе.

Я часто вижу эту развилку: разработчики упираются не столько в технический потолок Firebase, сколько в потолок привычного способа смотреть на данные. Затем начинают искать замену — и сталкиваются с тем, что Mixpanel и Amplitude считают не только события, но и активных пользователей за месяц. Эта логика ломает привычную модель «посчитаем, сколько логов мы отправляем, и поймём бюджет».

Сравнение Firebase, Mixpanel и Amplitude для мобильных приложений — не вопрос «что лучше». Это вопрос о том, на какой стадии находится продукт, кто в команде будет работать с данными и какие решения нужно принимать не по интуиции, а по поведению реальных пользователей.

Философия данных: разные задачи под одной вывеской

Firebase, Mixpanel и Amplitude часто ставят в один ряд, но у них изначально разные продуктовые цели — и это определяет всё остальное.

Firebase — прежде всего инфраструктурный слой экосистемы Google для мобильных приложений. Аналитика здесь лишь один из модулей рядом с Crashlytics, Remote Config, Cloud Messaging и A/B-тестами. Его задача — закрыть длинный хвост технических нужд разработчика, а не дать готовую продуктовую лабораторию из коробки.

Mixpanel и Amplitude исторически выросли из продуктовой аналитики. Их проектировали под вопросы, которые задают продакт-менеджеры, growth-команды и аналитики: где пользователь остановился в воронке, что отличает платящих от неплатящих, какая последовательность действий приводит к активации, почему одна когорта возвращается, а другая исчезает после первого запуска.

Их базовая единица — не просто событие как строка в логе, а пользователь с историей действий, свойствами и контекстом. Благодаря этому можно строить сложные сегменты без отдельной выгрузки, SQL-запроса и ожидания, пока аналитик соберёт новый отчёт.

Это не значит, что Firebase «слабее». Он просто отвечает на другой набор вопросов. Если команде нужны базовые счётчики, источники установок, ошибки, состояние релизов и общее понимание того, что приложение живо, Firebase закрывает потребность с запасом. Но если решения всё чаще принимаются на основании поведенческих паттернов, различие между системами становится принципиальным.

Firebase закрывает инфраструктурный минимум, но на продуктовые вопросы «почему» чаще приходится отвечать уже за пределами его стандартных отчётов.

Важный момент: специализированная аналитика не исправляет плохую событийную модель. Если команда называет события как попало, передаёт свойства без единого словаря, смешивает технические и бизнес-действия, Amplitude и Mixpanel просто дадут более красивый интерфейс для хаоса. Переход имеет смысл начинать не с установки нового SDK, а с ответа на простой вопрос: какие действия пользователя действительно меняют судьбу продукта?

Для подписочного сервиса это могут быть начало пробного периода, просмотр paywall, оформление подписки, отмена и возврат. Для маркетплейса — поиск, просмотр карточки, добавление в корзину, старт оплаты и успешный заказ. Для B2B-приложения — создание первого проекта, приглашение коллеги, подключение интеграции, первое регулярное действие. Всё остальное — вторично, пока эти точки не измеряются стабильно.

Ценовые ловушки и лимиты: что на самом деле бесплатно

Самая частая ошибка при выборе аналитики — ориентироваться только на слово free в описании тарифа. У всех трёх платформ бесплатные уровни есть, но ограничения работают по-разному. И момент, когда бесплатный режим перестаёт быть достаточным, у каждого продукта будет свой.

Сравнение бесплатных тарифов

У этой таблицы есть две строки, которые обычно читают слишком быстро.

Во-первых, Firebase действительно не ограничивает объём событий, но ограничивает число уникальных имён. Пятьсот типов для мобильного приложения на старте кажутся почти бесконечным запасом. Однако в продукте с разветвлённой событийной моделью, множеством экранов, экспериментами, параметризованными действиями и несколькими командами этот лимит постепенно становится реальным архитектурным ограничением. Особенно если события плодят под каждый частный сценарий вместо того, чтобы разумно использовать параметры.

Во-вторых, лимит Amplitude Starter — это 10 000 MTU, то есть уникальных активных пользователей за месяц. Его нельзя честно пересчитать в конкретный DAU. Приложение с одинаковым средним дневным числом пользователей может дать совершенно разное число MTU: в одном случае аудитория возвращается почти каждый день, в другом — каждый день приходят новые люди и быстро уходят. Поэтому DAU в 350 или 400 человек сам по себе ещё не означает, что бесплатный месячный порог уже пройден. Смотреть нужно именно на число уникальных пользователей за расчётный месяц и на темп притока новой аудитории.

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

Что происходит при переходе на платный тариф

Mixpanel и Amplitude используют принципиально разные модели тарификации, и это сбивает с толку команды, привыкшие считать только события.

Mixpanel на тарифе Growth начинается с условно бесплатного первого миллиона событий, а дальше цена растёт линейно — около 0,28 доллара за каждую дополнительную тысячу событий. Для приложения с 3 млн событий в месяц это порядка 560 долларов сверх базового миллиона. Предсказуемость счёта здесь становится главным аргументом: расход можно примерно прикинуть по собственному дашборду потребления, не дожидаясь неприятного письма в конце месяца.

Но эта предсказуемость зависит от дисциплины трекинга. Если команда начинает отправлять в Mixpanel каждое техническое действие, частые обновления экрана, необработанные события скролла и служебные статусы, счёт раздувается быстро — а пользы в отчётах не прибавляется. Mixpanel выгоден не тем, кто собирает максимум телеметрии, а тем, кто умеет отличать продуктовый сигнал от шума.

Amplitude считает по модели MTU или по объёму событий — в зависимости от того, какой лимит будет достигнут раньше. Тариф Plus стоит от 49 долларов в месяц при годовой оплате и расширяет лимиты до 300 000 MTU либо 25 миллионов событий в месяц. Это уже другая ценовая категория, зато у Amplitude есть козырь, о котором часто забывают: программа Startup Scholarship даёт стартапам с финансированием менее 10 млн долларов и штатом до 20 сотрудников один год бесплатного доступа к тарифу Growth.

Для команды, которая только подняла раунд и пытается быстро нащупать product-market fit, это не мелкая скидка, а возможность не экономить на продуктовых данных в самый нервный период роста. Правда, рассчитывать всю стратегию аналитики на программу поддержки всё равно не стоит: она помогает начать, но не отменяет вопроса, что будет с данными, процессами и бюджетом после льготного года.

MTU — это не сумма дневной аудитории. В Amplitude цену определяет число уникальных пользователей за месяц, а не один красивый показатель DAU.

Техническая интеграция: размер SDK и влияние на запуск приложения

Для продуктовой команды аналитика часто выглядит как «ещё одна зависимость в проекте». Но за этой формулировкой скрывается вполне практическая цена: размер SDK, влияние на холодный старт, сетевые вызовы, согласованность идентификаторов и необходимость поддерживать трекинг после каждого изменения интерфейса.

По данным замеров производительности iOS SDK, Mixpanel почти на 75% меньше Firebase по объёму бинарного кода. Разница ощутимая, и на проектах, где размер приложения критичен — например, на рынках с медленным интернетом или ограниченным мобильным трафиком, — это реальный аргумент в пользу Mixpanel.

Однако есть нюанс, который часто теряется в презентациях. Сам по себе меньший бинарник не превращает приложение в молнию. Время холодного старта зависит не только от веса SDK, но и от инициализации, очереди событий, сетевых операций, числа подключённых сервисов и того, что именно команда делает в первой секунде после запуска. Менять Firebase на Mixpanel исключительно в надежде «ускорить старт» не стоит: пользователь вряд ли почувствует разницу, если проблема лежит в тяжёлом первом экране, синхронной загрузке конфигурации или неудачной архитектуре приложения.

Что действительно важно — так это устройство событийной схемы.

Firebase автоматически собирает базовые события жизненного цикла: открытия, сессии, обновления. Для MVP можно вообще не писать много трекинг-кода: подключить SDK, проверить дашборд и получить первичную картину. Mixpanel и Amplitude требуют более явной работы. На каждом значимом действии нужно вызвать трекинг-функцию, передать свойства, определить пользовательский идентификатор, а после логина корректно склеить анонимную историю с известным аккаунтом.

Это даёт контроль, но вместе с ним — ответственность.

На практике команды часто переезжают с Firebase на Mixpanel в погоне за гибкостью, а через квартал обнаруживают, что часть ключевых событий не отправляется. Причина почти всегда прозаична: после рефакторинга изменился экран, сценарий стал состоять из нескольких шагов, а вызов аналитики забыли перенести. Дашборды при этом продолжают существовать и выглядят вполне убедительно. Просто показывают не весь продукт.

Поэтому миграция между платформами — не «заменить одну строку import на другую». Это отдельный проект, в котором нужно:

1. Инвентаризировать все события и выкинуть то, что не отвечает ни на один продуктовый вопрос.

2. Зафиксировать единый нейминг: что считается просмотром, стартом, успехом, отменой, ошибкой и повторным действием.

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

4. Настроить параллельную отправку в старую и новую систему на период валидации.

5. Сверить ключевые цифры не только в конце месяца, но и на конкретных тестовых сценариях: новый пользователь, логин, покупка, отмена, переустановка, смена устройства.

Особенно болезненный участок — идентификация. Если пользователь сначала действует анонимно, затем авторизуется, а потом выходит из аккаунта, платформы должны корректно понимать, где одна история, а где другая. Ошибка здесь способна искусственно раздуть число пользователей, поломать retention и сделать бессмысленной сегментацию по платящим аккаунтам.

Глубина инсайтов: воронки, когорты и путь пользователя

Именно здесь разница между платформами становится по-настоящему ощутимой. Mixpanel и Amplitude из коробки дают инструменты, ради которых продуктовые команды обычно и строят отдельную аналитическую инфраструктуру.

Воронки конверсии в Mixpanel и Amplitude строятся в визуальном интерфейсе без SQL и без выгрузки данных. Команда задаёт последовательность шагов, платформа считает конверсию между ними, показывает, где отваливается основная масса пользователей, и позволяет сегментировать воронку по свойствам: платформе, стране, источнику установки, версии приложения, типу подписки.

В Firebase аналогичный анализ возможен, но обычно требует либо ручной работы в BigQuery, то есть SQL-запроса к сырым логам, либо связки с GA4. Это не катастрофа для команды с сильным аналитиком. Более того, иногда именно SQL даёт нужную точность. Но для ежедневной продуктовой работы разница огромна: один вариант — собрать ответ за несколько минут на встрече, другой — поставить задачу, дождаться запроса, обсудить трактовку результата и вернуться к гипотезе через пару дней.

Когортный анализ и retention-кривые — вторая причина смотреть в сторону специализированных систем. Amplitude исторически считается сильным инструментом в этой области. Retention Analysis с тепловой картой возвратов по дням, неделям и произвольным интервалам — тот тип отчёта, который продакт-менеджеры приносят на growth-сессии и в разговоры с инвесторами.

Mixpanel не отстаёт. Встроенный конструктор когорт позволяет задавать условия сегментации прямо в интерфейсе отчёта, а гибкие формулы и фильтры помогают собирать разрезы от простого «retention по неделям для пользователей из конкретного канала» до многоступенчатых условий с комбинацией свойств и действий.

Однако и здесь есть ловушка. Retention нельзя улучшить, просто выбрав платформу с красивее нарисованной тепловой картой. Нужно заранее определить, какое действие считается возвращением. Открытие приложения? Просмотр каталога? Создание задачи? Успешное завершение ключевого сценария? Для новостного приложения и банковского сервиса это будут разные определения. Если в отчёт попадает любое открытие, команда может радоваться «возвратам», хотя пользователи заходят только за push-уведомлением и тут же закрывают экран.

Пути пользователя — третий класс задач, где Mixpanel и Amplitude экономят недели работы. Анализ путей показывает, какими маршрутами люди реально двигаются по приложению, какие ветки становятся тупиковыми, где возникают неожиданные прыжки между разделами. Это особенно полезно, когда команда уверена в одном пользовательском сценарии, а реальные данные показывают другой.

В Firebase такой анализ можно собрать через BigQuery Export и собственный pipeline обработки. Для крупной компании с аналитиками и data-инженерами это нормальный путь. Для небольшой продуктовой команды — часто слишком дорогой по времени. Не в деньгах SDK, а в часах людей, которые вместо проверки гипотезы обслуживают инфраструктуру вокруг неё.

Отдельно стоит упомянуть эксперименты. Amplitude предлагает встроенный Experiment-раздел, который позволяет запускать A/B-тесты и видеть результаты в контексте поведенческих метрик — без необходимости тащить данные в отдельный инструмент вроде Optimizely или LaunchDarkly. Firebase отвечает здесь через Remote Config с A/B-тестированием, но глубина анализа результатов ограничена стандартными отчётами. Для сложных гипотез и нестандартных сегментов данные всё равно приходится уносить в BigQuery.

Доступ к сырым данным: сильная сторона Firebase

У Firebase есть архитектурное преимущество, которое часто недооценивают: интеграция с BigQuery бесплатна и выгружает сырые события в реальном времени. Это означает, что команда с аналитиком, уверенно владеющим SQL, может построить любой нестандартный отчёт, недоступный в интерфейсе Firebase, и соединить продуктовые события с биллингом, CRM, поддержкой или внутренними данными.

Например, можно сопоставить поведение в приложении с фактами возврата средств, нагрузкой на службу поддержки или реальной маржинальностью заказа. В стандартной продуктовой аналитике такие связи часто остаются за кадром: она хорошо отвечает на вопрос «что делают пользователи», но не всегда знает всё о том, что происходит с ними после события оплаты или обращения в поддержку.

Mixpanel и Amplitude тоже позволяют выгружать сырые данные через API, но с ограничениями по частоте запросов. Для серьёзного data-инжиниринга это означает дополнительную настройку и стабильный pipeline. Специализированная платформа не отменяет хранилище данных — она просто даёт быстрый слой для повседневной работы с продуктом.

Есть и обратная сторона Firebase. По умолчанию события в стандартных отчётах хранятся 60 дней. Для долгосрочного анализа BigQuery-выгрузка проблему решает, но BigQuery — отдельный сервис со своей стоимостью. При высоком объёме событий хранение и регулярные запросы могут в итоге обойтись дороже, чем подписка на Mixpanel или Amplitude.

То есть Firebase не обязательно «бесплатнее». Он часто переносит стоимость из строки «лицензия на аналитику» в строки «работа аналитика», «поддержка витрин», «BigQuery» и «время команды на разбор очередного запроса».

Критерии выбора: на какой стадии что подходит

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

Firebase остаётся оптимальным выбором, если приложение находится на стадии MVP или раннего роста, у команды нет отдельного продуктового аналитика, а основные вопросы звучат так: «сколько у нас активных пользователей», «откуда они приходят», «какая версия приложения падает» и «работает ли новый релиз». Бесплатный объём событий и автоматический сбор базовых метрик позволяют закрыть эти потребности без лишней инфраструктуры. Дополнительный аргумент — экосистема: Crashlytics, Remote Config, push через Cloud Messaging уже находятся рядом и не требуют отдельного контракта с новым поставщиком.

Mixpanel имеет смысл подключать, когда у продукта появляется выраженная воронка: онбординг из нескольких шагов, регистрация, первая покупка, активация подписки, возврат после пробного периода. Это момент, когда вопрос «сколько пользователей пришло» перестаёт быть главным, а вопрос «на каком шаге и почему мы теряем людей» начинает влиять на выручку. Тариф Growth с линейной моделью по событиям хорошо ложится на проекты, которые понимают собственную событийную нагрузку и умеют не отправлять в аналитику технический мусор.

Amplitude оправдан, когда команда живёт в парадигме data-driven решений: строит модель когортного retention, регулярно запускает эксперименты, сравнивает сегменты и смотрит на поведение во времени, а не только на конверсию одной воронки. Startup Scholarship делает Amplitude особенно интересным для стартапов на ранних раундах: можно получить полноценную продуктовую аналитику в период, когда ошибочный вывод о поведении пользователей дороже самой подписки.

Firebase вместе с Mixpanel или Amplitude — тоже рабочая конфигурация, и в зрелых продуктах она встречается постоянно. Firebase остаётся инфраструктурным слоем: краши, атрибуция, push, техническая телеметрия. Специализированный инструмент берёт на себя бизнес-воронки, продуктовые действия, когорты и сегментацию.

Дублирования можно избежать, если заранее определить единого мастера данных для каждого типа метрик. В Firebase, например, остаются технические события и показатели стабильности. В Mixpanel или Amplitude — действия, по которым команда принимает продуктовые решения. Самое опасное состояние — когда одна и та же метрика существует в двух системах, считается чуть по-разному, а на встрече каждый выбирает цифру, которая больше нравится его гипотезе.

Что в итоге

Сравнение Firebase, Mixpanel и Amplitude для мобильных приложений стоит начинать не с таблицы тарифов и не с размера SDK. Сначала нужно понять, насколько часто команда будет задавать продуктовые вопросы, на которые нельзя ответить одним счётчиком установок или сессий.

Firebase остаётся стандартом де-факто для инфраструктурной аналитики. Его бесплатный тариф, автоматический сбор базовых событий и связка с остальными сервисами Google делают его естественной точкой старта. Но когда SQL-запросы в BigQuery начинают отнимать у продакт-менеджера больше времени, чем работа с самими гипотезами, бесплатность Firebase перестаёт быть главным преимуществом.

Между Mixpanel и Amplitude выбор обычно определяется двумя вещами. Первая — модель тарификации: события у Mixpanel, уникальные активные пользователи за месяц и лимиты по событиям у Amplitude. Вторая — стиль работы команды: Mixpanel хорош там, где нужны гибкие формулы, сегментация и понятный контроль потребления событий; Amplitude особенно силён в когортном анализе, retention и экспериментальной культуре.

Переходить на платные платформы стоит не по достижении «магического» DAU и не потому, что конкуренты используют модный инструмент. Переход наступает в тот момент, когда продукту нужны регулярные ответы о поведении пользователей — быстрые, проверяемые и доступные не только одному человеку, который умеет писать SQL.