Аналитика мобильного приложения: что считает Firebase, а что MMP

На планёрке в сервисе доставки продуктов в Алматы и Астане звучат два вопроса. Маркетолог хочет знать, какая сеть приводит покупателей. Продакт спрашивает, почему из 10 000 установок из рекламы за месяц до первого заказа дошла только тысяча. На первый вопрос отвечает MMP, на второй продуктовая аналитика, и путаница начинается, когда ответ ищут не в том инструменте. Приложение и цифры те же, что в уроке про MMP на практике, и они условные.

Два инструмента, два вопроса

MMP, то есть AppsFlyer или Adjust, отвечает на вопрос «откуда»: какой сети засчитать установку, сколько стоил первый заказ из каждой и какие события отправить сетям, чтобы их алгоритмы учились. Продуктовая аналитика (Firebase с GA4, Amplitude или Mixpanel) отвечает на вопрос «что дальше»: какие экраны человек открывал, где бросил корзину, вернулся ли через неделю.

Firebase хорошо видит, что происходит внутри приложения, но не рассудит Meta и TikTok, которые заявили одну установку: эти сети заявляют установки измерительным партнёрам, а не Firebase. Когда для рекламы хватает одного Firebase, например если вся реклама идёт через Google, разобрано в статье про AppsFlyer, Adjust и Firebase.

Из этого следует правило для плана событий. В MMP отправляют то, что нужно рекламным сетям и отчёту по источникам: первый заказ first_purchase, повторный purchase и регистрацию sign_up. Каждый экран и каждое нажатие уходят в продуктовую аналитику. Сетям для обучения нужны заказы и регистрации, а экраны в MMP только загромождают список событий, который приходится сопоставлять в каждой интеграции.

Что видит Firebase и GA4

В приложении GA4 работает через Firebase. Когда вы добавляете в ресурс GA4 поток для iOS или Android, GA4 создаёт проект Firebase, если его ещё нет, а разработчик встраивает в приложение Google Analytics for Firebase SDK (поток для приложения). Часть событий SDK собирает сам (автоматические события):

• first_open - первый запуск после установки или переустановки;
• screen_view - переход между экранами;
• session_start - начало сессии;
• app_remove - удаление приложения, только на Android.

Шаги покупки разработчик отправляет сам рекомендованными событиями электронной торговли: view_item (открыл карточку товара), add_to_cart, begin_checkout и purchase (события ecommerce в Firebase). Здесь легко ошибиться: автоматическое событие in_app_purchase считает только покупки, которые прошли через App Store или Google Play. Продукты оплачивают картой в приложении или курьеру при доставке; ни те, ни другие платежи через магазин приложений не идут, и без своего события заказов в отчёте не будет.

Последний шаг воронки - тот же first_purchase, что уходит в AppsFlyer: приложение отправляет его и в Firebase. Но приложение знает только об оплате картой. Заказ с оплатой курьеру закрывается на сервере, и в Firebase он попадёт, только если его отправит сервер через Measurement Protocol; иначе такие заказы досчитывают по системе заказов. Воронка для приложения доставки:

Хуже всего проходит шаг от карточки к корзине: из 60 открывших карточку в корзину добавляют 25, то есть 42%. Почему, воронка не скажет. Дальше её режут по городу, категории товара и версии приложения: например, если в Астане отвал заметно больше, посмотрите, не показывает ли приложение там карточки товаров, которых нет в наличии. Читать такие воронки помогает анализ воронки и точек отвала, а с Amplitude и Mixpanel работают по событийной аналитике.

Почему установки в Firebase и в MMP не совпадают

За сентябрь в Firebase 11 200 событий first_open, а в AppsFlyer 10 000 установок из рекламы. Ошибки тут может и не быть, потому что считают они разное.

• MMP считает установкой первый запуск, а не скачивание (AppsFlyer, Adjust), то есть по смыслу это тот же first_open. Но Firebase записывает first_open и после переустановки, а AppsFlyer переустановку в пределах окна повторной атрибуции новой установкой не считает.
• 10 000 - это установки, которые AppsFlyer приписал четырём сетям. Органику он показывает отдельной строкой, а в first_open она уже внутри.
• Если SDK стартуют в разный момент или один из них ждёт согласия, часть первых запусков одна система увидит, а другая нет.

Сравнивайте одинаковое: все установки AppsFlyer вместе с органикой и переустановками против first_open, за одни и те же дни и в одном часовом поясе. Если и тогда разрыв большой, ищите, где SDK стартует позже или не стартует.

Как связать источник с поведением

По таблице из урока про MMP первый заказ делают 15% установивших из Google и 5% из TikTok. Где теряются люди из TikTok: на карточке товара или на оформлении? Отдельно ни один инструмент этого не скажет. MMP не видит шагов внутри приложения, Firebase не знает, какой сети засчитана установка.

Связать их можно двумя путями.

1. Передать атрибуцию в продуктовую аналитику. У AppsFlyer есть готовая интеграция с Amplitude: она отправляет данные об установках, а Amplitude сопоставляет их с пользователями по идентификатору устройства (интеграция в документации Amplitude). После этого воронку можно разбить по источнику. Часть установок может прийти без названия сети и кампании, Amplitude об этом предупреждает.
2. Склеить сырые данные в BigQuery. Приложение передаёт один и тот же номер клиента в AppsFlyer как Customer User ID (базовая интеграция SDK) и в Firebase как user ID. Firebase выгружает события в BigQuery (экспорт в BigQuery), рядом загружают сырые данные AppsFlyer и соединяют их по номеру клиента. Номер берут внутренний: данные, по которым можно узнать человека, например email, Firebase в user ID класть запрещает (user ID в Firebase).

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

Открылась ли карточка из рекламы

Объявление приложения доставки показывает товар, и после установки человек должен увидеть ту же карточку, а не главный экран. На схеме тот же путь показан на приложении экскурсий. За такой переход отвечает отложенный диплинк (deferred deep link), и здесь вопросы снова делятся между инструментами.

Какой товар открыть, приложение узнаёт от MMP. Если ссылка сделана через OneLink AppsFlyer, ответ для нового пользователя содержит только параметры диплинка, например deep_link_value, а media_source и campaign в нём пустые (Unified Deep Linking для Android). Поэтому кампанию берут из отчёта атрибуции, а не из ответа диплинка. Открылась ли карточка на самом деле, показывает продуктовая аналитика: в первой сессии должен быть view_item с тем же товаром. Настройка и проверка диплинков - в уроке про deep linking.

Задание: карта вопросов к своему приложению

Возьмите приложение, с которым работаете, или приложение доставки из урока.

Выполнено 0 из 4

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

А теперь ситуация, которая встретится вам на проекте. Продакт пишет: «В Firebase 11 200 первых запусков, в AppsFlyer 10 000 установок. Какая система врёт? И давайте отправлять в AppsFlyer все экраны, чтобы видеть воронку по сетям».

Не врёт ни одна. В 10 000 только установки, которые AppsFlyer приписал рекламе, а в 11 200 есть органика и переустановки. Сравнивать надо общее число установок AppsFlyer с first_open за те же дни и в том же часовом поясе. Экраны в AppsFlyer отправлять незачем: воронка по сетям получится, если передать атрибуцию из AppsFlyer в Amplitude или склеить данные в BigQuery, а в MMP останутся только события, нужные рекламе.

Видео: роль AppsFlyer

Короткий обзор на английском о том, что AppsFlyer делает с расходами на рекламу приложения.