Dilshat Rakhimov
July 2026 · 12 min read

Большинство разговоров «какой MMP выбрать» должны начинаться на один вопрос раньше: а нужен ли он вообще? Firebase бесплатен, он уже стоит в приложении, и для честно Google-only микса он свою работу делает. Я же вёл и противоположный кейс — корпоративное банковское приложение, где всё revenue-событие происходило в core banking спустя часы после установки, и ни один SDK на свете его бы не увидел.

Между этими полюсами есть граница. Ниже — где я нахожу её на практике и чем на самом деле отличаются AppsFlyer и Adjust, когда сравнение фич закончилось.

AppsFlyer vs Adjust vs только Firebase cover

Что реально даёт только Firebase

Больше, чем принято считать. Google Analytics for Firebase бесплатно собирает in-app события в объёмах, за которые в другом месте пришлось бы платить, выгружает сырые события в BigQuery, атрибуцирует установки на Android через Play Install Referrer и — самое важное — нативно кормит App-кампании Google Ads, включая SKAdNetwork-часть iOS для google-трафика. Если ваше привлечение — это Google, петля замкнута: без лицензионных расходов и с сырыми данными в вашем хранилище.

Чего он не делает — так это не арбитрирует. Meta, TikTok, AppLovin, Unity и остальные не шлют свои install-постбэки в Firebase; они шлют их сертифицированным измерительным партнёрам. Поэтому как только появляется вторая платная сеть, Firebase по-прежнему расскажет, что произошло внутри приложения, но не скажет, кому засчитать установку, — и не рассудит случай, когда на неё претендуют две сети сразу. Ещё в нём нет антифрод-слоя, инфраструктуры диплинков и кросс-сетевого управления conversion values для SKAN, которое продают MMP.

Честное резюме: Firebase — очень хороший Google-only слой атрибуции и отличное хранилище продуктовых событий. Измерительным партнёром он не является, и никакой настройкой это не меняется.

Три теста на то, нужен ли вам MMP

Тест 1: больше одной платной сети. С одной сетью её собственной отчётности плюс Firebase достаточно. С тремя нужен единый дедуплицированный реестр установок и кто-то, чья бизнес-модель зависит от нейтральности между сетями. Эта нейтральность — большая часть того, что вы покупаете.

Тест 2: iOS на объёме. SKAN заставляет закодировать воронку в число от 0 до 63, с отложенными и рандомизированными постбэками. Кто-то должен централизованно владеть маппингом conversion values, расшифровывать его и джойнить с расходом — механику я разбирал в статье про SKAdNetwork. Делать это самому из сырых постбэков можно. На практике никто не делает, потому что CV-карта должна быть согласована сразу по всем сетям.

Тест 3 — и для финансовых продуктов решает именно он: деньги случаются вне устройства?

В банковском приложении SDK видит поданную заявку. Он не видит выдачу кредита, выпуск карты и открытие депозита, потому что это происходит в core banking — иногда через несколько дней, иногда в отделении. В результате в дашборде MMP лежат заявки, рекламные платформы оптимизируются на заявки — и так вы покупаете огромные объёмы дешёвого неквалифицированного трафика, который не превращается ни в одну выдачу.

Для корпоративного банковского приложения я закрывал это server-to-server пайплайном. Форма решения:

Мобильное приложение (Flutter) → AppsFlyer SDK → appsflyer_id ↓ снимается при логине, сохраняется в карточке клиента Core banking: loan_disbursed / card_issued / deposit_opened ↓ backend worker POST https://api2.appsflyer.com/inappevent/{app_id} af_revenue = сумма выдачи, af_order_id = application_id ↓ Дашборд MMP: полная воронка с реальными деньгами

Держат эту конструкцию три детали. appsflyer_id снимается при логине и кладётся в карточку клиента, потому что бэкенду он понадобится через часы, когда контекста SDK давно нет. af_order_id равен идентификатору заявки, чтобы MMP дедуплицировал ретраи, — плюс флаг отправки в строке выдачи, чтобы переигранная джоба не посчитала событие дважды. И события разделены по каналу завершения — loan_disbursed против loan_disbursed_office, — чтобы онлайн и отделения можно было оптимизировать раздельно, а не усреднять в одно бессмысленное число.

Суть тут не в эндпоинте. Суть в том, что MMP отрабатывает свои деньги как точка стыковки: единственная система, которая уже держит клик, установку и устройство, готова принять revenue-событие от вашего бэкенда и раздать результат всем рекламным сетям. Только Firebase такую передачу для не-Google сетей принять не может.

События устройства и бэкенда сходятся в одной точке стыковки и расходятся по рекламным сетям

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

AppsFlyer vs Adjust: различия, которые вылезли в реальной работе

Оба умеют атрибуцию, диплинки, SKAN 4.0, антифрод и выгрузку сырых данных. Таблица фич их не разведёт. У меня их развели три вещи.

Форма прайсинга и то, откуда на самом деле приходит счёт. AppsFlyer публикует цифры: бесплатный тариф Zero с welcome-пакетом на 12 000 конверсий в первый год и тариф Growth, где конверсии сверх этих 12K стоят $0,07 за штуку. Чего в заголовке нет: Protect360 (антифрод), Data Locker (сырые данные), сегментация аудиторий и analytics API — это отдельно оплачиваемые дополнения, а для банка антифрод и выгрузка сырых данных не «приятные опции», а причина, по которой MMP вообще покупали. Считайте итог с дополнениями, а не по ставке за конверсию. Adjust сопоставимой публичной ставки не показывает — на июль 2026 их страница прайсинга публичных цифр мне не отдала, то есть это котировка под контракт. Это не упрёк: просто Adjust нельзя посчитать по статье в блоге, а AppsFlyer — можно.

Контракт server-side событий, который определяет, кто может выкатить новое событие. S2S-эндпоинт AppsFlyer принимает appsflyer_id, произвольную строку eventName и JSON eventValue; добавление нового бэкенд-события — это изменение только на бэкенде. S2S API Adjust требует s2s=1, app_token и event_token, который сначала нужно создать в дашборде Adjust, плюс рекламный идентификатор (idfa/gps_adid) или собственный adid для опознания устройства. Функционально это эквивалентно, операционно — нет: в Adjust под каждое новое серверное событие нужен админ дашборда до того, как поедет код, а бэкенд обязан хранить рекламный идентификатор, что для банка тяжелее, чем хранить выданный SDK id. Если ваш роадмап звучит как «будем добавлять revenue-события по мере того, как их отдаёт команда core banking», эта разница всплывает каждый спринт.

Поведение в суперприложении и WebView. Оба отдают нативный getAttribution() с данными кампании по текущей установке — это тот крючок, через который я протаскивал рекламную атрибуцию внутрь WebView; паттерн разобран в статье про атрибуцию в WebView. Ни один вендор в документации не предупредит про режим отказа, который реально стоит денег: проставлять эту атрибуцию на каждый запуск WebView, включая те, что пришли из собственного меню суперприложения. Сделаете так — и уже авторизованные пользователи с конверсией под 80% попадут в платный канал, цифры платного сегмента станут фикцией, а алгоритм начнёт оптимизироваться на людей, которых реклама никогда не приводила. Гейт «атрибуция только на запусках рекламного происхождения» — ваша работа в обоих инструментах.

Чего не починит ни один MMP

Стоит сказать прямо, потому что продают это ровно наоборот:

  • Revenue, которое живёт в core banking. S2S-пайплайн выше всё равно кто-то должен написать. MMP принимает; он не лезет забирать.
  • Мёртвый пиксель в WebView. Если большинство платежей проходит в WebView, где браузерный рекламный стек выключен, это задача server-side CAPI, а не MMP.
  • Смешивание трафика суперприложения. Ни один вендор не знает, какая из ваших точек входа является рекламной. Это определяете вы.
  • Вашу таксономию событий. MMP с 200 несогласованно названными событиями ровно так же бесполезен, как любой другой инструмент с 200 несогласованно названными событиями.

Что выбирать и когда

Только Firebase, когда: Google Ads — фактически весь ваш платный микс, вы Android-тяжёлые, revenue-события происходят в приложении, где их видит SDK, и фрод-экспозиция низкая. Вы сохраняете бесплатный экспорт в BigQuery и не теряете ничего, чем реально пользовались. Пересмотреть — в момент, когда у второй сети появится бюджетная строка.

AppsFlyer, когда: закупаетесь в нескольких сетях, нужен антифрод уровня Protect360, нужны сырые данные в собственном хранилище и хочется публичной ставки за конверсию, по которой можно построить прогноз. И ещё — когда бэкенд-команда будет регулярно слать server-side revenue-события: контракт S2S здесь легче в эксплуатации.

Adjust, когда: вы предпочитаете один согласованный контракт вместо базовой ставки плюс столбца дополнений, требования к SKAN-отчётности и сырым данным прямолинейные, а набор событий достаточно стабилен, чтобы заводить event tokens в дашборде не было трением. Сначала получите котировку — сравнить иначе не получится.

MMP плюс Firebase вместе, когда: вы банк или суперприложение. Сюда приземляется большинство моих проектов. Firebase даёт Google-нативную глубину и бесплатные сырые события; MMP даёт кросс-сетевую правду и серверную точку входа для настоящих денег. А арбитром в их споре выступает хранилище, где сырая выгрузка MMP, BigQuery-экспорт Firebase и таблицы core banking лежат в одной схеме и джойнятся по вашим собственным ключам.

Итог

Вопрос MMP — это не AppsFlyer против Adjust. Это вопрос, является ли Google всей вашей историей привлечения и видно ли ваше revenue из SDK. Если оба ответа «да» — «только Firebase» является легитимным ответом, и шопинг можно прекращать. Если хотя бы один «нет» — вы покупаете нейтральную точку стыковки, и дальше выбор сводится к тому, как вам удобнее платить и кто должен быть в комнате, чтобы выкатить новое серверное событие: AppsFlyer публикует ставку и принимает от бэкенда любое имя события, Adjust даёт котировку и требует сначала завести событие в своём дашборде. Что бы вы ни выбрали, revenue-событие всё равно придётся отправлять со своей стороны — и всё равно всё должно приземляться в хранилище, которым владеете вы.

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

Источники

  • Прайсинг AppsFlyer — welcome-пакет Zero на 12K конверсий, Growth по $0,07 за конверсию сверху, отдельно оплачиваемые дополнения (проверено в июле 2026)
  • S2S events API AppsFlyer — appsflyer_id, eventName, eventValue, дедупликация по af_order_id
  • S2S events API Adjust — s2s=1, app_token, создаваемый в дашборде event_token, требования к рекламному идентификатору
  • S2S security Adjust — токены аутентификации запросов, генерируемые в дашборде
  • Экспорт Firebase в BigQuery — сырые события как нейтральный слой джойна