Кейс 500px: Создание системы аналитики для крупного фотохостинга с нуля

Бывший аналитик фотохостинга 500px Евгений Чеботарев написал заметку о том, как он с нуля разрабатывал систему аналитики для сервиса, с какими проблемами столкнулся и какими способами и инструментами он их решил.

В рубрике Growth Hacks — перевод заметки.

Я не колебался, когда решил присоединиться к проекту
500px в качестве руководителя аналитического отдела. Я увидел невероятную возможность, на которую пустили бы слюни большинство аналитиков — шанс построить аналитическую функцию с нуля для стартапа с большими амбициями. Таким образом, я мог воплотить мое видение того, как могла бы выглядеть компания, управляемая на основе данных.

Это место, где:

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

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

Но трудности меня совсем не пугают — я сразу же взялся за проект.

Прошел уже год с тех пор как я в проекте.

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

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

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

Я дам свое видение этой проблемы.

Некоторые общие сведения

Компания

500px — сообщество по обмену фотографиями, а также рынок фотоматериалов. Наша платформа включает в себя веб-сайт для настольных компьютеров и его мобильная версия, мобильные приложения для Android и iOS, также как и приложения сторонних производителей, например, Flipboard. Нас поддерживают первоклассные инвесторы, в том числе Andreessen Horowitz и Venture Capital.

У нас есть два основных потока доходов:

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

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

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

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

Технологический стек

Все наши приложения и веб-сайты работают на наших собственных API-серверах. На этих серверах мы разместили монолитное приложение Rails, а также несколько микросервисов. Они поддерживаются несколькими базами данных, главная из которых MySQL.

На MySQL хранится информация по отслеживанию состояний наших приложений. Важнее всего две таблицы данных: фотографии и пользовательские таблицы. У нас даже есть данные по покупке подписок и покупке из фотобанка.

Мы регистрируем API-вызовы и изменения состояний на серверной стороне. Например, здесь регистрируются вызовы размещения фотографии на сервере, также как и действия вроде регистрации, загрузки фотографий, голосовании или подписке на пользователя.

На случай, если вы не знаете, журнал регистрации состоит из простых текстовых файлов. Когда мы регистрируем какое-то действие, мы просто добавляем запись, в виде строчки, которая выглядит как:
2015–02–10 10:24:31.32444 23432423 photo_like 423223 123.132.623.123 /get?…

В каждой такой строчке могут быть записаны временная отметка, id фотографии, пользовательский id, пользовательский ip, действия пользователя и все, что релевантно. Все это дает нам историю деятельности на нашей платформе, которая дополняет структурированную информацию, которая есть на MySQL. Эти записи собираются и архивируются в S3 каждый час. Мы собираем около 20 ГБ файлов записей в день.

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

Путь к улучшению аналитики

Теперь, когда вы немного знаете о компании и наших технологиях, посмотрим на изменения нашей аналитики.

Два источника данных

Когда я только начал работу, мне представили два источника данных, с которым я мог работать: Splunk и MySQL. MySQL мог давать состояния, такие как, например, общее количество лайков на одной фотографии, но я не мог получить данных о том, сколько лайков поставили этой фотографии за последний час. Splunk — это движок для поиска по журналам записей “on top of logs».

Записи журнала событий могут многое вам сказать о пользовательском поведении. Когда пользователь лайкает фотографию, это действие записывается в журнал событий и у него появляется временная отметка. Поэтому, благодаря записям из журнала событий, вы можете получить информацию о том, как много лайков получило фото за последние несколько часов, просто просмотрев строки записей и отметив каждую строчку, где есть событие «лайк» по определенной фотографии.

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

Например, меня интересуют следующие вопросы:

Сколько фотографий в среднем загружает пользователь за одну сессию?
Сколько пользователей android пользовалось нашей платформой за последний месяц?

Splunk может просмотреть журнал событий строчка за строчкой очень быстро, и посчитать количество событий, которые соответствуют запросу.

Две головные боли

Запросы по этим двум ресурсам были довольно простыми. Если мне нужна была информация по состояниям, я делал запрос через MySQL. Если я хотел получить данные по пользовательскому поведению, то запрос делался через Splunk.

Но, если вам нужна информация, касающаяся и поведения и состояния, например, сколько пользователей поставили «лайк» на определенном фото за прошлый месяц (Splunk), с разбивкой по типу пользовательской подписки (MySQL), то вам понадобится какой-нибудь способ для офлайн-запроса из этих двух источников данных по отдельности. А затем вам нужно найти способ скомбинировать оба. Для подобных запросов я пользовался Python и библиотеками MySQL и Splunk.

Это еще небольшая головная боль. Времени было недостаточно, чтобы написать пользовательский код для организации сбора данных. Но была проблема и больше.

Эти два источника данных не были удобны в использовании. В Splunk есть специальный язык запроса, по которому существует несколько онлайн-ресурсов. А схемы в MySQL были плохо задокументированы. Таким образом, ответственность за сбор данных ложится только на аналитика.

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

Панель инструментов для руководства — Пуститься наутек

Нисколько не легче было в отчетности по метрикам.
Мы пользовались Splunk чтобы подсчитывать некоторое количество событий (подписки, загрузки и т.д.) по дате и клиентам (веб, iphone, android и т.д.). Результат этих поисков через Splunk сохранялся в Google Sheet, и дублировался на Exec Dashboard, передавая параметры по скрипту, который запускался каждую ночь:

Информационная доска наших руководителей. Цифры здесь указаны случайные

Только представьте, что для того, чтобы понять, как изменяются базовые метрики, такие как ежедневно активные пользователи, приходится обрабатывать тысячи цифр.

Было очевидно, что кое-что пора менять. Например, данные не были доступны. В течение четырех месяцев меня заваливало сборами данных, и я вполне мог бы сменить название должности на Data Monkey. Трудно было винить инфраструктуру, особенно потому, что я был новым в компании. И во-вторых, было трудно понять, как шли дела и у продукта и у компании. Лишь немногие могли понять наши метрики. Информационная доска для руководства была катастрофой.

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

После того, как инфраструктура была построена, мне надо было переделать отчетность и продвинуть новую систему в остальных отделах компании.

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

С точки зрения инфраструктуры мне надо было всего две вещи:

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

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

В следующих двух разделах статьи я буду рассказывать о внедрении базы данных Redshift и проекте Periscope. А после я расскажу о переформировании отчетности по метрикам с помощью Periscope и Google Sheets.

Новая инфраструктура. Часть 1 — Redshift

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

Инструкция по моделированию Dimensionality

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

У размерных хранилищ данных есть специальная схема с двумя типами таблиц, которые называются таблица фактов и размерная таблица. Данные поступают из источника (MySQL и logs) и преобразуются в эти два вида таблиц в процессе Extract-Transform-Load (ETL).

ETL и схема размерного хранилища данных

Схемы хранилищ данных имеет два типа таблиц:

Таблица фактов записывает измерения во время процесса.
Размерная таблица записывает информацию о каком-то определенном предмете.

Обе таблицы должны быть понятными. В них должны быть читаемы имена колонок и значения.Например:

Таблица фактов по «лайкам» имеет следующие колонки: дата-время, id_пользователя, id_фотографии, клиент.
«Размерная» таблица по пользователям содержит колонки: id_пользователя, имя_пользователя, имя, фамилия, …, тип_подписки, …, продавец, …, есть_приложение_android, …

Пример использования этой схемы: если мы хотели знать, сколько лайков было поставлено за последнюю неделю, мы могли сделать запрос через таблицу фактов по «лайкам», суммировать записи и сделать фильтр по дате.

Но если бы нам была нужна разбивка лайков по типу пользовательской подписки, то запроса через таблицу фактов было бы недостаточно. Параметр
тип_подписки не содержится в таблице фактов по «лайкам». А id_пользователя содержится. Тогда бы нам потребовалось объединить таблицу фактов по «лайкам» с «размерной» таблицей по id_пользователя, а затем сгруппировать данные по типу_пользовательской_подписки.

Из этого примера легко сделать вывод, почему
таблицы фактов часто содержат внешние ключи к «размерным» таблицам. Это делается для того,чтобы их можно было объединить, так что факты можно отсортировать по размерам.

ETL

Чтобы заполнить наше хранилище данных данными из наших производственных баз данных и журналов событий, мы применяли процесс, называемый ETL.

Хранилище данных очень сильно отличается от производственных баз данных и журнала событий. Таблицы часто денормализованы, а их многокомпонентность скрыта. Например, чтобы увидеть есть ли у пользователя активная подписка, нам, возможно, придется написать сложный запрос, включающий в себя сбор данных из разных таблиц. Но в хранилище данных пользовательская таблица должна просто содержать колонку «да/нет».

Из-за этого нам приходится трансформировать данные после того, как мы вытащим их из источника и загрузим в хранилище данных. Отсюда и название процесса E-T-L (Extract-Transform-Load). Если избегать многокомпонентности, делая запросы данных через процесс ETL, то доступ к данным становится проще и допускается меньше ошибок.

Создание схемы

К этому времени я провел несколько месяцев, вытаскивая данные и проводя анализ специального вида. Принимая во внимание мои прошлые запросы, я получил ряд требований к таблицам:

Таблицы фактов: Покупка подписки, покупка из фотобанка, загрузки, регистрация, лайки, добавление в избранное, подписка на пользователей, …
«Размерные» таблицы: Пользователи, фотографии.

Казалось, что это золотая середина между невыполнением достаточного количества требований и чрезмерным техническим усложнением системы. Но удовлетворяет ли эта схема наши потребности?

Эта модель данных содержит и журнал событий и данные MySQL в одном месте, где не требуется дополнительной работы по их совмещению. Ее просто понимать и читать. Все сложные запросы, например, такие как определение типа аккаунта пользователя, которые мне приходилось выполнять, теперь были скрыты в ETL. Запросы с помощью этой модели данных — настоящее удовольствие.

Но иногда наших моделей данных просто не хватает:

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

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

Amazon Redshift

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

Есть некоторые технические требования к базам данных, которые могут поддерживать «размерные» модели. Главные операции для таких баз — агрегирование и соединение. Эти две операции очень затратны на традиционных базах данных, и должен быть информационный массив для приложений. Попробуйте объединить 100 миллионную таблицу с 500 миллионной таблицей в MySQL. Даже Postgres тут дрогнет. Нам было нужно что-то более специализированное, разработанное специально под нужды аналитики.

К счастью для нас, существует дешевая, простая в использовании и поддержке база данных, которая оптимизирована специально под аналитические запросы, такие как соединение и агрегирование: Amazon Redshift на AWS. База данных Redshift с двумя террабайтами дискового пространства — этого вполне достаточно для наших нужд, а стоит она чуть больше 4 тысяч долларов в год.

Создание ETL

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

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

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

В MySQL такой колонки нет. А так как мы делаем такие подсчеты только ночью, то к тому времени, как пользователь продлит свою подписку, мы уже не сможем проверить был ли он ранее нашим активным подписчиком. Единственная колонка, которая у нас есть, — это «активен». Поэтому нам придется создать новую таблицу только для использования в процессе ETL, которая будет хранить записи об активных подписчиках на конкретную дату.

В этой таблице мы оставили колонку «присоединились», и убрали данные о тех, кто ранее уже был активен, получив таким образом исправленный счетчик новых подписчиков. То же самое мы делаем, чтобы добавить пользователей в колонку «обновленный».

Производственные схемы просто ужасны для аналитики. Соответственно скрипт ETL, целью которого было преобразование запутанных производственных данных в чистое хранилище данных, вполне естественно станет очень запутанным.

Пользуйтесь такой инфраструктурой как
Luigi или таким инструментом как Informatica. Они содержат всем хорошо известные стили оформления кода и концепции кодирования, кроме того, они широко распространены. Всё равно аналитика будет довольно запутанной. Но она хотя бы будет сравнимой с известными способами проведения ETL.

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

Для создания каналов ETL, я предпочитаю работать в Luigi. На это есть множество причин:

Luigi создан и поддерживается Spotify. Он используется в тысячах стартапов по всему миру. У них активна рассылка и постоянно растет сообщество.
Luigi это приложение с открытым исходным кодом и оно расширяемо. Вполне понятно, как все работает, а расширение количества базовых классов не возбраняется.
Luigi создан на Python, популярном языке для обработки информации.
Код Luigi легко читаем. Базовыми элементами Luigi являются классы задач, которые формируют первичные операции ETL. Они состоят из трех частей. Требования, в которых есть указатели на другие задания, которые следует выполнить до этого задания, шаг по транфсормации данных и результат. Таким образом, каждое задание это узловой пункт в ориентированных графах — работа ETL. Luigi даже сможет визуализировать для вас этот график с помощью функции визуализации, он так же может дать диагностическую информацию о каждом запуске ETL.
Когда код структурирован таким образом, то читать и поддерживать его гораздо проще. Здесь есть и иерархия и отношения. Я также вношу все задачи, которые feed в финальную таблицу на Redshift в один файл. Это позволяет мне быстро увидеть структуру кода и изолировать те его части, которые меня интересуют.

Ориентированный граф Luigi

Luigi является идемпотентным. Это означает, что если запустить его два раза подряд, один за другим, то ничего не произойдет. Он просто перезапустит части кода заново, если вы уже удалили результат предыдущих задач. А это просто невероятно помогает во время отладки. Если запуск прерывается на каком-то определенном пункте, вам просто надо исправить этот пункт, а затем запустить процесс заново. Вам не придется изолировать эту часть кода методично запускать его изолированно.
В Luigi предусмотрена рассылка-оповещение с данными по регистрации ошибок и статусу выполнения. Вы получите уведомление, если во время запуска произошел сбой на каком-то этапе. Вы можете посмотреть запись отслеживания стека ошибок, поправить код и перезапустить ETL.

После того, как я написал ETL в Luigi, у меня было около 200 ключевых пунктов в ориентированном графе. Эти действия включали в себя извлечение данных из MySQL, загрузку данных в S3 и загрузку всего этого с S3 на Redshift. Один определенный пункт запускает Elastic Mapreduce Instance, чтобы парсить данные журнала событий и трансформировать их в данные таблицы фактов, которые сохраняются на S3, а затем загружаются на Redshift.

Полный цикл запуска ETL занимает приблизительно четыре часа. Я сделал настройки так, чтобы процесс запускался каждую полночь.

Хранилище завершенного сбора данных

Вот это и есть наша модель сбора данных — храним мы их на Amazon Redshift, и дополняем новыми данными ежедневно посредством каналов ETL, запускаемых на Luigi.

Сразу же после внедрения, вы поймете, что не учли в требованиях несколько вещей. Люди буду просить вас вносить множество изменений в схеме, потому что им обязательно понадобится какая-нибудь дополнительная колонка в анализе. Вы заметите, как нарушается часть ETL, потому что инженерный отдел вносит изменения в производственные данные даже не предупредив вас.

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

Есть несколько способов проверить, что данные в хранилище данных точны. Подробнее об этом будет написано чуть ниже.

В целом, управление этим хранилищем данных обойдется вам менее 8000 тысяч долларов в год. И это сопоставимо с традиционными решениями по хранилищам подобного масштаба.

Новая инфраструктура. Часть 2 — Periscope

Когда хранилище готово, появляется необходимость в инструменте, который можно использовать внутри компании, и чтобы у каждого был к нему доступ. Я оценивал несколько популярных вариантов:

Самое простое и дешевое решение — дать каждому SQL терминал. Но он совсем не прост в использовании, и кроме того, возникли бы затруднения в обучении сотрудников SQL.
Looker показался мне довольно заманчивым, поскольку его интерфейс позволял технически не подкованным сотрудникам получать доступ к базе данных и создавать информационные доски и отчеты. Но платить за это решение более 30 тысяч долларов в год мы не могли себе позволить.
Tableau тоже мощный инструмент для визуальной аналитики, но он не оправдал наших ожиданий. С ним не просто делать отчетность и создавать списки. Кроме того, инструмент требует хранить данные в памяти до расчетов, он не может положиться на превосходные способности оперирования данными Redshift.

Ни одно их этих решений не подходило. Но я нашел ответ на все свои вопросы в
Periscope, стартапе, находившимся на ранней стадии своего развития, который создал именно такой продукт, который был мне нужен.

Немного о Periscope:

Periscope — аналитический инструмент, где вы можете писать SQL, чтобы создавать графики.
Periscope легко соединяется с Redshift, потому что они оба являются облачными решениями.
Информационная доска — базовый тип документов.

Пример информационной доски

На этих досках пользователи могут писать SQL, чтобы создавать графики и таблицы.

Написание SQL для создания графиков

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

Этот инструмент просто невероятен:

В основе инструмента лежит SQL, поэтому изучение SQL это обязательное требование. Но благодаря тому, что досками так легко поделиться, использование Periscope теперь стало социальной активностью внутри компании. А это, в свою очередь, стало сильным мотивом для изучения SQL.
Несистематические анализы в Periscope проводятся очень быстро. Из-за того, что графики можно создавать очень быстро, вы можете также быстро отлаживать их в соответствии с тем, как вы смотрите на данные и какие вопросы вы задаете на данный момент. Лично мне кажется, что постоянная отладка — самый естественный способ работы любого аналитика. А если вы можете делать отладку быстрее, то и ответы на свои вопросы вы получаете тоже быстрее.
Составлять отчётность с помощью Periscope легко. Для того, чтобы вытащить список, просто создайте новую информационную доску, напишите свой SQL и нажмите «сохранить». Затем вы можете поделиться ссылкой на доску или экспортировать таблицу как CSV.
Periscope — многофункциональный инструмент по созданию информационных досок. Первое, что я сделал после установки Periscope, — начал создавать информационные доски на каждый продукт и каждую команду, которые у нас есть. А затем, каждое утро я рассылал эти доски всем в компании.
Инструментом Periscope можно пользоваться коллективно. Любой в компании может зайти и посмотреть над чем работают другие. Пользователи могут добавлять графики на доски друг другу, или даже редактировать SQL стоящий в основе графиков других людей. Те пользователи, которые застряли в каком-нибудь пункте создания запроса, могут с легкостью попросить помощи у других пользователей.
Цена за этот продукт разумна. Если учесть, что в нашей компании более 60 человек, я был просто счастлив, когда увидел, какая стоимость в месяц будет у нас получаться.

После установки Periscope, в компании появился новый коммуникационный канал — канал на уровне передачи данных.

Теперь поток данных по компании курсирует без моей помощи. У меня освободилась масса времени, которую я раньше тратил на эти выгрузки данных. И вся компания в целом теперь имеет доступ к большему количеству данных, чем это было тогда, когда выгрузкой данных и анализом занимался только я. Поэтому внедрение Redshift и Periscope оказалось очень удачным решением.

Оценка рабочих характеристик и отчетности

Определение формата

Когда мы разобрались с инфраструктурой, нам нужно было сосредоточиться на налаживании отчетности по метрикам. Старая информационная доска для руководства в Google Sheets с этой огромным количеством цифр требовала полного пересмотра.

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

Кроме того, существовала проблема в определениях метрик: не каждый понимал, что мы имели в виду, говоря «ежедневно активный пользователь». Это была настоящая проблема.

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

Я начал с вершины: сначала разработал доску для управленцев. Она была создана в форме еженедельной выжимки из всех метрик и предоставлялась управляющему составу компании еженедельно на вторничных собраниях. Я плотно работал над VP Product и VP Operations, отлаживая различные способы, которыми может измеряться компания.

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

Рядом с еженедельными цифрами располагались планируемые цифры, которые мы экспортировали из основного документа по планированию. Мы могли сравнить эти цифры и понять двигается ли компания согласно графику.

Эта выжимка данных для управленцев является самой важной информационной доской. Она закладывает основы того, как люди в компании 500px должны думать о своей работе. Из этой выжимки последовали информационные доски для остальных команд в компании.

В итоге я создал набор досок для всех этих команд:

Отдел развития продукта.
Отдел веб сайта.
Отдел мобильных приложений.
Отдел маркетинга.
Отдел продаж.

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

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

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

Об определении метрик

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

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

Те метрики, которые мы измеряем соотносятся с нашими воронками вовлечения. В 500px существует три таких воронки:

посетитель -> подписка -> ежедневная активность -> ежедневная вовлеченность -> платный подписчик.
посетитель -> подписка -> загрузка фотографий -> выставление фотографии в магазин -> продажа фотографии в магазине.
посетитель -> подписка -> покупка фотографии в магазине.

Каждая команда владеет различными частями этой воронки для различных продуктов:

Отделу маркетинга принадлежит верхняя (просмотр страницы) и нижняя границы (доход) этой воронки
Команде разработки продукта в меньшей степени важны верхние границы метрик воронки
Команда разработчиков (веб-сайта и мобильных приложений) хотела бы видеть всю воронку в соотношении с их продуктом.

Книга
Lean Analytics рекламирует применение соотношений (количество загрузок/dau на определенную дату), а не простой подсчет (количество загрузок на определенную дату). Наша команда решила, что подсчет будет проще восприниматься всеми.

Подсчет используется для всего кроме метрик продукта, а здесь мы концентрируемся на измерительных характеристиках двумя способами:

Частота использования (количество загрузок фотографий пользователем в месяц).
Величина использования (количество фотографий на одну загрузку).

Внедрение

Внедрение инфраструктуры и новой измерительной системы требует определенной подготовки. Людям надо научиться использовать Periscope и иметь четкое представление о том, что значит каждая метрика.

Обучение Periscope

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

SQL School
Khan Academy

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

Информационно-разъяснительная работа по метрикам

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

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

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

Точность данных

Метрики часто дают неверную информацию. Мне кажется это то, о чем редко говорится публично. Но каждая компания с этим сталкивается. В этой системе очень много места для ошибок:

Журнал событий может быть неверно спарсен, и в таком случае вы получаете неверное количество событий.
Отправитель журнала событий на API-сервер, может не отправить журнал, и тогда вы можете даже не заметить, что вам не хватает целого фрагмента событий.
Однажды могут случиться проблемы с сетью, и 10% записей журнала событий не будут отправлены в S3.
Некоторые метрики, которые вам важны вообще может быть сложно извлечь, и тогда вы будете располагать неверными цифрами.
И так далее.

Сюда не включены ошибки, вроде тех, когда не запустился процесс ETL или метрики не обновились. Об этих ошибках история умалчивает.

Ошибки будут происходить. Кого-то будут наказывать за то, что совету директоров придется ждать новых данных по метрикам. Но полностью этого избежать сложно. Как с этим бороться?

Всегда проверяйте свою работу. Привязывайте важные цифры к внешним источникам истины. Мы вытаскиваем данные по «ежедневно активным пользователям» нашего хранилища данных и сравниваем их с данными Google Analytics ежедневно. Мы также сверяем метрики по подписке с данными Stripe/Paypal.

Еще мы делаем перекрестную проверку таблиц фактов, которые мы создаем из журналов событий с «размерными» таблицами, которые мы создаем из MySQL. Эта проверка помогает избежать ошибок интерпретации параметров. Например, можно сравнить цифры по новым пользователям в «размерной» таблице с событием «подписка», цифры по которому отражены в таблице фактов.

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

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

Работа с инженерами

Сотрудники отдела аналитики являются связующим звеном между такими отделами компании как отдел разработки продукта, отдел маркетинга, отдел техподдержки, отдел продаж и инженерный отдел.

Очень тщательно надо подходить к налаживанию отношений с инженерным отделом.

При запуске новой характеристики:

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

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

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

Правило 20% — нужно проводить информационно-просветительскую работу по аналитике.

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

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

Я расскажу, как все происходило у меня. Я планировал, что в компании 500px я смогу построить аналитику в несколько этапов:

Инфраструктура.
Отчетность.
Аналитика.
Прогнозное моделирование.

Аналитика — та часть, где сотрудники аналитического отдела всматриваются в данные, чтобы понять куда идет компания, не будет эффективной, если не наладить отчетность и инфраструктуру.

Но когда от руководства звучат вопросы в стиле: «Почему вы не делаете свою работу?» — почему аналитическая часть работы не делается, а вы все еще работаете над построением инфраструктуры, то такая ситуация может сильно демотивировать. Очень сложно выразить несогласие, и вам остается только придерживаться выбранного вами курса.

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

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

Потратьте 20% своего времени на продажи. Это важно.

Заключение

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

У нас теперь есть система, благодаря которой люди знают, как дела в компании, и они могут самостоятельно получать аналитические данные без помощи аналитика. Мы уже далеко ушли и твердо идем к тому, чтобы превратить 500px в лучший стартап, продвижение которого основано на аналитических данных.

Что дальше

Это был хороший год. Но мы сделали еще очень малую часть того, что можно сделать.

Впереди еще так много работы:

Аналитика исходных данных, как Google Analytics, все еще плохо понимается.
Моделирование с помощью pirate metrics по каналам.
Сегментация пользовательской базы.
Казуальное моделирование влияния изменения характеристик.
Создание модели LTV для применения ее в маркетинге.
Процесс A/B тестирования.
Расширение команды.

Это будет отличное время. Но я складываю с себя полномочия.

Когда я устраивался на работу в 500px, я всегда знал, что мое пребывание тут будет временным, и что затем я перееду дальше на запад в Сан-Франциско.

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