[Перевод] Руководство по аналитике для основателя стартапа16.01.2018 12:18

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

Это пост о том, как создать аналитику в вашей организации. Речь пойдёт не о том, какие метрики отслеживать (об этом уже написано много хороших постов), а о том, как сделать так, чтобы ваш бизнес их генерировал. На практике выясняется, что на вопрос реализации — как мне построить бизнес, который добывает данные для принятия решений? — ответить гораздо труднее.

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

Во-первых: Почему вам стоит меня послушать?

Я почти двадцать лет проработал в аналитике. Я видел много успешных кейсов, но гораздо больше было неудачных. В начале своей карьеры я внедрял устаревший BI для предприятий (эх). С 2009–2010-го я построил первую аналитику в Squarespace и поднял крупный раунд при помощи этих данных. Потом я стал операционным директором в Argyle Social, стартапе по анализу социальных сетей, а затем вице-президентом по маркетингу RJMetrics, ведущей платформы BI для стартапов.

Теперь я помогаю руководителям стартапов внедрять аналитику, будучи генеральным директором и основателем Fishtown Analytics. В Fishtown мы начинаем работать с компаниями, после того, как они поднимают раунд A, и помогаем им по мере их роста выстраивать свою аналитику. К настоящему моменту мы прошли через процесс, который я опишу в этой статье, более чем с дюжиной компаний, включая Casper, SeatGeek и Code Climate.

Я пошагово объясню, как нужно делать аналитику на каждой стадии вашего стартапа. Мои рекомендации для каждой стадии помогут ответить на вопрос: «Каков абсолютный минимум, которым я могу обойтись?». Мы здесь не для того, чтобы строить воздушные замки; нам нужны самые дешёвые решения.
Давайте начнём.

Стадия основания

(От 0 до 10 сотрудников)

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

Что делать

Установите Google Analytics на свой сайт при помощи Google Tag Manager. Данные не будут идеальными без дополнительной работы, но сейчас не время об этом беспокоиться.
Если у вас бизнес в области электронной коммерции, то вам всё-таки нужно убедиться, что с вашими данными в Google Analytics всё в порядке. GA может проделать большую работу по отслеживанию событий вашей электронной коммерции на всем пути от посетителя до покупки, поэтому потратьте время, чтобы правильно его настроить.
Если вы разрабатываете программное обеспечение, вам необходимо отслеживать пользовательские события. Не важно, какой инструмент вы используете, — Mixpanel и Heap очень похожи и оба хороши. В этот момент я бы не особо задумывался о том, какие события отслеживать: просто используйте режим AutoTrack в Mixpanel или установки по умолчанию в Heap. Когда вы поймёте, что вам нужны какие-либо события, вы обнаружите, что они уже отслеживаются. Этот подход не очень хорошо масштабируется, но пока и так сойдёт.
Ведите свою финансовую отчётность в Quickbooks. Прогнозирование делайте в Excel. Если у вас подписочный бизнес, используйте Baremetrics для метрик подписки. Если вы занимаетесь электронной коммерцией, используйте свою торговую платформу для расчёта доходов. Не увлекайтесь.

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

Чего не делать

Ничего, что не перечислено выше. Не позволяйте никому продавать вам хранилище данных, платформу BI, большой консалтинговый проект или… ну вы поняли. Оставайтесь сфокусированными. Когда вы начинаете строить аналитику, появляются дополнительные расходы. Данные всё время меняются. Меняется бизнес-логика. Ступив на эту дорожку, вы уже не сможете поставить свой аналитический проект на паузу. Отложите большие инвестиции на потом.
Появится много вопросов, на которые вы пока просто не сможете ответить. Это нормально (на данный момент).

Очень ранняя стадия

(От 10 до 20 человек)

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

Что делать

Вероятно, вы наняли маркетологов. Убедитесь, что именно они отвечают за GA. Сделайте их ответственными за чистоту отображающихся в нём данных. Пусть они проставляют UTM-метки в каждую чертову ссылку, которую создают. Пусть убедятся, что ваши поддомены не отслеживаются дважды. Ваши маркетологи могут сказать, что они «не шарят в GA». Не слушайте их. В Интернете достаточно информации о GA, так что, если они умны и мотивированы, они могут научиться и разобраться в этом. Если они не могут разобраться, увольте их и найдите кого-нибудь другого (серьёзно).
Если у вас есть отдел продаж и есть CRM, используйте встроенную отчётность. Убедитесь, что ваши люди знают, как ей пользоваться. Вы должны быть в состоянии посчитать основные вещи, такие как эффективность продаж и коэффициенты конверсии по шагам воронки продаж. Salesforce может делать это из коробки. Не экспортируйте данные в Excel, сформируйте отчеты в их (ужасном) построителе отчетов. Даже если сейчас вам неудобно, это сэкономит вам массу времени в ближайшие месяцы.
Вероятно, у вас есть несколько человек в службе поддержки. В большинстве систем службы поддержки нет хорошей отчётности, поэтому выберите такие KPI, которые вы можете легко измерить в их интерфейсе.
Удостоверьтесь, что вы измеряете NPS. Используйте Wootric или Delighted.

Чего не делать

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

Ранняя стадия

(От 20 до 50 сотрудников)

Именно тут всё становится интересным, а изменения за последние два года — очевидными. Как только вы поднимете свой раунд A и у вас будет 20+ сотрудников, у вас появятся новые возможности.

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

Это самый сложный и наиболее важный этап: многообещающий, если вы всё сделаете правильно, но болезненный, если неправильно.

Что делать

Настройте инфраструктуру данных. Это означает выбор хранилища данных, инструментов ETL и BI. В качестве хранилищ данных рассмотрите Snowflake и Redshift (я предпочитаю работать со Snowflake, если есть выбор). В качестве инструмента ETL возьмите Stitch 1 или Fivetran. Что касается BI, то посмотрите на Mode и Looker 2. В этой области много, очень много продуктов; эти шесть — те, к которым мы снова и снова возвращаемся с нашими клиентами.
Возьмите сильного руководителя аналитики. По дороге вам понадобится целая команда специалистов по аналитике: инженеры, аналитики, data scientists… Но пока вы можете позволить себе (не более) одного человека в штат. Вам нужно найти того особенного человека, который принесёт пользу в первый же день, но который также сможет нанять команду вокруг себя по мере роста. Этого человека трудно найти — потратьте время на его поиск. Часто такие люди имеют опыт в области консалтинга или финансов, и у них часто есть MBA. Хоть этот человек и должен быть готов закатать рукава и замарать руки, сосредоточьтесь на найме кого-то, кто может думать о данных и о вашем бизнесе стратегически: он станет важнейшей частью вашей аналитической головоломки в течение многих лет.
Подумайте о найме консультанта. Хотя здорово, что вы нашли руководителя аналитики, у этого человека не будет опыта, необходимого для объединения всех компонентов вашего технологического стека или для решения всех проблем с аналитикой, с которыми вы столкнетесь в вашем бизнесе. Ошибки, сделанные на этом критическом этапе, обернутся серьезными затратами как во времени, так и деньгах, когда вы будете расти, поэтому важно заложить прочную основу. Чтобы сделать это, сегодня большинство стартапов предпочитают работать с консультантами, чтобы помочь им настроить инфраструктуру, а затем создать команду вокруг неё.

Чего не делать

Если машинное обучение не является основной частью вашего продукта, пока не нанимайте data scientist-а. Для создания вашей аналитической команды вам нужен универсал, а не узкий специалист.
Во имя всего святого, не пишите свой собственный ETL. Вы потратите на разработку кучу времени. Купите готовые решения от Stitch или Fivetran.
Не используйте никакой другой инструмент BI, кроме двух упомянутых выше. Иначе это обернётся вам потом большими тратами.
Не пытайтесь обойтись более традиционной базой данных, типа Postgres, в качестве вашего хранилища данных. Она не намного дешевле, и вы потратите кучу времени, чтобы мигрировать с неё позже, когда исчерпаются её возможности. Postgres не масштабируется так же хорошо, как настоящее хранилище данных.

Средняя стадия

(От 50 до 150 человек)

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

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

Что делать

Реализуйте надежный процесс моделирования данных на основе SQL. Ваши модели данных служат основной бизнес-логикой для вашей аналитики и должны использоваться во всех случаях — от BI до data science. Убедитесь, что ваш процесс позволяет всем пользователям вносить изменения в скрипты моделирования данных, версионируется и запускается в прозрачной среде. Мы поддерживаем продукт с открытым исходным кодом, называемый dbt, который используется многими компаниями в стадии роста именно для этого.
Мигрируйте из существующих систем веб-аналитики и отслеживания событий в Snowplow Analytics. Snowplow делает всё, что делают платные инструменты, но это продукт с открытым исходным кодом. Вы можете либо хостить его самостоятельно (и просто оплачивать расходы на свои экземпляры EC2), либо платить за размещение сборщика событий в Snowplow или Fivetran. Если вы не сделаете переход на этом этапе, вам не удастся собрать гораздо более подробные данные, и приготовьтесь к реально огромным счетам из Segment, Heap или Mixpanel в ближайшем будущем. Когда вы пройдёте этот этап, платные инструменты могут с лёгкостью брать с вас по 10 000 долларов в месяц.
Развивайте свою команду вдумчиво. Ядром вашей команды всегда должны быть бизнес-аналитики: люди, которые являются экспертами в SQL и вашем инструменте BI, и тратят своё время на работу с бизнес-пользователями, чтобы помогать им получать данные. Невероятно важно выяснить, каков профиль этих людей, как их обучать и экипировать. Вы также должны нанять своего первого data scientist-а на этом этапе. Важно собрать вашу инфраструктуру данных и основную команду аналитики до найма опытных (и дорогих) талантов в области науки о данных, но в какой-то момент вы должны будете добавить и эти навыки.
Начинайте выборочно решать некоторые проблемы прогнозирования. Прогнозирование сложнее, чем просто вычисление количеств и сумм, но есть несколько ключевых областей, в которые имеет смысл начать погружаться. Если вы работаете в SaaS, вы должны работать над моделью прогнозирования оттока. Если вы занимаетесь электронной коммерцией, вам совершенно необходимо работать над моделью прогнозирования спроса. Эти модели, возможно, не будут супер сложными, но они будут большим улучшением по сравнению со случайными числами в Excel-таблице, которую соорудил кто-то из финансового отдела.
Потратьте время и силы, чтобы разобраться с маркетинговой атрибуцией. Про это можно написать отдельный пост, но достаточно сказать, что вы просто не можете доверить эту критическую бизнес-задачу третьей стороне.

Чего не делать

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

Упорно проталкивайте SQL и ваше хранилище данных. На этом этапе вы можете справиться с чем угодно, используя вычислительную мощность вашего хранилища данных. Купите столько мощностей в хранилище данных, сколько вам нужно — платить за серверы намного дешевле, чем платить за людей.
Добавьте Jupyter Notebooks для задач data science. Если данные были предварительно агрегированы в вашем хранилище, вам не понадобится делать обработку в кластере Spark или Hadoop.
Найдите недорогие способы делать ETL таких данных, для которых нет готовых интеграций. Это одна из вещей, за которые мы любим Singer. 3
Избегая затрат на мартышкин труд, вы будете сосредоточены на решении реальных бизнес-задач.

Стадия роста

(От 150 до 500 сотрудников)

Этот этап связан с созданием аналитических процессов, которые масштабируются. Вам необходимо балансировать получение ответов, необходимых сегодня, с внедрением аналитических методов, которые будут масштабироваться по мере продолжения роста вашей команды.
К моменту, когда у вас будет 150 сотрудников, вероятно, из них только небольшая команда (3–6 человек) будет заниматься исключительно аналитикой. К тому времени, когда у вас будет 500 сотрудников, таких легко может стать 30 и больше. 3–6 аналитиков могут действовать довольно бессистемно, обмениваясь знаниями (и кодом) неформальным образом. К тому моменту, когда у вас будет 8+ аналитиков, процесс начнёт очень быстро разваливаться.
Если вы не справитесь с этим переходом, вы фактически будете работать всё хуже и хуже по мере того, как ваша команда растёт: вам понадобится больше времени, чтобы добывать полезные инсайты, и ваши ответы будут более низкого качества. Просто это нелинейный рост сложности: у вас будет всё больше данных и всё больше аналитиков, работающих с ними. Чтобы бороться с этим, вам нужны процессы для надёжной совместной работы.

Что делать

Внедрите тестирование данных. На данный момент у вас есть данные, поступающие в ваше хранилище по крайней мере из десятка источников, и вам нужен процесс для обеспечения того, что загружаемые данные продолжают соответствовать предъявляемым к ним требованиям: уникальность, отношения внешних ключей, ненулевые поля, кастомная бизнес-логика. Если у вас нет надёжного автоматизированного процесса, который проверяет эту историю, качество вашего анализа будет продолжать ухудшаться, и вы не будете знать, почему. Мы с нашими клиентами используем в этих целях функционал тестирования в dbt.
Используйте пул-реквесты и code review. Ваш аналитический код является активом, точно так же как код вашего сайта и приложения. Создание высококачественного кода требует серьёзного контроля версий. Добавьте каждого члена вашей команды в git, научите их пользоваться ветками и отключите пуши в master. Весь код, который отправляется в продакшен, должен пройти через пул-реквест с обязательной рецензией от другого члена команды. 4
Отнеситесь серьёзно к документации. У вашей компании сложная инфраструктура данных. Единственный способ эффективно управлять знаниями о ней и поделиться ими с вашей командой — это потратить время и энергию на её документирование. Это добавит некоторые накладные расходы, но если вы не сделаете эти инвестиции, вы обнаружите, что ваши аналитики тратят больше времени на выяснение, где получить нужные данные или как их использовать, чем на саму аналитику. Airbnb отлично поработал в этой области.
Продумайте структуру вашей аналитической команды. Существуют две основные модели структурирования аналитической команды: централизованная и встроенная. Тут нет чёткого правильного ответа, но это решение будет иметь решающее значение для того, как вы приносите аналитику в свою растущую организацию. Карл Андерсон хорошо описывает компромиссы в своей книге «Creating a Data-Driven Organization». 5

Чего не делать

Не принимайте оправдания. Делать аналитику на этом уровне — тяжелая работа, и для этого требуется талантливая и мотивированная команда, которая постоянно придумывает что-то новое и совершенствуется. Code review требует времени и энергии. Аналитики не привыкли проверять свой код. А документирование — кропотливый труд. Вы встретите сопротивление этим практикам, особенно среди старых членов вашей команды, которые помнят «старые добрые времена». Но по мере того как сложность возрастает, вам нужно развивать свои процессы, чтобы адаптироваться к ней.
Эти процессы на самом деле делают аналитику проще, быстрее и надёжнее, но их реализация напоминает выдёргивание зубов. Если вы серьёзно отнесётесь к масштабированию аналитики, то продвинетесь вперед.

Вы пионер

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

От переводчика

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

Последние 16 месяцев я фактически провожу в Skyeng как раз те изменения, которые тут описаны. Когда я пришёл в компанию в октябре 2016-го, мне пришлось собирать data warehouse, строить инфраструктуру данных, организовывать единый доступ к данным для всей компании. Затем я собрал распределенную команду из SQL-аналитиков, прикреплённых к различным бизнес-юнитам, настроил коммуникацию между ними, процессы code review и шаринга результатов. Сейчас у нас 20 аналитиков, помимо меня, и я выстраиваю децентрализованную схему управления этой структурой.

Спасибо Тристану, сейчас я вижу, что двигался в правильном направлении и не наступил на большинство граблей.

Примечания

1. Про облачный ETL из коробки при помощи Stitch можно подробнее почитать в моей статье на Хабре.

2. Я последние 2 года работаю с Redash — он на порядок дешевле Mode и покрывает почти все кейсы, кроме разве что python notebooks. Looker, к сожалению, официально не работает с компаниями из России.

3. Singer — это простой фреймворк от создателей Stitch с открытым исходным кодом, который позволяет писать кастомные коннекторы к источникам данных на python. Например, мы сделали при помощи него свой коннектор к Typeform, чтобы перманентно собирать результаты опросов пользователей.

4. Мы в Skyeng пока не доросли до правильного code review аналитики при помощи пул-реквестов, но я написал простой скрипт, который забирает из Redash все новые SQL-запросы, кладёт в master, назначает ревьюера и делает пост об этом в Slack. Так мы не теряем в скорости, но получаем стабильно работающий процесс review пост-фактум по горячим следам.

5. Книга вышла в 2017-м году на русском под названием Аналитическая культура.
От сбора данных до бизнес-результатов.