Продуктовая и мобильная аналитика: с какими испытаниями в работе сталкиваются специалисты

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

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

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

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

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

Но чаще всего бизнес готов к таким рискам, если их можно контролировать. Например, для тестирования новой фичи в приложении проводится A/B-тест на ограниченную группу пользователей. Даже если метрики в рамках эксперимента «упадут» — это нормально. Так мы тоже учимся «как делать не нужно», лучше понимаем своих пользователей и делаем продукт лучше.

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

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

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

Я работаю в рекламном агентстве, у которого в клиентах множество компаний. Все они используют разные трекеры — инструменты для сбора статистики конкретного мобильного приложения. Я вынуждена адаптироваться под каждый из них: Appsflyer, Adjust, AppMetricа или под что-то ещё.

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

У каждого сайта-трекера есть огромное количество документации для автоматизации работы. А сайтов, которые стараются помочь аналитикам и предоставляют API (программный интерфейс приложения, который позволяет «поженить» одну систему с другой) с подробной инструкцией — единицы. Если API нет, я пускаю в ход все свои умения и пишу парсеры, чтобы скачать статистику вручную. Не сплю ночами и пытаюсь понять документацию сайта.

Иногда на автоматизацию сайта-трекера уходят недели. Поскольку нельзя оставить клиента без данных, мне приходится собирать статистику «на коленке», пока не настроится автоматизация. Сейчас у меня уже есть 1 000 заготовок на все случаи жизни, но в начале пути такие ситуации были для меня ужасным стрессом.

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

Я нашёл такое решение этой проблемы — нужно глубоко погружаться в каждую метрику, чтобы понять, какая из них будет полезна в конкретном случае. Никто не подскажет, какая метрика — MAU, DAU, revenue, LTV, retention или что-то ещё — нужны именно вашему продукту. Поэтому помимо метрик важно изучить сам продукт, его бизнес-модель и пользователя, чтобы потом выбрать ключевые метрики, на основе которых можно будет принимать решения.

Набить руку поможет знание кейсов аналитики digital-продуктов в разных сферах: ecommerce, банковских, игровых продуктах, а также сервисах доставки, такси, подписки и прочее. Но даже их знание не сможет полностью оградить от ошибок: в аналитике все ошибаются, даже уже опытные специалисты. В какой-то момент они начинают думать: «А разве эта метрика отвечает на мой вопрос? А если бы мы взяли эту метрику, но только для определённого сегмента пользователей, что мы бы получили?». И это нормально. Просто надо принять, что любые люди в компании вплоть до инвесторов могут задать аналитику вопрос: «Почему ты выбрал такие метрики?». И на этот вопрос нужно будет всегда знать ответ.

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

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

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

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

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

В мобильной аналитике есть два разных мира — iOS и Android. Обычно компании делают приложение для каждой из этих платформ. Для аналитика же в них различается практически всё: архитектура приложения, профиль и поведение пользователей, команды разработки.

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

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

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