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

Мы в команде Proba занимаемся разработкой сервиса для A/B-тестирования мобильных приложений. Поскольку A/B-тесты полностью основаны на данных приложений, наша работа тесно связана с мобильной аналитикой. Поэтому мы решили разобрать самые частые проблемы, которые нам встречались на практике.

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

Частый кейс: данные по количеству установок приложения в аналитической системе и консоли (App Store Connect или Google Play Console) не сходятся. Почему могут быть расхождения? Чаще всего причина в следующем: в статистике App Store Connect мы видим количество установок — сколько раз ваше приложение скачали, это отчёт Копии приложения. А аналитические системы показывают, сколько раз ваше приложение открыли. Трекинг начинает работать тогда, когда инициализируется SDK, то есть когда ваше приложение запускают. Но не все пользователи, скачавшие приложение, его запустят. И здесь уже появляется расхождение данных.

Кстати, более подробно об аналитике мобильных приложений и ASO рассказываем в нашем курсе на платформе Stepik.

В аналитических системах могут не учитываться какие-то события, которые вы хотите отслеживать. Есть несколько возможных причин, почему это может происходить:

• Неправильная настройка события. Из-за этого оно просто не отправляется в трекинговую и аналитическую систему.
• Событие не выполняется пользователями. Такое бывает, если у приложения небольшая аудитория или событие редкое — пользователи просто не добираются до него. Чтобы избежать такой ситуации, нужно тестировать отправку событий до релиза. Если вы добавляете новые события в аналитику, то при тестировании важно проверить, что они действительно приходят в систему, срабатывают тогда, когда должны. Поручите вашему QA-инженеру проверить корректность срабатывания событий перед релизом приложения.
• Аналитическая система отправляет события «пачками». Чтобы не перегружать сервера, сервисы аналитики могут отправлять информацию о событиях «пачками», либо по таймауту (когда набралось 10 событий, прошло 10 или 30 секунд). Например, в приложении есть регистрация пользователей, в которой настроено 5 событий. Система аналитики будет ждать ещё несколько событий, чтобы отправить всю «пачку». Нужное количество событий для отправки может не накопиться и пачка так и не отправится. Как с этим бороться? Можно принудительно отправлять события. В большинстве систем аналитики есть возможность принудительно отправить одно или несколько событий. Но мы не рекомендуем прибегать к этому постоянно, потому что может нарушаться последовательность приёма. И, в целом, это не то, чего от нас обычно ждёт аналитическая система. Это увеличивает нагрузку на сервера аналитических систем и на соединение с интернетом, если на каждое действие отправляется отдельный запрос.

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

Ещё одна частая ситуация: аналитическая система не узнает, какому пользователю относятся события. Система либо создаёт нового пользователя (как в Amplitude), либо событие просто игнорируется (как в AppsFlyer).

В чём суть:

Конкретный пользователь установил приложение, аналитическая система присвоила ему номер 1. Мы отправляем из какого-то другого места событие о том, что пользователь совершил покупку. Нам обязательно нужно указать, что этот пользователь тоже номер 1, чтобы аналитическая система нашла этого пользователя. Пользователь № 1, который установил приложение и пользователь № 1, который совершил покупку — это один и тот же пользователь.

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

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

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

Если событие о покупке приходит вместе с данными о доходах, то данные и о доходах задвоятся. Например, вы увидите доход в кампании 10,000 $, расход 7,000 $. Кажется, что ROI в плюсе и всё в порядке. А на самом деле фактически заработано 5,000 $, и кампания в минусе.

Поэтому нужно сравнивать данные и в App Store Connect / Google Play Console, и в сервисе, где происходит учет оплат. Они должны сходиться.

Как бороться с расхождением данных? Тестировать, сравнивать общее количество, сравнивать с другими системами, и отключать какую-то систему при необходимости.

В разных аналитических системах данные по событиям могут расходиться. Чаще всего причина в том, что сервисы запускаются в разные моменты времени. Они не всегда срабатывают одновременно. Например, один пользователь запустил приложение, у него успел включиться Amplitude и отправить событие. А у другого пользователя не успела отправиться информация после запуска приложения.

Почему так происходит? Как правило, разработчики приложений, в первую очередь, думают о пользователе, а не об аналитических системах. Разработчики часто стараются сделать так, чтобы в первую очередь загрузился ценный контент для пользователя, а уже потом запустились Amplitude, AppsFlyer и прочие фоновые процессы. Часть юзеров не дождётся загрузки приложения, поэтому App Store Connect покажет сильно больше установок, чем их зафиксируют трекинговые системы.

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

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

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

Если вы хотите учитывать платежи в другой валюте, нужно решить, по какому курсу вы будете конвертировать. Например, по курсу на момент транзакции, на момент учёта или на момент выплат.

Очередная ситуация, когда могут расходиться данные: разные окна атрибуции в разных системах.

Окно атрибуции установки — это количество дней между просмотром объявления или кликом по нему и последующей установкой приложения. Например «окно атрибуции установки 7 дней» означает, что с момента клика по рекламе до инсталла прошло 7 дней. Фактически, окно атрибуции — это договорённость.

В разных системах могут быть разные настройки окон атрибуции. Проблема в том, что вы можете просматривать данные в двух разных системах, в каждой из которых окно настроено по-разному: где-то 3-го дня, где-то 7-го. С 4 по 7 день пользователи могли совершить ещё установки, и данные в системах аналитики могут разойтись. Поэтому важно, чтобы договорённость об окнах атрибуции была одинакова во всех системах. К тому же, в разных системах установки учтутся за разными источниками в зависимости от настроек.

Следующий момент — вы пытаетесь найти ответ на вопрос: «Сколько покупок в приложении мы получили с каждого источника?». Для правильного подсчёта эффективности канала также важно сравнивать одинаковые окна атрибуции конверсии: за месяц, за неделю, за день и т.д.

Кроме того, нужно учитывать отложенные во времени конверсии. Например, вы продаёте подписку в приложении с триальным периодом в 7 дней, и вам нужно оценить конверсию в покупку. Если вы посмотрите статистику по покупкам с трафика, который пришел за последние 7 дней, там окажется 0 покупок. Никто не мог стать платящим пользователем за это время — бесплатный период ещё не прошёл. Оценивать нужно конверсию с трафика, который пришёл 8 и более дней назад. Это довольно очевидная, но частая ошибка.

В разных системах аналитики одним и тем же термином могут называться разные вещи. Самый простой пример из пункта 1 — когда мы сравниваем данные по количеству установок из консоли и из трекера. Это не совсем корректно, ведь мы сравниваем разные метрики — установки и запуски приложений.

Ещё один пример, когда сравнивают несравнимые данные: в каких-то системах может учитываться статистика по всем пользователям, в каких-то — только по пользователям, разрешившим трекинг рекламы. Это статистика по так называемым «LAT on/LAT off» пользователям — разрешившим и не разрешившим трекинг рекламы в приложениях (стало ещё актуальнее с выходом iOS 14.5).

Мы перечислили многие популярные проблемы, которые встречались в мобильной аналитике в нашей практике. Главный вопрос: что со всем этим делать, если у вас где-то что-то не сходится.

В первую очередь рекомендуем проверить техническую часть: всё ли правильно настроили разработчики, посмотреть логи, как работает отправка событий. Если вы всё проверили, но данные сильно не сходятся (отклонение на 20-30%), то здесь, к сожалению, единственный выход — обратиться в поддержку аналитической системы. Благо, что в больших системах она отвечает достаточно быстро. Можно обращаться за помощью в тематические группы на Facebook, в Telegram или в Slack-коммьюнити.

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

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

Сталкивались ли вы с подобными проблемами в мобильной аналитике? Пишите в комментариях ваши интересные кейсы — разберёмся вместе.