Dilshat Rakhimov
July 2026 · 12 min read
Вопрос всегда приходит в одной и той же форме: «у нас уже есть GA4 — нам правда нужен Amplitude?». И это неправильный вопрос. Во-первых, эти два инструмента отвечают на разные вопросы. Во-вторых, ни в одном суперапп-проекте, который я вёл, инструмент не был самой дорогой частью. Дорогой была таксономия.
Я делал это с обеих сторон. Разбирал Amplitude в страховом бизнесе банка, где в систему летело 200+ типов событий с 18+ префиксами в названиях, и писал memo по выбору инструмента для финтеха, который ушёл с Amplitude из-за цены и искал, куда приземлиться. Ни один из проектов не решался сравнением фич. Оба решались тремя вещами: сколько событий реально порождает продукт, где физически должны лежать данные и кто после запуска будет владеть схемой.
Ниже — честная версия: где GA4 действительно ломается на масштабе суперприложения, за что на самом деле берёт деньги Amplitude и как понять, на какой стороне этой границы вы находитесь.

Они отвечают на разные вопросы, и разница не тонкая
GA4 — это инструмент про привлечение и сессии с прикрученной спереди рекламной интеграцией. Он отлично отвечает на «какая кампания, какой канал, какая посадочная, сколько это стоило» — и это единственный инструмент в сравнении, который нативно кормит биддинг Google Ads. При заметной доле бюджета в App-кампаниях и Performance Max это немаловажно.
Amplitude — это user-centric хранилище событий, в интерфейс которого зашиты вопросы продуктовой команды: воронки с произвольным порядком шагов, кривые retention, поведенческие когорты, path analysis. Его единица мышления — человек, который двигается через продукт неделями, а не сессия с источником.
В суперприложении оба вопроса живут одновременно, и задают их разные люди. Маркетингу нужна правда по каналам. Продукту нужно понять, почему на одном шаге урегулирования происходит 115 000 ошибок в месяц. Это не один и тот же запрос, и попытка закрыть оба одним инструментом заканчивается предсказуемо: GA4-ресурс, который никто в продукте не открывает, и проект в Amplitude, которому не верит маркетинг.
Решение не в том, GA4 или Amplitude. Решение в том, окупает ли второй инструмент ту работу по таксономии, которую он же и потребует.
Где GA4 реально ломается на масштабе суперприложения
Не в интерфейсе — в квотах. Это лимиты стандартного ресурса, и каждый из них задокументирован:
| Лимит | GA4 стандартный | GA4 360 |
|---|---|---|
| Кастомные параметры уровня события | 50 | 125 |
| Кастомные параметры уровня пользователя | 25 | 100 |
| Параметров на событие | 25 | 100 |
| Аудитории | 100 | 400 |
| Хранение данных | до 14 месяцев | до 50 месяцев |
| Ежедневный экспорт в BigQuery | 1 млн событий/сутки | миллиарды/сутки |
| Порог семплирования в исследованиях | 10 млн событий на запрос | 1 млрд событий на запрос |
Теперь приложите строку про кастомные параметры к реальной схеме суперприложения. Таксономия, которую я собрал для страховой линейки банка, стоит на обязательном product_type с 23 значениями плюс примерно 16 плоских свойств, по которым аналитики реально сегментируют: screen_name, step_number, step_name, error_type, error_severity, error_source, payment_method и так далее. В GA4 каждое свойство, по которому вы хотите разложить отчёт, должно быть зарегистрировано как один из 50 кастомных параметров события. Одна продуктовая линейка съедает треть бюджета. В суперприложении их тринадцать.
Дальше объём. На том же ресурсе только топовое событие давало 11,2 млн просмотров за 30 дней, а api_error — ещё 4,5 млн. Весь поток спокойно уходит за 20 млн событий в месяц. Бесплатный экспорт в BigQuery ограничен 1 миллионом событий в сутки — то есть на стандартном ресурсе сырой экспорт, ровно та часть GA4, которая на таком масштабе и нужна, тихо перестаёт быть полным. У потокового экспорта лимита по объёму нет, но он тарифицируется по гигабайтам и не даёт тех же суточных таблиц.
И кардинальность. Любое измерение, которое уходит вширь — полные URL, идентификаторы, свободный текст ошибок — после превышения суточного лимита уникальных значений схлопывается в строку (other). В продукте, где интересный вопрос звучит как «какая именно из 80 ошибок загрузки фото выстрелила», вы теряете ровно те данные, ради которых пришли.
GA4 360 снимает все эти ограничения. Он же не продаётся по опубликованному самообслуживаемому прайсу; на рынке фигурирует старт порядка $50 тыс./год, дальше по переговорам. То есть честная формулировка «GA4 бесплатный» звучит так: GA4 бесплатный ровно до момента, когда объём событий перестаёт делать из него базу данных, — а лечится это дороже, чем тариф Amplitude, которого вы избегали.
За что на самом деле берёт деньги Amplitude
Публичный прайсинг Amplitude перешёл на объём событий вместо отслеживаемых пользователей. На июль 2026 бесплатный тариф — 2 млн событий/мес, Plus стартует с $0 (первые 2 млн событий бесплатно) и масштабируется до 70 млн событий, Growth и Enterprise считаются по объёму. Места (seats) не ограничены ни на одном тарифе, а расширения — session replay, эксперименты, guides — идут отдельными пакетами поверх платформенного тарифа.
Отсюда два следствия, которые важнее ценника.
Первое: ваш счёт — это ваша таксономия. В доставшемся мне проекте летело 30+ вариаций одного платёжного события, generic-событие payment на 154 тыс./мес, случайное revenue_amount на 94 тыс./мес и порядка 80 отдельных событий на один шаг загрузки фото. Схлопывание этого хозяйства в 35 событий — одно screen_viewed, одно technical_error с severity и source в свойствах, одно payment_completed, отправляемое сервером после колбэка платёжного шлюза с полями Revenue API внутри — сильно урезало счётчик событий и сделало отчёты отвечаемыми. На event-based прайсинге гигиена схемы — это статья расходов, а не эстетика.

Второе: ценовой обрыв реален, и лезть на него нужно не всегда. Казахстанский финтех автокредитования, для которого я писал memo по выбору, уже ушёл с Amplitude из-за цены. 22 000 MAU, 40–60 событий на пользователя в месяц — то есть примерно 0,9–1,3 млн событий в месяц. По меркам суперприложения — мало. Рекомендация была не «вернуться на тариф побольше», а пересобрать выбор с нуля, потому что доминировали два ограничения: жёсткий нулевой бюджет и вопрос резидентности данных, от которого регулируемый кредитор в Казахстане отмахнуться не может. В итоге победил self-hosted PostHog (на таком объёме — одна VM; product analytics, session replay и feature flags в одной коробке; данные физически в стране), а запасным вариантом без DevOps шёл бесплатный тариф Mixpanel. Это рекомендация, а не завершённая миграция, — но логика показательна: при 1 млн событий в месяц и требовании к резидентности правильным ответом не был ни GA4, ни Amplitude.
Что бы вы ни выбрали, смену вендора переживает схема. Инструменты меняются. Чистая таксономия из 35 событий с плоскими свойствами переезжает за неделю; каша из 200 событий не переезжает никогда.
Ошибка, которая дороже любой из лицензий
Отправить одну и ту же сломанную таксономию в оба инструмента.
Я заходил в проекты, где GA4 и Amplitude получали каждый свой самописный поток событий: разные названия для одного действия пользователя, вложенные объекты свойств (data.event_info.utm.*), по которым нормально не сегментируешь ни там, ни там, и ИИН в сырых свойствах событий открытым текстом. Дальше начинаются невыигрываемые встречи по сверке цифр — потому что версии правды нет, есть два инструмента, которые спорят друг с другом.
Лечится это не инструментом, а четырьмя решениями, принятыми один раз:
- Одна схема, плоские свойства.
utm_sourceна корневом уровне, а неdata.event_info.utm.source. Всё, что маршрутизирует отчёты —product_type,step_name,is_success, — полноценное свойство с объявленным типом. - Деньги — server-side.
payment_completedотправляется бэкендом после колбэка шлюза, с ключом идемпотентности, и никогда из браузера. Это единственное платёжное событие, и оно несёт revenue. - Никакого PII в аналитике. Аналитика получает UUID. CRM хранит связку UUID → личность. Джойны происходят в BI под ролевым доступом. Это то, что я внедрял, и то, что реально проверяют регуляторы.
- Governance включён. Контроль плановой схемы, валидация типов свойств, алерты на незапланированные события и автоматическая блокировка полей, попадающих под PII-паттерн. В Amplitude это есть из коробки; в GA4 это аппроксимируется процессом ревью в тег-менеджере и линтом.
Сделайте эти четыре вещи — и вопрос вендора резко уменьшится в размерах. Ровно поэтому я всегда начинаю спор с таксономии.
Что выбирать и когда
GA4 в одиночку достаточно, когда: вы web-first или Google-Ads-first, объём — меньше примерно миллиона событий в сутки, а вопросы, которые задают, — это вопросы про канал, кампанию и посадочную. Если никто в продукте не просит retention D7 по когортам, второй инструмент — это подписка, которую вы будете полтора года оправдывать. BigQuery под ним включите всё равно, в первый же день.
GA4 + Amplitude, когда: у вас мультипродукт (суперприложение — по определению), продуктовая команда живёт в воронках и retention ежедневно, нужны когорты в разрезе product_type по десятку линеек — и, без вариантов, назначен владелец схемы событий. GA4 остаётся с рекламной интеграцией и правдой по каналам; Amplitude берёт на себя продуктовые вопросы. Оба кормят хранилище.
Ни то ни другое, смотрите в третью сторону, когда: бюджет жёстко ограничен, или данные обязаны оставаться в конкретной юрисдикции, или вы хотите product analytics плюс session replay плюс feature flags без трёх контрактов. Это кейс self-hosted PostHog, и на 20–100 тыс. MAU он живёт на одной виртуалке. Бесплатный тариф Mixpanel — вариант с меньшими усилиями, если готовы принять хранение данных в США.
И в любом из этих случаев: снизу стоит хранилище. GA4 экспортируется в BigQuery, Amplitude выгружается туда же, MMP кладёт рядом сырые данные, и арбитром в любом споре становится SQL-таблица, которой владеете вы, а не дашборд вендора. Это не вопрос вкуса — это то, что сохраняет заменяемость всего стека.
Итог
GA4 бесплатен ровно до тех пор, пока объём суперприложения не превращает его квоты в вашу архитектуру: 50 кастомных параметров события против каталога из 23 продуктов, лимит бесплатного экспорта в BigQuery в 1 млн событий в сутки против потока в 20 млн в месяц и строка (other), съедающая именно то высококардинальное поле, которое вы расследовали. Amplitude отвечает на продуктовые вопросы, на которые GA4 структурно не отвечает, и тарифицируется по событиям — так что хозяйство из 200 событий это одновременно и плохой набор отчётов, и больший счёт, чем 35-событийная версия того же продукта. Сначала таксономия: это единственный актив в этом сравнении, который переживёт смену мнения об инструменте.
Если непонятно, на какой вы стороне границы, три числа решают вопрос быстрее любого демо вендора: реальный объём событий в месяц, сколько бюджета кастомных параметров уже потрачено и сколько вариаций платёжного события прямо сейчас живёт в проде. Этот подсчёт — первый час трекинг-аудита, и сделать его можно самому, до разговора с кем бы то ни было.
Источники
- Лимиты GA4: стандартный ресурс и Analytics 360 — кастомные параметры, аудитории, хранение, экспорт в BigQuery, пороги семплирования
- Лимиты сбора данных GA4 — 25 параметров на событие, 100 тыс. событий на пользователя в сутки
- Лимиты экспорта GA4 в BigQuery — 1 млн событий в сутки на стандартном ресурсе, тарификация потокового экспорта
- Прайсинг Amplitude — бесплатные 2 млн событий/мес, Plus до 70 млн событий, пакеты расширений (проверено в июле 2026)
