mobile-qaanalyticsandroidgoogle-playqa

Фантомные пользователи: откуда в аналитике мобильного приложения берутся «боты» и как их отличить от фрода

На днях я почти отправил в поддержку Google Ads гневное письмо про ботов. Картина была очень убедительная: запустили рекламу в США, и в аналитике сразу всплыла одна и та же модель телефона — OnePlus 8 Pro, устройство 2020 года. За три дня — 17 «новых пользователей» из 73. Следующая по частоте модель встречалась два раза. Ведут себя как роботы: открыли приложение, начали первый уровень, бросили. Ни одной покупки, ни одной завершённой игры.

Выглядит как классический фрод: ферма устройств, которая ставит приложение ради оплаченной установки. Письмо было готово. А потом я посмотрел на даты и заметил, что пики «ботов» совпадают не с запуском рекламы, а с днями, когда я загружал новые сборки в Google Play.

Это была не ферма. Скорее всего, это были тестовые устройства самого Google. И это настолько частая история, что про неё стоит знать каждому, кто смотрит на аналитику мобильного приложения.

Что такое pre-launch report и почему он попадает в аналитику

У Google Play есть встроенный автотест — pre-launch report. Каждый раз, когда вы загружаете сборку в Play Console, Google ставит её на свои реальные устройства в Firebase Test Lab и запускает робота-краулера. Робот открывает приложение, нажимает кнопки, проходит экраны и через несколько минут выдаёт отчёт: крэши, проблемы доступности, скриншоты. По документации Play Console отчёт генерируется автоматически при загрузке сборки и обычно готов в течение часа.

Для QA это полезный бесплатный прогон. Но у него есть побочный эффект, про который в документации пишут вскользь: эти устройства — настоящие телефоны с настоящей сборкой. Аналитический SDK внутри приложения не знает, что его запустил робот. Он честно отправляет first_open, сессии, события первого уровня. В отчётах это выглядит как новые пользователи.

А дальше начинаются ложные выводы:

  • «У нас боты». Пачка одинаковых устройств, которые ничего не делают, выглядит как фрод.
  • «Ретеншн упал». Робот никогда не возвращается на второй день. Каждая загрузка сборки добавляет в когорту людей с D1 = 0.
  • «Воронка развалилась». Робот проходит первые шаги и бросает, поэтому конверсия на ранних шагах проседает.
  • «Пользователи не платят». В той же документации прямо сказано, что тестовые устройства не могут совершать покупки.

Если вы загружаете сборки часто — например, пять раз за два дня перед релизом — фантомов становится много. В моём случае это были десятки «пользователей» в неделю на фоне живых установок.

Признаки: тестовое устройство или настоящий фрод

У робота Google и у фермы ботов похожие симптомы, но есть отличия, которые видно в обычной аналитике.

Похоже на pre-launch report:

  • Всплески новых пользователей совпадают со временем загрузки сборок в Play Console, а не с запуском рекламы. Робот отрабатывает в течение часа после загрузки.
  • Версия приложения у «пользователей» — только что загруженная, иногда ещё не выпущенная в production.
  • Источник установки — (direct) или (not set), а не ваша рекламная кампания.
  • Страна часто не определяется ((not set)), сессии короткие — минута-две.
  • Покупок ноль, хотя покупка в приложении есть и живые пользователи её делают.

Похоже на настоящий фрод:

  • Всплеск совпадает с запуском или повышением бюджета кампании и держится, пока кампания крутится.
  • Установки атрибутированы рекламной сети и засчитаны как оплаченные конверсии.
  • Модели и версии ОС распределены неестественно: много одинаковых устройств, но приложение обычной production-версии.
  • Есть клики и установки, но нет даже первого открытия, или открытия идут с одинаковым интервалом.

Главное различие: за роботов Google вы не платите. В документации Play Console написано, что Google Ads уже исключает трафик с адресов pre-launch report. Робот ставит приложение напрямую, без клика по рекламе, поэтому платную установку засчитать не к чему. Он портит аналитику, но не съедает бюджет. Фрод съедает бюджет.

Проверка за пять минут

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

  • Источник. В Firebase или GA4 открываю подозрительный сегмент (например, «модель устройства = X») и смотрю измерение First user source / medium / campaign. Если там (direct) / (none), это не рекламные установки.
  • Время. Сравниваю время first_open подозрительных пользователей со временем загрузки сборок. Совпадение в пределах часа — почти наверняка pre-launch.
  • Версия приложения. Если у «ботов» версия, которая на тот момент была только загружена, а живые пользователи сидят на предыдущей, это робот.
  • Сам отчёт. Play Console → Test and release → Testing → Pre-launch report → нужная версия → Devices. Если подозрительная модель есть в списке устройств отчёта, вопрос закрыт.

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

Как отфильтровать тестовые устройства

Выключать pre-launch report не стоит: он бесплатно ловит крэши до пользователей. Правильнее научить приложение узнавать, что его запустил робот.

Системный флаг Test Lab. На устройствах Firebase Test Lab выставлена системная настройка firebase.test.lab со значением "true". Это описано в документации Firebase — там же пример проверки через Settings.System.getString(contentResolver, "firebase.test.lab"). В Unity то же самое читается через AndroidJavaClass.

Дальше два варианта:

  • Не собирать аналитику вообще. При старте проверяем флаг и, если это Test Lab, выключаем сбор данных до первого события (в Firebase это setAnalyticsCollectionEnabled(false)). Проверка должна стоять как можно раньше, иначе first_open успеет уйти.
  • Помечать, а не выключать. Ставим пользовательское свойство вроде traffic_type = test_lab и фильтруем в отчётах через сравнения и аудитории. Этот вариант мне нравится больше: крэши и производительность робота остаются видны, а продуктовые метрики считаются без него.

Чего не получится сделать. В GA4 нельзя выкинуть трафик по модели устройства через фильтры данных: там есть только фильтры для трафика разработчиков и внутреннего трафика по IP (см. справку GA4). А IP в отчётах Firebase не виден. Поэтому надёжнее всего пометка из самого приложения.

Для других рекламных сетей. Google Ads исключает pre-launch трафик сам. Другие сети могут засчитывать его по-своему. Актуальные IP-диапазоны Test Lab можно получить командой gcloud beta firebase test ip-blocks list и передать в настройки антифрода сети.

Что из этого вынести QA

  • Аналитика — тоже тестовое окружение. Любой автоматический прогон на реальных устройствах шлёт настоящие события: pre-launch report, ваши фермы, автотесты на CI. Если их не помечать, продуктовые решения принимаются по грязным данным.
  • Проверьте, что пометка работает. Флаг Test Lab — отдельный тест-кейс: загрузить сборку, дождаться pre-launch report и убедиться, что эти устройства в аналитике либо отсутствуют, либо помечены.
  • Разделяйте «боты» и «тесты» до жалобы. Жалоба на фрод без проверки источника — это потерянное время и подорванное доверие у поддержки.
  • Реже загружайте сборки, если смотрите на ранние метрики. Пять загрузок за два дня — это пять партий фантомных пользователей, которые обрушат D1 новой когорты.

Чек-лист: фантомные пользователи в аналитике

  • Подозрительный всплеск новых пользователей одной модели — сверить с датами загрузок сборок.
  • Проверить First user source у сегмента: реклама или (direct).
  • Проверить версию приложения у сегмента: только что загруженная или production.
  • Открыть Pre-launch report → Devices и найти подозрительную модель.
  • Убедиться, что за эти установки не списаны деньги в рекламном кабинете.
  • Добавить в приложение проверку флага firebase.test.lab как можно раньше при старте.
  • Решить: выключать сбор аналитики на Test Lab или помечать пользователей свойством.
  • Добавить тест-кейс: после загрузки сборки pre-launch устройства не попадают в продуктовые отчёты.
  • Помечать так же свои автотесты и фермы устройств.
  • Для сторонних рекламных сетей передать IP-диапазоны Test Lab в антифрод.

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