Как Growth Analytics влияет на количество активных пользователей. Применяем кейсы Airbnb и Gojek
Привет, читатели. Я Дарина Свирчевская, Sr. Marketing Analyst в Booking.com. Также я кураторка курса Growth Analytics в Projector. Сегодня хочу поделиться с вами двумя интересными кейсами использования Growth Analytics на примерах успешных стартапов. Я расскажу, как использую техники оценки состояния данных для проведения анализа в своей работе, и дам практические советы, как вы можете сделать это у себя в компании.
Я занимаюсь аналитикой более 4 лет, и у меня есть опыт работы в стартапах и больших корпорациях в Украине, Швеции и Нидерландах. За это время я поняла: чтобы быть в курсе движения, нужно иметь спектр ресурсов новой информации, состоять в комьюнити единомышленников и учиться у лучших, даже если они за 1000 км от тебя.
Кейс № 1: добиться роста продукта с помощью фикса в аналитике
Для первого примера я выбрала стартап, который одним из важных факторов своего успеха считает решение проблем с данными. Я уверена: если имплементировать идеи, написанные ниже, — результат гарантирован.
Краткая предыстория: Crystal Widjaja присоединилась к команде super-app Gojek, когда в growth-команде было всего 8 человек, а BI (business intelligence) еще совсем не существовало. Задачей Кристал было имплементировать изменения в команде аналитики, чтобы приложение стало одним из самых больших super apps в Южной Азии (super apps — приложения, которые могут удовлетворить много запросов пользователя: заказать еду, оплатить счета, заказать такси, организовать локальную доставку и так далее).
Результат, которого Crystal Widjaja с командой добились в течение 4,5 лет работы: увеличение количества заказов от 20 тыс. до 5 млн в день. Одним из ключевых составляющих успеха компании стало enabling the organization with robust and simple data systems to make data informed decisions quickly. Другими словами, они позволили данным доступно и просто подсказывать команде, какие решения принимать.
Основа для роста компании — эксперименты. Если дать возможность лидерам продуктов принимать решения намного быстрее, ориентируясь на данные как результат экспериментов, компания будет расти. Для этого важно понимать, что нужно трекать, как это трекать и как управлять этим с течением времени. Если вы не поймете, как делать эти вещи правильно, никакие инструменты не спасут.
Как часто в работе вы сталкивались с фразой: Our data is a mess? Я — часто. Даже сейчас это является одним из самых больших челленджей. Если не обращать внимание на эту проблему вовремя, со временем можно оказаться в ситуации, когда несколько аналитиков анализируют одни и те же данные по-разному с разным результатом и тратят ресурсы попусту.
Кристалл в своем рассказе о кейсе описывает четыре основных симптома хаотичных действий, связанных с данными:
Отсутствие общего «языка»
Это делает данные бесполезными. Намного больше времени уходит на то, чтобы вдумчиво обсудить их с другими командами или прийти к общему пониманию того, что они означают. Хуже того, команды могут думать, что у них есть общее понимание, хотя на самом деле это не так. Это недопонимание обычно приводит к разочарованию и отказу от использования данных вообще.
Практика: попробуйте с командой описать путь от sign-up до покупки, базируясь на дата-ивентах, и сравните терминологию. После этого упражнения вы заметите, где терминология и видение продукта не сходится, и разберётесь, как действовать дальше. Договоритесь о том, что основные ивенты должны сходится в названии, в том, как юзер может из осуществить и какой путь или пути он должен пройти, чтобы совершить именно это действие. Именно такая практика поможет обнаружить low hanging fruits.
Медленная передача знаний
Когда новый член команды присоединяется, важно правильно и системно передать ему знания, приобретенные до его прихода. Чтобы сотрудник использовал ресурс и потенциал на полную, он не должен повторять работу, сделанную до него только потому, что это не было задокументировано.
Практика: посмотрите на последний найденный инсайт: как вы его задокументировали и представили команде, есть ли к нему доступ у других команд? Они поймут, о чем идет речь и какие именно action points вы хотите выделить благодаря этому инсайту?
Как аналитик я рекомендую документировать весь процесс от самого начала до конца: с подготовки данных и до презентации инсайтов команде. Начните с того, какие data sources вы использовали для анализа. Если их было несколько, объясните, какие key values взяли для их соединения. Тут, как правило, появляются некоторые технические лимиты, которые не позволяют анализировать полный сбор данных. Если это происходит, расскажите команде, какие характеристики таких лимитов и как это влияет на результат данных. Можно ли будет осуществить анализ, базируясь на данных, которые можно достать, или в этом уже нет смысла?
По моему опыту, больше результата приносят объяснения нетехническим коллегам, с какими именно лимитами столкнулись во время анализа, как это влияет на процесс и как они должны смотреть на конечные данные. Такую процедуру проделайте на каждом этапе анализа: обязательно делитесь своим кодом и рядом с этим дайте комментарии о логике осуществления.
Недостаток доверия
Однажды, будучи еще начинающим аналитиком, я очень торопилась сделать анализ, завернуть это все в красивенький дашборд и представить команде. Я не проверила одну из самых простых и важных метрик — number of reached users. Решила представить это в абсолютном значении и не сравнила с общим числом пользователей. Как результат, количество пользователей, которые открыли письмо, превышало количество тех, кто его получил. Команда поняла, что не может доверять данным из этого дашборда, и перестала им пользоваться, даже несмотря на то, что другие метрики были предоставлены правильно. Вся работа оказалась потраченной впустую. После этого мне нужно было сместить планы по другой задачи, исправить дашборд и убедить команду, что теперь все ошибки исключены, чтобы вернуть доверие.
Представляю, что вы подумали. И правда, проверка всего дашборда на баги может занять неделю времени, ну или полноценного FTE (full time employee). Это нормальная практика — давать дашборд в использование, получать фидбэк об ошибках и дополнительных функциях и дорабатывать его. То, что вы можете с этим сделать: проверяйте основные KPIs, о которых рассказывает этот дашборд, задокументируйте шаги проведения анализа и практикуйте peer review.
Невозможность действовать быстро, базируясь на данных
Все вышеупомянутые симптомы являются частью того, что процесс принятия решения и воплощения его в жизнь занимает слишком много времени и теряет актуальность. Столкнувшись с компромиссом: тратить много времени только на получение данных, которым доверяют и которые могут понять, или пропускать этот шаг, чтобы двигаться дальше, — многие команды выберут последнее.
Тут важно уметь правильно приоритизировать и определять, какие техники приносят результат. Тратить ресурсы на анализ данных из разных источников может оказаться правильным решением, но не тогда, когда нужно действовать быстро.
Использование инструментов аналитики, которые быстро дают понять основные метрики, важные для роста, например когортный анализ, retention rate, MAU (Monthly active users), кастомные метрики, которые указывают на результативность продукта, могут служить основой. Также важно иметь инструмент для экспериментов, который показывает данные в реальном времени. Конечно, как только вы проведете свой первый успешный тест — не тяните с имплементацией.
Имея базис, можно сосредоточиться на шагах, которые более затратные по времени, но дают более глубокие инсайты.
Кейс № 2: что учитывать при принятии решений, ориентируясь на дашборд экспериментов
Этот кейс об аналитике экспериментов на примере Airbnb. Компания часто говорит о том, как эксперименты и их правильный анализ повлиял на ее рост. Об этом есть много статей в сети, но я хочу остановиться на конкретных деталях.
Airbnb выделяет четыре основных элемента для начала работы Growth-команды:
1. Чистый сет данных. На примере прошлого кейса мы поняли: неструктурированный дата-сет — одна из самых частых проблем, с которой сталкиваются команды. Это одна из главных причин, которая тормозит процесс принятия решения. Чистый набор данных, который дает возможность отслеживать нужные метрики и цели — базовый элемент в работе growth-команды.
Для этого нужно вовремя инвестировать в архитектуру и инжиниринг данных. В идеальном мире аналитики должны работать с чистым набором данных, которые подготовил инженер, настроил автоматический workflow с помощью ETL. Единственное, что ему оставалось бы делать — писать Python, R, SQL и красиво визуализировать. Я знаю немного таких аналитиков, но такие везунчики существуют.
Что же делать, когда такой роскоши нет: провести exploratory analysis с помощью Python и сделать чистку, проверить, какие значения принимают форму NULL values и почему, убрать все данные, которые не подходят, не могут быть соединены с другими данными или ресурсами данных.
2. Инструменты для сегментирования. Компания говорит о том, что возможность правильно сегментировать аудиторию помогло им сфокусировать growth marketing campaign на нужную аудиторию, чтобы получить ее в правильном месте, в правильное время и с правильным месседжем.
3. Понятный дашборд результатов экспериментов. Чтобы отслеживать результаты тестов и экспериментов, важно создать доступный для понимания дашборд для команды — для всех ее уровней. Он должен регулярно обновляться. Идеально будет иметь real time data для того, чтобы видеть результат еще во время эксперимента, а если вдруг что-то пойдет не так — его можно сразу остановить.
4. Настроить peer review процесс. Не описать лучше, чем фразой «одна голова хорошо, а две — вообще збс». Много раз я сталкивалась с моментом, когда мозг больше не может производить новых идей или инсайтов, только потому что мне как аналитику нужно соединять несколько функций в одной. Когда аналитик работает над кодом, затем сразу настраивать воркфлоу данных, а потом их презентует, может происходить слом креатива. Замечательная практика — давать работу коллеге, чтобы он посмотрел на нее под другим углом и помог определить вещи, которые уже не видны замыленным глазом.
В командах, которые работают в подобных компаниях, как Airbnb (например, Booking, Facebook, Amazon), в основном используют инструменты, разработанные самой компанией. У них есть in-house ресурсы, которые создают кастомизированные решения.
Так, например, выглядит дашборд экспериментов в Airbnb:
Сам дашборд помогает команде проводить различные эксперименты и тестировать новые фичи, прежде чем имплементировать их в продукт. Понимая то, что количество экспериментов может превышать сотни или тысячи в неделю, важно как можно раньше начать с прочной визуализации. Дашборд также становится бесценным архивом прошлых экспериментов. Как мы заметили на примере прошлого кейса, быстрая передача знаний — один из важных факторов принятия решений вовремя.
Когда у команды нет возможности разработать собственный инструмент, существуют доступные сервисы Mixpanel, Amplitude, Optimizely, Superset and Chartio для трекинга экспериментов.
В завершение хочется обратить внимание на то, что Growth Analytics в общих случаях не отличается от стандартного анализа данных. Все акценты, на которые я обратила внимание, будут полезны не только для роста компании. Совершенно нет. Но именно данные помогут принять решения, которые будут влиять на количество активных пользователей, их реактивацию или привлечение новых. Growth — это не просто buzz word современной маркетинг-тусовки, а полноценный подход, который доказывает свою пользу и результативность уже не первый год.
