GA4 для мобильного приложения: Firebase, события и DebugView

GA4 показывает отчеты, а Firebase подключает приложение

Firebase служит проектом и связующим слоем для приложения. SDK устанавливают в приложение для iOS или Android. Он собирает автоматически записываемые и собственные события, а затем отправляет их в проект Firebase. После связи проекта с Google Analytics эти данные появляются в свойстве GA4.

Google описывает такую связку как способ измерять использование приложения и, если у компании есть сайт, сопоставлять часть пути пользователя между двумя каналами. Но GA4 не решает за команду, что считать активацией, успешной записью или покупкой. Эти определения должны появиться в описании продукта.

Firebase ближе к настройке приложения и работе SDK. GA4 используют для анализа путей, воронок, аудиторий и ключевых действий. В документации Firebase о событиях хорошо объясняется, какие события собираются автоматически, а какие нужно определить самостоятельно.

Как действие превращается в строку отчета

До начала разработки полезно нарисовать весь путь данных. Так становится видно, что приложение подключено не к тому проекту, что выбран неправильный поток или что никто не проверяет параметры.

По возможности разделяйте данные разработки и рабочие данные. Тестовые покупки, смешанные с настоящими, быстро портят отчеты. Как минимум зафиксируйте окружение, версию приложения и список сборок, которым разрешено отправлять рабочие данные.

Составьте словарь событий до написания кода

Словарь событий, это короткая договоренность между продуктом, дизайном, разработкой, тестированием и аналитикой. В нем указаны смысл события, момент отправки, параметры и решение, которое оно помогает принять. Без такого документа одно действие может называться `signup`, `sign_up_complete` или `registration_done` у разных разработчиков.

Начните с вопросов о продукте:

• В какой момент новый пользователь получает первый полезный результат?
• Какой шаг мешает завершить запись, заказ, урок или оплату?
• Для какой ошибки нужна правка продукта, а для какой достаточно ответа поддержки?
• Какое событие подтверждает, что подписка или членство действительно активны?
• По какому действию видно, что пользователь вернулся за нужным ему результатом?

Используйте устойчивые названия, а детали храните в параметрах. `checkout_started` можно сравнивать даже после изменения подписи кнопки. Параметры `plan_type`, `payment_method`, `course_id` или `error_type` добавляют контекст, не создавая десятки похожих событий.

Какие события нужны первой версии

Автоматические события дают хорошую основу, но коммерческому приложению нужны собственные действия. У приложения для курсов, сервиса записи и интернет-магазина разные воронки.

Не передавайте в параметрах имена, телефоны, электронные адреса и свободный медицинский текст. Номер заказа может понадобиться для разрешенной сверки, но он не должен превращаться в скрытый идентификатор человека.

Для MVP небольшой словарь легче проверить, чем список из сотен событий. Ответственный за продукт должен уметь объяснить каждое событие одним предложением и назвать решение, которое оно поддерживает.

DebugView и Realtime решают разные задачи

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

Firebase DebugView показывает с небольшой задержкой события устройства, на котором включен режим отладки. В нем можно открыть событие и проверить параметры. Google отдельно описывает включение отладки на Android через `adb` и на iOS через аргумент запуска Xcode. Режим отладки нужен для проверки внедрения, а не для имитации обычного рабочего трафика.

Раздел Realtime в GA4 помогает убедиться, что свежая активность приходит в нужное свойство и поток данных приложения. Он не заменяет полноценные тесты. Выполните действие, проверьте параметры, повторите сценарий после перезапуска и убедитесь, что два быстрых нажатия не создали две покупки или две записи.

Перед публикацией проведите такую проверку:

1. Установите чистую сборку на настоящее устройство.
2. Включите режим отладки аналитики.
3. Пройдите главный сценарий с тестовой учетной записью.
4. Проверьте в DebugView название события и обязательные параметры.
5. Повторите путь при плохом интернете, отказе в разрешении и после перезапуска.
6. Убедитесь в Realtime, что активность пришла в правильный поток приложения.
7. Отключите отладку до передачи сборки обычным тестировщикам или пользователям.

Ключевые действия должны означать успех

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

Не делайте ключевыми `screen_view`, `button_tap` и каждое открытие меню. Большое количество активности еще не означает, что продукт движется вперед. Полезная воронка может состоять из `first_open`, `sign_up_complete`, `first_value_reached` или из `product_viewed`, `checkout_started`, `purchase_complete`.

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

Параметры, свойства пользователя и версии приложения

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

Например, `booking_complete` может содержать `service_type`, `payment_method`, `amount` и `currency`. Свойство `account_role` иногда помогает разделить клиента и исполнителя, если это действительно нужно и допустимо. `app_version`, `platform` и `environment` относятся к техническому контексту.

Заранее определите допустимые значения. Если одна версия отправляет `online_course`, а другая `course_online`, отчет разделит одну категорию на две. Добавьте события в шаблон технического задания мобильного приложения и укажите, кто может менять словарь.

Ошибки, из-за которых данным нельзя доверять

Чаще всего проблема возникает не в GA4, а при передаче работы между участниками:

• приложение использует не тот проект Firebase или рабочий поток данных;
• одно событие добавлено в двух слоях и отправляется дважды;
• iOS, Android и сервер используют разные написания;
• важный параметр пропадает именно в сценарии ошибки;
• команда сразу смотрит обычный отчет после теста и принимает задержку за потерю данных;
• тестовую отладочную активность принимают за рабочий трафик;
• изменение SDK или согласия на обработку данных выпускают без повторной проверки;
• событие покупки отправляется в момент открытия оплаты, а не после подтверждения платежа.

Письменный словарь, список проверки релиза и повторяемые сценарии полезнее еще одного отчета. Если событие отправляется не в тот момент, отчет этого не исправит.

Приватность и данные для магазинов

Аналитика влияет на политику конфиденциальности, запрос согласия и формы магазинов. Apple просит описывать данные, которые собирают приложение и сторонние сервисы. Google Play требует точных сведений в разделе Data safety. Ответ зависит от SDK, типа данных, цели, срока хранения и особенностей продукта.

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

Как Appfyl закладывает аналитику в проект

Appfyl считает измерение частью объема продукта. На этапе обсуждения мы связываем вопросы бизнеса с основными пользовательскими путями, выбираем события первой версии и откладываем то, что не помогает принять решение. Словарь событий становится общей частью передачи работы между продуктом, мобильной разработкой, сервером и тестированием.

Перед запуском команда проверяет настоящую сборку в DebugView и Realtime, успешные и неуспешные сценарии, а также соответствие политики конфиденциальности установленным SDK. Инструмент может измениться, но ответственность за достоверные данные остается в проекте.

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

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Порядок действий перед выпуском

1. Запишите вопросы, на которые должна ответить первая версия.
2. Нарисуйте главный путь и выберите события результата.
3. Зафиксируйте в спецификации названия, параметры, значения и ответственных.
4. Проверьте проект Firebase, идентификаторы приложения и свойство GA4.
5. Реализуйте автоматические и собственные события без лишних персональных данных.
6. Проверьте успех, ошибку, отсутствие сети, отказ в разрешении и перезапуск в DebugView.
7. Убедитесь в Realtime, что активность приходит в правильный поток, и настройте ключевые действия.
8. Сопоставьте политику, согласие и формы магазинов с реальной работой SDK.
9. Передайте словарь событий и версию вместе с документацией проекта.
10. После запуска посмотрите первую воронку и только потом добавляйте новые события.

Частые вопросы