КЕЙС: ВЫЯВЛЕНИЕ ОТКЛОНЕНИЙ В РАБОТЕ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ ПОСЛЕ ОБНОВЛЕНИЙ

ОПИСАНИЕ ЗАДАЧИ

Социальная платформа регулярно публикует новые версии мобильных приложений с улучшенным функционалом и исправлениями ошибок предыдущих версий. Обновленные версии могут содержать новые технические ошибки, упущенные на стадии тестирования. Также ошибки могут возникать в результате обновления операционных систем, настроек сервера и настроек рекламных систем внутри приложений. Для разработчиков важно как можно скорее выявить ошибки в работе приложения, чтобы они затронули минимально возможный процент пользователей.

Как часто вносились изменения? 5-8 обновлений версий в месяц для приложений на Android и iOS для трех продуктов, то есть  30-45 релизов каждый месяц. При этом версии обновляются с постепенным внедрением (повышением процента rollout). 3-7 изменений настроек сервера в день. 4-8 изменений в настройках рекламы каждую неделю.

ОТСЛЕЖИВАНИЕ ОТКЛОНЕНИЙ

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

При этом метрики отдельно рассматривались для 2 сегментов сессий и 2 сегментов пользователей: 

1. Сегменты сессий: новые (первая сессия с новым ID устройства) и повторные. Метрики на уровне версии приложения анализировались для разных сегментов сессий, чтобы сравнить поведение пользователей при первом / повторном использовании приложения в разных версиях. 
2. Сегменты пользователей: новые (хиты от пользователей в первые 24 часа после установки приложения) и вернувшиеся. Сравнивалось поведение пользователей в первый / последующий день использования приложения. 

Зачем группировать сессии и пользователей? Поведение пользователей социальной платформы отличается в зависимости от давности установки приложения. Новые пользователи активней взаимодействуют с приложением: проходят регистрацию, загружают фотографии, просматривают и лайкают больше профилей, отправляют больше сообщений, таким образом проводят в приложении больше времени и просматривают большее количество экранов. Вернувшиеся пользователи входят в аккаунт (логинятся), кликают по уведомлениям, совершают покупки в приложении (например, услугу “Поднятие профиля”, так как со временем профиль пользователей ранжируется ниже в результатах поиска). Также настройки рекламы внутри приложениями заданы таким образом, что новым пользователям реклама показывается реже, а вернувшимся – чаще, мотивируя купить платную подписку.

Метрики в разрезе версий приложения (новая версия с предыдущими версиями) сравнивались внутри сегмента сессий / пользователей. 

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

В зависимости от анализа и настроек сервера и рекламы, данные могли анализироваться и еще по двум сегментам – полу (указанному при регистрации) и геоположению пользователя. Например, реклама не показывается девушкам, а только парням. Также подписки и покупки внутри приложения рассчитаны на парней. Модели монетизации отличаются в зависимости от страны.

Как проводился контроль метрик? Для контроля метрик использовались регулярные отчеты (рутинный мониторинг без разбивки по всем версиям приложения, с фильтрами по сегментам сессий / пользователей) и сводные таблицы метрик с разбивкой по версиям приложения (с фильтрами по сегментам сессий / пользователей). Пострелизовый мониторинг проводился после каждого повышения процента внедрения (rollout). 

При этом на уровне версии в отфильтрованном сегменте в качестве количества сессий / пользователей, минимального для возможности сделать вывод об успешности внедрения, принималось количество в 1000 сессий / пользователей. Мониторинг повторялся с повышением процента внедрения, когда колебания показателей сглаживались из-за повышения размера выборки.

Какие источники данных использовались? Контроль KPI (регулярный и пострелизовый) проводился с помощью следующих отчетов:

• Отчеты Crashlytics и Latest Release в Fabric и отчет Crash в Flurry для отслеживания крашей. Регулярный и пострелизовый мониторинг.

• Дашборд “Изменения метрик во времени” с временными рядами метрик, на основе данных по событиям из Firebase. Дашборд был сделан в Tableau на основе таблиц в BigQuery. Отчеты рассматривались с фильтрами по сегментам сессий / пользователей. Отслеживались временные ряды как количества событий (в том числе изменение структуры события с разбивкой по параметрам), так и уровня конверсии событий (для сегментов сессий) и количества событий на одного пользователя (для сегментов пользователей). Показатели уровня конверсии событий и количества событий на одного пользователя помогали отслеживать тренды в независимости от колебаний трафика. При этом временной ряд лучше рассматривать за период в несколько месяцев, чтобы избежать искажения тренда из-за колебаний платного трафика и Featured-трафика. Примеры показателей, тренды которых отслеживались на дашборде: Registration CVR, Login CVR, Photo Upload CVR, Message Sent CVR, Screens per Session, Interstitial Shown per User, Revenue per User. Применялся фильтр по сегментам сессий / пользователей. Регулярный и пострелизовый мониторинг.
• Отчет “Сравнение версий” в виде таблицы с показателями и детализацией на уровне версии приложения на основе данных Firebase. Применялся фильтр по сегментам сессий / пользователей. Пострелизовый мониторинг.
• Отчет “Показатели по странам” в виде таблицы с показателями и детализацией на уровне страны на основе данных Firebase. Применялся фильтр по сегментам сессий / пользователей.  Регулярный и пострелизовый мониторинг.
• Отчет “Показатели по версии ОС” в виде таблицы с показателями и детализацией на уровне версии операционной системы на основе данных Firebase. Применялся фильтр по сегментам сессий / пользователей.  Регулярный и пострелизовый мониторинг.
• Для дополнительного отслеживания событий: отчеты Events в Fabric и Flurry. Регулярный и пострелизовый мониторинг.
• Для мониторинга коэффициента удержания: отчеты Retention в Fabric, Firebase и Flurry. Изменение коэффициента удержания оценивалось по  графикам временных рядов и с помощью когортного анализа. Регулярный и пострелизовый мониторинг.
• Отчеты внутренней системы мониторинга и документация изменений в версиях приложения.
• Дополнительные отчеты в Facebook Analytics, Google Play, App Store, AppAnnie.

Как отмечали изменения? Отклонения показателей в большинстве случаев было видно тремя способами:

1. График временного ряда показателей отклонялся от тренда (в выбранном сегменте). При этом могла рассчитываться статистическая значимость изменения показателя по сравнению с предыдущим периодом (например, по сравнению с тем же днем недели 7 дней назад). Период для сравнения статистической значимости выбирался со схожими условиями по структуре трафике и настройками рекламы и сервера.
2. Числовое отклонение показателя в последней версии по сравнению со значением показателя в предыдущих версиях (в выбранном сегменте).
3. На графике временного ряда события с детализацией по параметрам события наблюдалось изменение в структуре события (в выбранном сегменте).

На что обращали особое внимание? Часто изменения показателей не означали ухудшения / улучшения в работе приложения и являлись естественными вследствии изменений функционала, настроек сервера и способа привлечения пользователей. Задача аналитика состояла в выявлении потенциально опасных отклонений показателей и создании тех. заданий для проверки работы функций  приложения разработчиками и командой тестирования. Так, увеличение процента платного трафика или Featured-трафика из Google Play и App Store обычно влекло за собой снижение уровня конверсий и среднего времени в приложении в сегментах новых сессий / пользователей, так как платный трафик и Featured-трафик обычно менее мотивированный по сравнению с органическим. В то же время увеличение закупки пользователей через Facebook Ads обычно влекло за собой изменение структуры события Registration по параметрам: повышался процент регистраций с помощью Facebook, а проценты других способов регистрации (Google и Email) снижались.

Пример. В качестве примера рассмотрим активирование в настройках сервера нового типа уведомления “Ваша пассия сейчас онлайн!” пользователям приложения. Уведомление отправляется пользователю А, если он предварительно добавил другого пользователя Б в “Любимые пользователи”, и пользователь Б зашёл в приложение. Какие показатели скорее всего изменятся? Avg. Session Duration: если уведомления будут приходить часто (в течение одной сессии пока приложение на заднем/переднем фоне устройства), то это повысит среднее время сессии, как сумму разниц временных меток между хитами. Login: повысится количество событий от вернувшихся пользователей и снизится/повысится уровень конверсии Login CVR, так как увеличится среднее время сессии (это справедливо и для уровней конверсии других событий, не относящихся к уведомлению). Notification Tap: повысится количество событий и, если уведомления будут отправляться довольно часто,  понизится уровень конверсии Notification Tap CVR (чем больше уведомлений, тем меньше пользователи будут по ним кликать).