Все мы знаем, что данные лучше гипотез, а успех любого проекта строится на грамотной аналитике. Что начинать собирать информацию о том, как реальные люди используют ваш продукт, следует сразу после его запуска. Однако в реальности мало кто начинает работать над аналитической стратегией на ранних этапах проектирования. Чаще всего решения о том, какие данные и события отправлять в эту самую аналитику, принимаются сильно позже. О развитии аналитической стратегии, к сожалению, редко задумываются вообще.
В этой статье мы поговорим о том, какие последствия это за собой влечёт и что можно сделать, чтобы упростить себе жизнь, улучшить архитектуру и ускорить развитие продукта.
Вот только сперва я хотел бы быстренько синхронизировать с вами определения.
1. Аналитическая стратегия
Одна из серьёзнейших проблем в IT – это терминология. Бешеная скорость развития технологий и методик заставляет термины изменяться и вырастать из своих прежних определений. Так было с UX, с персонами, с API и даже с названием множества IT-профессий.
Говоря об аналитической стратегии, я подразумеваю совокупность подходов и решений, направленных на сбор и анализ данных о пользователях, включая данные с клиентских устройств. Сюда входит не только отправка переходов, событий, рекламных идентификаторов и прочего во внешние системы аналитики, но и работа с системами внутренними.
Например, с помощью связки Amplitude и Branch мы собираем сквозную аналитику в мобильном приложении, оцениваем конечную эффективность каналов привлечения, косвенно выясняем удобство нашего интерфейса и определяем качество конверсии. Тогда как с помощью внутренней аналитики мы можем выяснить, к примеру, процент регулярно платящих клиентов и скорректировать прогнозы окупаемости. Или определить средний уровень заполняемости профиля пользователя и принять меры по его улучшению.
Работа над аналитической стратегией заслуживает отдельной статьи. Если это кажется вам интересным, пишите в комментариях. Может быть, имеет смысл сделать на эту тему отдельный лонгрид.
Итак, если с этой частью терминологии мы определились, идём дальше.
2. Проблема обновлений
Представим себе условного дизайнера/проектировщика/аналитика. Он работает над крупным проектом уже не первый месяц. Он знает все ключевые точки сценариев, он понимает, что и когда нужно отправлять в мобильную и веб-аналитику. Он умный и опытный, и поэтому с лёгкостью составляет список таких переходов и событий, уже заранее простраивая многосоставные цели в метриках.
Приходит время, и он передаёт документацию в разработку. Представим даже, что он осуществляет авторский надзор, и все требования к продукту, включая аналитические, выполняются неукоснительно.
Что происходит дальше? Продукт запускается, начинают появляться первые клиенты. Некоторое время данных из аналитики хватает, но потом возникает необходимость расширить или вовсе поменять список отправляемых эвентов. Например, в одной из веток ключевого сценария вдруг начинает падать конверсия – и нужно срочно выяснить, почему. Аналитик приходит к разработчикам и просит добавить к отправке пару событий на странице профиля.
И вот тут начинается самое интересное. Добавить события не сложно, сложнее заставить всех пользователей обновить приложение, чтобы эти события там появились.
И если вы думаете, что это касается только мобайла, то зря: скрипты веб-приложений кэшируются в браузерах пользователей, и не всегда изменения появляются у них мгновенно. Иногда реально проходят недели, прежде чем кэш устареет. Конечно, можно изменить настройки заголовков сервера или добавить версионность скриптам, но это в итоге сказывается на скорости загрузки страниц и, как следствие, на оценке поисковыми системами, типа Google или Яндекса.
С мобильными приложениями вообще мрак. Допустим, наши разработчики внесли нужные изменения. Они отправляют новую версию на ревью, и она благополучно оседает там на несколько дней, а то и недель. Пока AppStore и Google Play проводят проверку приложения, данные, разумеется, не собираются. И даже после этого пользователи скачивают обновление не сразу, процесс может затянуться надолго. За это время появляются новые требования к сбору, и цикл повторяется.
Такой подход заставляет аналитиков, маркетологов и владельцев продукта находиться в перманентном состоянии ожидания.
Ну и что, скажете вы. Все уже привыкли к такому раскладу, в нём нет ничего необычного или плохого. А вот и есть. Мало того, что при этом падает условная эффективность специалистов, так ещё и существенно замедляется скорость развития продукта – что в динамичных условиях рынка чаще всего лупит по конкурентоспособности.
3. Ошибочное решение
Самый простой способ, который сразу приходит на ум – это заранее заложить в отправку все события, даже самые незначительные. Авось, понадобятся. Разумеется, так делать нельзя.
Во-первых, отправка событий, чаще всего, стоит каких-то денег: например, тот же Amplitude позволяет бесплатно отправлять только 10 миллионов эвентов в месяц. Это только кажется много: если у вас даже 2 тысячи ежедневных пользователей, вы исчерпаете этот лимит, отправив с каждого всего по 170 событий в сутки, включая переходы между экранами.
Во-вторых, частая отправка данных повышает нагрузку на сеть (зачастую мобильную), в разы увеличивает сложность обработки ошибок и в целом ухудшает архитектуру продукта.
Ну и в-третьих, излишняя информация будет мешать грамотной аналитике. Данные – не деньги, их вполне может быть слишком много. «Мусор» в аналитических отчётах мешает принимать взвешенные решения, на обработку большого объёма уходит больше ресурсов.
В итоге получается, что даже плотное «усеивание» интерфейса событиями не приводит к желаемому результату.
4. Система триггеров
А теперь представьте, что изменять список отправляемых в аналитику событий можно в реальном времени. То есть действительно в реальном: как только пользователь открывает ваш сайт или приложение, система сама подтягивает актуальный список эвентов.
Вот как должна выглядеть идеальная схема:
На самом деле, сделать это просто, понадобится всего 5 этапов, 3 из которых и так осуществляется большинством аналитиков.
4.1. Формирование списка претендентов
В самом начале мы формируем полный список событий, которые нам когда-либо могут понадобиться. Сюда можно включать даже совсем мелкие эвенты, вроде ошибок заполнения полей профиля.
Заметьте, мы не отправляем их сразу в аналитику, а просто составляем перечень. Это можно сделать где-нибудь в Google Sheets или любой другом табличном редакторе.
4.2. Присваивание идентификаторов
Затем мы присваиваем каждому событию внутренний идентификатор. Важно, чтобы такие идентификаторы были действительно уникальными для каждого эвента. Желательно также, чтобы они собирались по некоторой схеме – так будет проще потом с ними работать.
Опытным аналитикам эта работа во многом уже знакома, но я всё равно о ней расскажу.
Вы можете придумать собственные правила создания таких айдишников, или воспользоваться моими, сформированными на базе событий из Google Analytics:
- Первым указывается инициатор события. Это могут быть, например: «посетитель», «покупатель» или система.
- Далее указывается название самого действия (например, «шэринг через соцсети» или просмотр).
- После этого можно добавить ярлык – какую-то особенность события, если оно, к примеру, может быть выполнено несколькими способами или касаться разных типовых объектов.
- Иногда в конце нужно установить значение. Это числовой параметр, как правило – динамический. Например: «id поста» или «время загрузки видео».
- Все идентификаторы пишутся на английском языке в нижнем регистре;
- Метки разделяются нижним подчёркиванием, а слова внутри самих меток – с помощью тире.
Пример составленного таким образом идентификатора:
user_post_social-share_facebook_235
4.3. Приоритизация списка
Следующим этапом мы выясняем, какие события точно будут нам нужны сразу после запуска продукта. Как правило, это все переходы между экранами и какие-то ключевые действия пользователя, вроде добавления товара в корзину.
Эти события и переходы мы станем собирать в первую очередь – но это вовсе не значит, что такой список является окончательным. Если нам понадобится, то уже через несколько дней после релиза мы сможем изменить перечень эвентов.
Пока что всё знакомо и понятно, да? Первые три шага в той или иной мере выполняет каждый аналитик. Интересное начинается на шаге четвёртом.
4.4. Работа с кодом и конфигами
Итак, у нас есть на руках отсортированная по важности таблица со списком событий-триггеров. Мы понимаем, в какой момент мы шлём каждое, у всех уникальные и логично сформированные идентификаторы. Самое время обратиться к разработчикам.
Наши программисты делают простое упражнение: они пишут отдельную функцию, которая может быть вызвана из любого места приложения. Эта триггерная функция принимает в себя только один параметр – идентификатор события. Когда она вызывается, то проверяет наличие идентификатора в списке необходимых к отправке – и, если он там присутствует, отправляет данные в аналитику. Конкретные параметры для отправки она может брать прямо из айдишника или из связанного с ним массива (для тех, кто любит заморачиваться).
Разработчикам остаётся повесить эту функцию на все указанные в таблице триггеры, а рядышком положить файлик конфигурации со списком «активных» событий, на которые нужно реагировать – именно к нему будет обращаться функция, когда потребуется проверить, надо ли отправлять эвент.
4.5. Добавление механизма обновления
Теперь нам остаётся просто сделать так, чтобы этот файлик, в котором указан текущий перечень событий для отправки, получался с сервера сразу после инициализации нашего приложения. Разумеется, этот процесс выполняется в фоновом режиме и не должен влиять на скорость запуска.
Мы можем пойти дальше и сперва просто запрашивать с сервера версию этого файла – и если она отличается от сохранённой локально, то уже тогда получать весь обновлённый массив событий. В ряде случаев мы можем вообще объединить этот файл с остальной конфигурацией приложения.
Всё. Теперь, если нам нужно поменять события для отправки, мы просто заменяем/правим конфиги на сервере – и приложение само понимает, что теперь в аналитику нужно слать новые данные. Profit.
5. Вместо эпилога
Я знаю, что некоторые компании и даже отдельные аналитики уже применяют такой или подобный подход. Это неудивительно, я сам его использую уже больше пяти лет подряд. Однако по роду деятельности мне приходилось и приходится работать с большим количеством проектов и команд, а система триггеров или её аналоги встречаются крайне, крайне редко. Хотя реализация её не стоит каких-то колоссальных или даже просто всерьёз значимых ресурсов.
Надеюсь, что теперь ситуация хотя бы немножко изменится. Кому-то станет проще обновлять аналитические данные, а некоторые проекты будут развиваться чуть более динамично.
