Собираем и анализируем статистику в мобильных приложениях

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

На рынке присутствуют готовые инструменты, такие как, например, Flurry или Kontagent. Для них есть как готовые SDK под основные платформы, так и какой-то инструментарий по работе с данными в виде отчетов/графиков/воронок и т.д. Однако же эти инструменты также обладают рядом недостатков.

Так, например, у Flurry наблюдаются значительные задержки в обработке информации и, что хуже, опытным путем установлено наличие серьезных потерь в данных (по нашим оценкам Flurry “теряет” от 30 до 60% данных). Ну а серьезным недостатком Kontagent становится стоимость лицензии на его использование, так как она может подойти далеко не каждому. Также практически все готовые решения не предоставляют необходимой гибкости и прозрачности при работе с отчетами.

Flurry + Splunk

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

После выбора инструмента для обработки статистики, логичным образом встал вопрос о том, а как, собственно, мы будем получать данные из игры. Игра, показатели которой нас интересовали, уже была опубликована и в ней уже был интегрирован модуль Flurry (и на тот момент мы еще не знали о потерях данных у Flurry), поэтому мы приняли решение выкачивать данные из Flurry, используя их Raw Data API.

Это вот самое Raw Data API на поверку оказалось весьма неоднозначным инструментом, достойным отдельного поста. Но, “невзирая на боль”, мы тем не менее настроили получение статистики из Flurry и загрузки ее в Splunk. После чего система была запущена в боевую эксплуатацию: данные индексируются, аналитики строят отчеты, все радуются, зал апплодирует, цветы, музыка, шампанское.

Счастье продлилось недолго. Буквально до нескольких сверок цифр, которые мы могли сверить хоть с чем-то еще, заведомо достоверным, помимо имеющейся статистики — данных, связанных с внутриигровыми платежами, которые были у нас в Splunk и которые нам показывает мобильный стор. В том, что данные не совпадут, никто особо не сомневался (всегда есть факторы задержки в поступлении данных, возможные ошибки в построенных отчетах, потенциальный “фон” в статистике от читеров и т.д.), но никто не ожидал, что разница окажется именно такой: данных в статистике отображалось почти в два раза меньше, чем в сторе (и по сумме, и по количеству платежей). Детальный анализ показал, что ошибок в отчетах и выборках нет, данные в Splunk интерпретируются корректно, игровое приложение также отправляет статистику в Flurry SDK исправно и там, где требуется, но сырых данных от Flurry поступает “несколько” меньше, чем есть на самом деле. Как уже говорилось выше, наша оценка потерь данных — от 30 до 60 процентов.

Kontagent

Через некоторое время у нас также появилась возможность сравнить вживую работу нашей связки Flurry+Splunk с системой Kontagent. Kontagent предоставляет гораздо более широкий набор возможностей, заявляется, что работает практически в режиме реального времени, имеет интеграцию с кучей маркетинговых инструментов и вообще весь такой няшка.
На самом деле, все приблизительно так и есть, однако, повторюсь, стоимость лицензии для мобильных платформ вряд ли обрадует небольшие команды: стоимость напрямую зависит от объема вашей аудитории и разговор начинается с десятков тысяч долларов в год. Сравнительный анализ подтвердил нашу гипотезу о потерях данных на стороне Flurry. Судя по всему, в том числе и за полноту данных Kontagent и просит свой ценник.

Таким образом, мы оказались перед следующей дилеммой — переезжать на Kontagent или оставаться с Flurry? Полноценный переход на Kontagent осложнялся рядом моментов, в первую очередь связанных с необходимостью переделок в игре, чего нам очень хотелось избежать. В то же время оставаться с Flurry означало получать заведомо неполную картину, на основании которой принимаются важные решения.

Финальное решение

В итоге было принято “Соломоново решение” — заменить Flurry на собственный транспорт данных из игры в Splunk с максимальным сохранением формата данных и минимальными изменениями в игровом коде.
От системы требовалось:

• максимальная надежность
• максимальная легковесность / устойчивость к высоким нагрузкам
• минимальное время задержки между получением данных от клиента и попаданием их в индексы Splunk

Для обеспечения этих требований была предложена следующая схема работы системы:

• передавать все параметры на сервер в строке GET-запроса
• в таком варианте самым простым, надежным и дешевым с точки зрения нагрузки на сервер хранилищем данных становится access.log веб-сервера, мы используем nginx
• для обеспечения минимальной секурности используется md5-подпись запроса, которая реализуется с помощью модуля HTTPSecureLink для nginx
• для обеспечения масштабируемости на фронтенд ставится балансировщик, который может “револьвером” раскидывать запросы по кластеру нод-логгеров
• для минимизации задержек access.log ротируется раз в час и самый “свежий” ротированный лог передается в Splunk, обеспечивая часовое отставание данных в индексах
• для передачи данных в головной инстанс Splunk на каждой ноде-логгере установлен Splunk Universal Forwarder — “родной” транспорт от Splunk, который занимается только передачей данных, т.е. дает минимальную дополнительную нагрузку на ноду
• для обеспечения консистентности данных от одного пользователя, распределенных по кластеру нод-логгеров, в каждом запросе присутствует уникальный идентификатор пользователя и timestamp, взятый по времени пользовательского устройства

В итоге мы получили стабильную, легковесную, масштабируемую систему сбора и транспортировки в Splunk статистических данных. Параллельно были реализованы клиентские SDK для iOS и Android, которые для простоты интеграции продублировали API предоставляемое Flurry SDK. Т.е. переход на новую SDK занял полчаса времени программиста, включая тесты.

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