Долгое время наша команда People Data Design занималась исключительно разработкой мобильных приложений. Мы были классической dev командой. Но проходило время и задачи становились на столько привычными и обыденными, что мы начали понемногу скучать. В этот момент мы поняли что хотим большего, хотим развиваться и наращивать вокруг нашей разработки дополнительные услуги. Но услуги те, которые будут приносить бизнесу реальную пользу и которыми нам будет интересно заниматься. Одной из таких услуг стала аналитика мобильных приложений. Направление, которое заставляет твой мозг постоянно быть в фокусе, продумывать метрики, генерировать гипотезы и проверять их, принося непоправимую пользу всем. 

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

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

Основные блоки

Верхнеуровнево, я думаю, можно разделить аналитику на несколько блоков:

1. аналитика трафика;

2. аналитика продаж;

3. аналитика эффективности приложения и его отдельных блоков.

Что мы должны считать в аналитике трафика?

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

Как это считать? Настроить схему UTM меток. Передать во все отделы, чтобы они их использовали. Далее настроить интеграцию системы аналитики. Допустим Google Analitics и настроить интеграцию с рекламными кабинетами. И вуаля, вы видите откуда, какой трафик идет и сколько денег тратится на платные каналы. Так было бы, если бы мы настраивали аналитику на сайт, но в мобильном приложении чуть-чуть по-другому. Нам нужно подключить и настроить APPSFLYER, который позволит нам посчитать весь трафик. 

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

Что мы должны считать в аналитике продаж

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

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

• Главная;

• Категории товаров;

• Список товаров;

• Карточка товара;

• Добавление товара в корзину;

• Корзина;

• Оформление заказа;

• Спасибо за заказ

Либо отталкиваясь от действий пользователей:

• Открытие приложения;

• Просмотр листинга;

• Просмотр карточки товара;

• Добавление товара в корзину;

• Просмотр корзины;

• Оформление заказа

Таким образом мы сможем увидеть конверсию пользователей на каждом этапе. И делать простейшие выводы. Например, у нас был такой кейс, что около 25% пользователей добавляли товары в корзину, около 15% пользователей переходили на экран корзины. Но оформляли заказ в итоге менее 1% пользователей. Это был сигнал что, что-то мешает пользователям оформить заказ на наши утюги на экране оформления заказа. Мы сформировали гипотезы, о причинах подобного поведения пользователей. Сформировали предполагаемые решения, внедрили их через А/Б тест и помогло. Конверсия подскочила до 3,5%. В масштабах проекта и его оборотки это был колоссальный рост. Такие кейсы, конечно, бывают не часто и при наличии очень большой проблемы в проекте.

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

Что получим? К аналитике конверсии пользователей мы сразу получим и аналитику по товарам, товарным группам или торговым предложениям:

• какие товары чаще смотрели;

• какие товары чаще добавляли в корзину;

• товары из каких категорий чаще смотрели;

• товары из каких категорий чаще покупали;

• конкретные цифры и суммы покупок по товарам и категориям;

• соотношение просмотра товара/категории к добавлению в корзину и выкупу;

• статистика в разрезе времени для анализа влияния изменений. Например изменения описательной части товара, его очередности вывода или цены. 

• LTV - общая ценность клиента;

• APRU - средняя выручка с посетителя;

• ARPPU - средняя выручка на платящего пользователя;

• DAU/MAU/WAU - уникальные пользователи в день/месяц/неделю;

• и еще куча-куча показателей, которые можно получить благодаря этой простейшей настройки

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

Что мы должны считать в аналитике эффективности продукта

Далее начинается более интересная история. Мы начинаем прописывать отдельным функциям события, чтобы померить их эффективность. Например, мы хотим проверить эффективность системы лояльности, а точнее на сколько удобно пользователям ей пользоваться в приложении. Мы можем построить такую же микро-воронку по добавлению бонусной карты в приложение и понять так же, где пользователи сталкиваются с проблемами. Или можем проанализировать систему добавления/выбора адреса доставки, и увидеть, что большое количество пользователей (более 40%) не доводят добавление адреса до конца и уходят из мобильного приложения не оформив заказ. 

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

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

Дополнительный блок

Блок аналитики продаж мы уже затронули. Но именно в рамках МП. Важно так же считать аналитику продаж и после того, как заказ был оформлен. То есть выкупили ли его или нет. Так как может быть такое, что заказы оформляют, но в последующем не выкупают. Соответственно аналитика по выручке у нас будет не точная. 

Итог всей работы

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

 P.S. это мой первый пост на Хабре, надеюсь он будет кому то полезный.