AppsFlyer vs Adjust vs только Firebase: когда MMP реально стоит своих денег

Firebase не является измерительным партнёром, но «только Firebase» - легитимный ответ, если Google - это вся ваша история привлечения, а revenue видно из SDK. Если хотя бы одно из условий не выполняется, вы покупаете MMP как нейтральную точку стыковки. Между AppsFlyer и Adjust в реальной работе всплыли два отличия - прайсинг и контракт server-side событий: AppsFlyer публикует $0,07 за конверсию сверх первых 12K, а Adjust даёт котировку под контракт и требует сначала завести каждое серверное событие в своём дашборде.

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

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

Что реально даёт только 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 пайплайном. Форма решения:

1. 

   Мобильное приложение (Flutter) → AppsFlyer SDK → appsflyer_id

   • снимается при логине, сохраняется в карточке клиента
2. 

   Core banking: loan_disbursed / card_issued / deposit_opened

   • backend worker
3. 

   POST https://api3.appsflyer.com/inappevent/{app_id}

   • af_revenue = сумма выдачи, af_order_id = application_id
4. 

   Дашборд MMP: полная воронка с реальными деньгами

Изначально пайплайн отправлял события в api2; сейчас AppsFlyer принимает S2S-события на api3 с отдельным S2S-ключом, поэтому на схеме указан текущий эндпоинт.

Держат эту конструкцию три детали. appsflyer_id снимается при логине и кладётся в карточку клиента, потому что бэкенду он понадобится через часы, когда контекста SDK давно нет. af_order_id равен идентификатору заявки, чтобы каждое revenue-событие связывалось со своей заявкой. Ретраи гасит бэкенд, потому что AppsFlyer не дедуплицирует S2S in-app события: переигранная джоба пропускает строки выдачи, уже помеченные флагом отправки. И события разделены по каналу завершения - 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-ключ в заголовке authentication; добавление нового бэкенд-события - это изменение только на бэкенде. 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, связанный с вашим идентификатором клиента, eventValue строкой
• S2S events API AppsFlyer (api3) - POST https://api3.appsflyer.com/inappevent/{app_id}, S2S-ключ в заголовке authentication, обязательные appsflyer_id, eventName, eventValue (проверено в октябре 2026)
• Бюллетень AppsFlyer об обновлении S2S API - переход с api2 на api3, S2S-ключ вместо dev key, с 12 декабря 2023; api2 будет выведен из эксплуатации, дата не объявлена (проверено в октябре 2026)
• Обзор in-app событий AppsFlyer - дедупликация работает только для событий из SDK, S2S in-app события не дедуплицируются (проверено в октябре 2026)
• S2S events API Adjust - s2s=1, app_token, создаваемый в дашборде event_token, требования к рекламному идентификатору
• S2S security Adjust - токены аутентификации запросов, генерируемые в дашборде
• Экспорт Firebase в BigQuery - сырые события как нейтральный слой джойна