Продуктовая аналитика мобильных приложений | GeekBrains – образовательный портал

Продуктовая аналитика мобильных приложений | GeekBrains - образовательный портал Аналитика
Содержание
  1. Как всё начиналось
  2. Основные системы мобильной аналитики
  3. Events vs pageviews (внутренние системы аналитики для мобильных приложений)
  4. Return on investment (roi)
  5. Аналитика мобильных приложений: 5 базовых показателей отслеживания
  6. Аналитика сторов мобильных приложений
  7. Важно хотеть развиваться в аналитике и не стоять на месте
  8. Как выбрать платформу аналитики мобильных приложений?
  9. Кого выбирать
  10. Настройка аналитики мобильного приложения. алгоритм
  11. Не быть одиночным игроком — важно учиться взаимодействовать с командой
  12. Нужно находить баланс интуиции и цифр
  13. Нужно уметь быстро разбираться в инструментах и метриках
  14. Ошибки при настройке аналитики в мобильном приложении
  15. Полезные хаки при настройке аналитики в мобильном приложении
  16. Сквозная, маркетинговая, продуктовая и мобильная аналитика | медиа нетологии
  17. Сколько стоит
  18. Эксперименты

Как всё начиналось

Удивительно, но на начало 2021 года большинство девелоперов могут оценить эффективность каналов трафика только по начальным метрикам воронки (постклик на сайте, длительность и стоимость звонка).

Совершенно отсутствует понимание, сколько стоит привлечение реального покупателя квартиры с определенного канала трафика.

Так же было и в мобайле. По меркам диджитала довольно давно — лет 5 назад.


Основным KPI для всех неигровых клиентов была стоимость установки приложения (CPI). Не учитывалось, что делают пользователи после инсталла, главное — количество установок и их стоимость.

Сложность была в отслеживании источников трафика. Наиболее популярные системы в те времена — Flurry и Google Analytics. Последняя ставилась вообще автоматом. По одной простой причине — была самой известной.

Эти две системы изначально были аналитикой, но пытались сойти и за трекинг. Например, мы отслеживали установки с разных каналов трафика с помощью Flurry. Правда, приходилось мириться с потерями до 100% и отсутствием интеграции со многими каналами трафика.


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

Благодаря аналитике сейчас CPI — это всего лишь модель закупки трафика, но никак не конечный KPI.

Трекинг любых каналов трафика легко осуществим, но появились новые вызовы — борьба с фродом, глубокие ссылки (deeplink), динамический ретаргетинг, мультиканальная атрибуция и тому подобное.

Основные системы мобильной аналитики

Продуктовая аналитика мобильных приложений | GeekBrains - образовательный портал

Граница между системами – условна, на сегодняшний день она практически стерта, так как каждая система стремится максимально удовлетворять всем целям и задачам владельцев и маркетологов приложений.

GA for Mobile Apps

К плюсам Google Analytics можно отнести его относительную бесплатность (до первых 500К событий); способность видеть DAU, WAU, MAU и предоставлять отчет по удержанию пользователей.  Однако минусов у этой системы гораздо больше: нет сегментации по событиям, не умеет работать с воронками, нет когортного анализа и определения источников трафика, нет А/В тестирования и пуш-нотификаций с сегментами.

Дополнительный анализ:  Большие данные в ритейле -

AppsFlyer

Весь процесс adtracking’а у этой системы аналитики – один из самых лучших на рынке. Может работать с любыми операционными системами (даже небольшими, подстраиваясь под них). Отличается хорошей поддержкой и быстрой работой над исправлениями настроек. Реализована работа с диплинками.

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

Flurry

Система абсолютно бесплатна, очень хорошо умеет трепать все события и процессы, связанные с маркетинговой активностью на площадках Yahoo (в работе с другими площадками есть определенные проблемы). Наличествуют воронки и когортный анализ, соцдем и сегментация аудитории приложения. In-app аналитика у приложения на самом высоком уровне.

Самым большим минусом системы является отсутствие риал-тайм репортов (отчеты могут идти с задержкой в несколько часов). Отсутствие трекинга FB и Google Ads, а также оптимизации данных, также являются достаточно серьезными минусами Flurry.

Amplitude

Это отличная in-app аналитика, которая умеет делать абсолютно все. Но, разумеется, не бесплатно. У Amplitude есть: когорты, пуши, любая внутренняя и внешняя аналитика, отчеты по всем видам событий, ремаркентинг, возможность работы по API, работа с диплинками и базами данных.

Если не смущает цена, иностранный интерфейс и клиентская поддержка, Amplitude для e-commerce систем и банковских сервисов, пожалуй, самая лучшая система. 

Amplitude лучше использовать в паре с трекером Localitics, тем более, что системы являются партнерами.

Events vs pageviews (внутренние системы аналитики для мобильных приложений)

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

С приходом веб 2.0 такой подход стал менее оправданным (пользователь теперь может взаимодействовать с сайтом без перезагрузки страницы) и со временем стали появляться cистемы аналитики, работающие с событиями.

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

Дополнительный анализ:  ЕЩЕ ПАРУ СЛОВ О FIGMA КАК Я НАШЛА СВОЮ “СЕРЕБРЯНУЮ ПУЛЮ”.

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

Системы внутренней мобильной аналитики для мобильных приложений — аналоги всем привычных Google Analytics или Яндекс Метрики в вебе.

Return on investment (roi)

ROI — Return on Investment — коэффициент окупаемости инвестиций. Этот показатель можно рассчитать для уточнения возврата вложений на маркетинг в целом или какую-то конкретную рекламную кампанию (например, с одного канала сбыта).

Формула расчета у ROI простая: (выручка от инвестиций – затраты на инвестиции) / (затраты на инвестици) х 100%.

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

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

Тем не менее, хотя бы примерный ROI знать нужно:

Если ROI больше 100%, значит, инвестиции оправдали себя, вы получили прибыль. В противном случае следует пересмотреть стратегию и либо отказаться от дальнейших инвестиций, либо внести какие-то изменения для исправления ситуации.

Аналитика мобильных приложений: 5 базовых показателей отслеживания

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

  1. Количество регистраций и установок

    Как известно, не все люди, установившие приложение, активно им пользуются. Некоторые даже отказываются пройти регистрацию сразу после запуска сервиса. Поэтому количество установок всегда выше количества регистраций. Хорошим показателем для регистраций является отметка в 60–80%. Кроме прочего, установок может быть больше и из-за того, что некоторые пользователи, уже зарегистрированные в приложении, скачивают его повторно для инсталляции на другом устройстве.

  2. Активная аудитория

    Данный показатель способен отразить количество активных пользователей, которые открывают приложение в течение определенного периода. Выделяют аудиторию: дневную (DAU); недельную (WAU); месячную (MAU).

  3. Длительность сессии

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

  4. Выручка

  5. Вовлеченность в диалог

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

Дополнительный анализ:  Союзное государство России и Беларуси: в поисках вектора развития — Российская газета

Вас заинтересовала услуга «Аналитика мобильных приложений» и вы хотите больше узнать об этом? Позвоните нам по телефону или заполните форму заявки – и мы сами свяжемся с вами в течение рабочего дня!

Аналитика сторов мобильных приложений

Для аналитики сторов можно использовать такие сервисы, как Sensortower, Appfollow, Searchman, AppFigures и AppAnnie, Flurry. Они предоставляют сведения о количестве скачиваний приложения/инапов, о рейтинге и доходах приложения, отзывах и иных параметрах.

Для отслеживания источников трафика хорошо подходят Adjust, Mixpannel, Google Analytics, App Metrika, Mobile App Tracking, Flurry, AppsFlyer. При клике пользователя на рекламный материал (баннер, ссылку в соцсети) его проводят через внешнюю ссылку инструмента аналитики, где скапливаются всевозможные данные о его телефоне.

Для A/B тестирования в мобильных приложениях используются такие сервисы, как Splitmetrics, Onetwosplit, SWRVE, Arise, SQBA. Они дают возможность настроить приложение под определенные сегменты пользователей. Например, разработчик заметил, что повышение цены на какой-то товар для покупателей из города N никак не отразилось на их покупательской способности.

Для работы с push-уведомлениями подойдут Otherlevels, Mixpanel, Playnomics и Capptain. Настройка аналитики для мобильного приложения по этим сервисам позволяет целенаправленно работать с выбранным сегментом аудитории приложения путем отправки им push-сообщений: помогать освоиться новым пользователям и удерживать старых, работать отдельно с платящими/неплатящими пользователями.

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

Важно хотеть развиваться в аналитике и не стоять на месте

Я не верю, что мобильная аналитика выживет как сущность. Думаю, что с аналитикой произойдёт история, которая произошла с дизайном: здесь специалисты перестают быть заточены чисто под отрисовку макетов, под UX или UI и переквалифицируются в продуктовых дизайнеров, которые должны понимать, как дизайн повлияет на какие-то метрики продукта, смогут общаться с пользователями, проведут юзабилити-тестирование и прочее.

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

Как выбрать платформу аналитики мобильных приложений?

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

При выборе всегда стоит обращать значительное внимание на:

  • тарифный план платформы. На официальных сайтах сервисов по обобщению вы сможете найти некоторые функции в бесплатном доступе. Зачастую создатели в этот пакет услуг включают самые базовые опции и, если для оценки мобильного добавления вам не нужно много различных показателей, можно смело использовать такой набор аналитических инструментов. Если необходим более обширный круг инструментов, то стоит ознакомиться с тарифными наборами и выбрать для себя подходящий и выгодный.
  • основные возможности. Многие сервисы специализируются на каком-то одном виде оценки. Если ваше добавление требует использования стандартных расчетных действий, то выбрать платформу для вас не составит труда, но если же ваша разработка более специфична и требует периодизации большего объема показателей, то необходимо подобрать платформу с возможностью настраивания метрик.

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

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

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

Кого выбирать

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

Свой стек традиционно собирают на реляционной колоночной базе данных, например, Clickhouse Tableau для BI. Дополнительно для сбора данных я рекомендую использовать Cube.js. В качестве слов для гугления накидаю: AWS Lambda, Redash, Google Big Query, Serverless.

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

Из сервисный решений традиционно выделяют Amplitude и Mixpanel. Дополнительно сюда можно добавить App Metrica и Firebase Analytics (Google Аналитика для мобильных устройств).

Традиционно выбирают несколько аналитик, чтобы сравнить точность. Обычно берут бесплатную и платную.

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

Который в дальнейшем добавляется в приложение и тестируется.

Настройка аналитики мобильного приложения. алгоритм

Шаг 1. Что хотим знать

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

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

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


Стандартная часть обычно выглядит примерно так:

  • Где люди отваливаются на туториале?
  • Насколько туториал эффективен (какая часть пользователей обучилась по его итогам, а не просто прокликала его)?
  • Сколько людей продолжают использовать приложение спустя один, семь, 14 дней?
  • Какая доля новых пользователей заходят в магазин (или видят продающий экран)?
  • Какова конверсия в покупку? В повторую покупку?
  • Сколько стоит привлеченный пользователь?
  • Сколько мы зарабатываем с пользователя на первый, седьмой, 14, 30 день?
  • Как отличаются ответы на предыдущие вопросы в зависимости от платформы, страны, источника трафика, типа девайса?

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

Итогом этого шага является список вопросов, который представляет собой структуру исследования приложения.

Шаг 2. Какие ивенты и с какими параметрами нужны, чтобы ответить на вопросы из первого шага

Теперь у вас есть понимание того, что конкретно вы хотите знать, поэтому можно переходить к проектированию структуры ивентов и их параметров. Подойдите к этому процессу итеративно. Быстро составьте первую версию списка ивентов и переходите к следующему пункту. К этому пункту вы еще вернетесь.

Шаг 3. Позволит ли используемая система аналитики ответить на вопросы из первого шага со структурой ивентов из второго шага

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

Пример 1. Во Flurry есть ограничение на количество параметров, которые можно передавать с ивентом (не более десяти параметров у конкретного ивента). Поэтому при создании структуры ивентов и параметров вам надо держать эту особенность в голове. В Kontagent параметров ивентов по сути нет , поэтому всю содержательную информацию придется поместить в название ивента.

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

Пример 3. Если вы используете Mixpanel и хотите интегрировать его с AppsFlyer (система для определения источников трафика), чтобы в Mixpanel знать, откуда пришел пользователь, то вам надо будет делать параметр источника трафика глобальным (то есть передавать его со всеми ивентами).

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

Шаг 4. Еще раз пройдитесь по предыдущим пунктам

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

Шаг 5. Встройте аналитику в приложение

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


Осмысленное встраивание аналитики окупается экономией времени на следующем шаге.

Шаг 6. Протестируйте статистику перед релизом

Тестировать можно поверхностно – просто проверить факт того, что ивенты и их параметры приходят в систему аналитики.

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

В системе аналитики Mixpanel это делать очень удобно благодаря инструменту Live view (инструмент позволяет видеть и фильтровать приходящие ивенты в режиме реального времени). Вы что-то делаете в тестовой версии приложения и сразу же видите ивенты, которые приходят в систему аналитики.

Я рекомендую очень внимательно проверять мобильную аналитику, как минимум по двум причинам:

  • Обновить аналитику в мобильном приложении — это накладно (временные затраты на проверку приложения в сторе, а также временные затраты на обновление пользователей на новую версию).
  • Неправильные данные – это еще хуже, с моей точки зрения, чем их отсутствие.

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

Не быть одиночным игроком — важно учиться взаимодействовать с командой

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

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

#нетология#аналитика#карьера

Нужно находить баланс интуиции и цифр

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

9 из 10 продуктовых разработок проваливаются именно из-за слишком большого доверия данным и недоверия своей интуиции. Как бы качественно мы не пытались предсказать будущее по историческим данным, оно туманно.

Именно поиск баланса между данными анализа и собственным опытом — очень непростая задача продуктовой команды. Мне было очень сложно в первое время перестроиться и соглашаться с решениями, которые были приняты «на 50% уверенности». Но со временем привыкаешь — в этом и суть работы с инновациями.

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

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

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

Я начинал изучение с Google Analytics и Яндекс.Метрики. Главная проблема таких сервисов: одна и та же метрика может не только называться по-разному, но и считаться. Например, такая история происходит с показателями отказов, визитами и сеансами. А для начинающего специалиста освоение всех необходимых инструментов — большие нервы и стресс. Поэтому я много копался в справках и постоянно задавал вопросы коллегам.

Интересоваться и расспрашивать — круто. Чем больше копаешься в вопросах, тем быстрее разбираешься. А самый главный вывод, который я сделал — всему можно научиться. Даже тому, что сначала кажется совсем непонятным и чертовски сложным.

Ошибки при настройке аналитики в мобильном приложении

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

Я заметил следующие распространенные ошибки при настройке аналитики:

  1. Настройка аналитики откладывается до последнего момента. Но перед релизом и помимо аналитики (которая в этот момент не кажется особо важной частью) образуется большой стек всевозможных задач. В итоге времени на продумывание того, какие данные следует собирать и зачем, не остается.
  2. Иногда ивентами завешивают каждый элемент и каждое действие в приложении, безотносительно полезности и применимости этой информации. Такой подход тоже опасен, так как появляется куча ненужных данных, а их структура далеко не всегда подходит для последующей работы с ними.
  3. Случается и другая крайность. Ивенты вешают только на наиболее важные места в приложении (по мнению команды на момент релиза), а потом оказывается, что собираемые данные не позволяют получить ответы на ключевые вопросы.
  4. А вот еще одна распространенная ошибка. При настройке аналитики не учитывают ограничения, накладываемые функциональными возможностями используемой системы аналитики, что опять же делает невозможным (или сложным) получение ответов на интересующие вопросы после запуска продукта.

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

Полезные хаки при настройке аналитики в мобильном приложении


Глобальные параметры

Есть такой полезный хак — отправлять определенные параметры со всеми ивентами. Я называю такие параметры глобальными.

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

  1. номер недели или дня, когда пользователь пришел в игру (для последующего выделения когорт);
  2. источник трафика;
  3. уровень игрока;
  4. количество покупок;
  5. количество пройденных уровней в игре.

Пишите статистику как минимум в две системы аналитики

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

Проверяйте покупки на сервере перед тем, как писать их в статистику

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

Как хранить структуру ивентов

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

Как называть ивенты

Чтобы не путаться в названиях ивентов, их удобно называть по принципу
ЭКРАН_ЭЛЕМЕНТ_ДЕЙСТВИЕ. Например, старт уровня будет называться LEVSCR_LEVEL_STARTED, а покупка в магазине SHOP_ITEM_PURCHASED.

Для некоторых сущностей такая структура не подходит, тогда можно вводить сквозные ивенты, которые не привязаны ни к какому экрану, а отвечают, например, за трекинг внутренней экономики. Такие ивенты можно назвать
ECONOMICS_CURRENCY_SPENT и ECONOMICS_CURRENCY_GAINED, а в качестве параметров передавать method (на что потратил) и value (сколько потратил).

Сквозная, маркетинговая, продуктовая и мобильная аналитика | медиа нетологии

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

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

Другой вопрос, может ли компания охватить сразу весь объём инструментов аналитики. Например, настройка сквозной аналитики в самой простой вариации занимает 1–3 месяца. Но потом ее всё равно нужно поддерживать и корректировать на постоянной основе.

Выбор вида аналитики зависит от продукта.

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

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

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

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

Сколько стоит

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

В целом, эта цена — абсолютно адская в соотношении к предоставляемой полезности, поэтому с ростом объемов стоимость сервиса будет расти медленнее. Более того, вы обязаны будете заплатить даже если трафик не сконвертируется и не окупится, то есть по факту вы платите за установку. Такая стоимость может легко увеличить стоимость за установку (CPI) на 10%.

Вывод простой — торгуйтесь, если хотите сэкономить.

Легко посчитать, сколько примерно будет стоить AppsFlyer. Предположим, вы покупаете трафик на $10 000 в месяц при стоимости установки $2 -> 5 000 атрибуций -> 5 000 * 0.06 = $300.

Отмечу, что если вы не получаете данных об атрибуции при выключенном доступе к IDFA, то вы не платите за атрибуцию. Я официально спросил AppsFlyer об этом и получил ответ «Да, если у клиента включен LAT, мы не получаем IDFA/GAID и установка может уйти в органику.

Эксперименты

Продуктовая аналитика мобильных приложений | GeekBrains - образовательный портал

Запускаем мы свои эксперименты двумя путями. Первый, простой – через

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

Но этих результатов обычно мало, нам в том числе. Нам надо было смотреть, как пользователь двигается по воронке, что пользователи делали после того, как нажали на условную синюю/красную кнопку. Поэтому у нас есть второй способ экспериментов, где пригодился Amplitude (эти две системы встраиваются друг в друга).

Optimizely тоже не самый дешевый инструмент, триал заканчивается через два-три месяца, мы постарались уместить в это время максимальное количество экспериментов. Теоретически их можно осуществить на собственном бекенде, просто раздавая каждому пользователю свойство «красная» или «синяя кнопка», а потом в Amplitude выбирать их смотреть статистику. С Optimizely это можно делать на фронтенде.

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector