Продолжаем тему построения аналитики без помощи программистов. Мы уже писали о том, как настроить сквозную аналитику «на коленке». А в этой статье Александр Максименюк, CVO & founder Ringostat, описывает, как создавать дешборды для нужд SaaS. Автор постоянно занимается аналитикой, а предложенные им варианты проверены на практике и используются в рабочих процессах.
В онлайн-бизнесе без аналитики никак — чтобы принять решение или проверить гипотезу, нужны цифры, а предположений, домыслов и интуиции недостаточно. Лично мне пришлось в свое время набить много шишек. Но все удачные и неудачные попытки привели к тому, что я вывел алгоритм, а также свод принципов и правил, которые помогут любому продукту построить гибкую аналитику, не привлекая к разработчиков.
Показатели, о которых я буду говорить, актуальны для Ringostat — мы сервис, работающий по подписке, SaaS-продукт, поэтому для нас важны эти метрики, мы считаем и анализируем именно их. Но для начала синхронизируемся в терминологии. Я обозначу лишь пару основных терминов, о которых дальше пойдет речь.
У нас в управленческих бизнес-срезах есть первичка и еще два элемента.
- Дешборды — отчеты с KPI и данными, сведенными по какому-то признаку. Дешборд должен постоянно обновляться. Это его важное свойство и характерная особенность.
- Срезы — отчеты, которые делаются разово для проверки какой-либо гипотезы. С помощью срезов можно с разных сторон взглянуть на нужные показатели и найти оптимальное решение какой-либо задачи.
Почему привлекать ресурс разработки к построению аналитики — плохая идея
К построению первых дешбордов я тоже привлекал разработчиков. Просто изначально кажется, что это единственно верный вариант. Но солидное количество набитых шишек показало, что это не так, и причин тому несколько.
- Мы никогда на 100% не уверены в конечном результате. Первые два или три дешборда я строил так: подходил к разработчику и говорил: «Чувак, вот показатель, который нам нужен, считается он так и вывести его надо вот сюда». Разработчик делал какую-то дичь, но задача типа была выполнена. Проходило время, и мы понимали, что так не годится и все надо переделать. И все повторялось снова: я подходил уже к другому разработчику, опять все объяснял и опять не получал того, что было мне нужно. В этом и проблема — итоговый результат всегда неизсвестен. Да, мы четко знаем, как получить нужные показатели. Но тот же lifetime value (LTV) или churn (показатель оттока клиентов) можно посчитать разными способами. В процессе работы мы видоизменяем метрики и на выходе получаем не совсем то, что хотели.
- Данные разрознены, и поэтому с ними сложно работать. Допустим, мы берем их из базы данных и из бухгалтерского учета. С первыми девелопер справится без проблем, а вот со вторыми иметь дело ему гораздо сложнее.
- Вы теряете динамичность и гибкость. Если дешборд создан разработчиком и выведен в интерфейс, то внести в него какие-либо изменения — хотя бы добавить показатель — уже сложно. Эта волшебная методология Agile: сперва делается feature request, затем реквесторы обсуждают все это на встрече. После этого надо очень постараться доходчиво объяснить техрайтеру, что это за показатель, зачем он нам и каким образом его получить. Пройдет время, пока техрайтер это все опишет, а скрам-мастер возьмет в процесс. Когда мы получим хоть какой-то результат, будет слишком поздно. Нам надо было проанализировать показатель ретроспективно, а мы его получили только через пару месяцев, приняли решение и того позже, а деньги потеряли.
- Вы никогда точно не знаете, что внутри. Можно подойти к разработчику и подробно объяснить, что вот это, к примеру, MRR. Он показывает, сколько нам клиент приносит денег в распределении по месяцам. А через три месяца выясняется, что разработчик понял нас неправильно, и на дешборде совсем не MRR. А вы-то уже приняли решение на основе выведенных цифр.
Инструментарий
Приведу краткий список инструментов, которые я использую ежедневно.
Данные:
- Google Docs — самые разные доксы, включая учет денег, отчеты по бухгалтерии, кэш-флоу;
- MySQL — сырые данные;
- API разных сервисов — у нас, например, данные саппорта — это API сервиса Intercom;
- BigQuery — пост-обработка, удобный инструмент с учетом того, что разработчики нервничают, когда кто-то своими руками лезет в базу данных, да еще и создает там свои промежуточные таблицы.
Визуализация:
- Google Spreadsheets — рекомендую полезные советы по работе с этим инструментом;
- Google Apps Script — мне удобно с ним работать с теми же BigQuery и Spreadsheets;
- Data Studio — для визуализации, возможно, кому-то удобней Microsoft Power BI, но я его так и не попробовал, так как под маком он не заводится.
Примеры дешбордов
Приведу примеры нескольких дешбордов, с которыми мы работаем — для понимания, как это выглядит и что с этим можно сделать. Я скрыл некоторые цифры, другие изменил, остальные остались реальными.
В каждом департаменте есть свой сводный дешборд. Руководитель департамента строит его на свое усмотрение, делает удобным для своей команды, выводит нужные показатели и добивается максимальной автоматизации.
Верхнеуровневый — дешборд со сводной информацией со всех этих доксов по департаментам. Содержит нужные нам вкладки — по сейлзам, маркетингу, customer success, саппорту. Также мы видим в нем проекты в основных разрезах по интеграциям, партнерствам, структуре тарифов. Также есть гео-структура, churn, результаты по финансам, LTV, основные KPI.
Drill down дешборды в Data Studio — для углубленной аналитики.
В отчете на примере выше есть основные показатели — MRR, Lifetime, LTV и т. д. Также в нем есть фильтры, с помощью которых я могу выбрать то, что хочу посмотреть. К примеру, меня интересует, как менялся churn проектов для клиентов, которые пришли по партнерке и используют интеграцию. Пара кликов — и я уже вижу данные.
Или необходимо взглянуть на соотношение дохода по тематикам клиентов — что там растет, а что падает.
Или, к примеру, я хочу узнать, что происходит на рынках, которые для нас не являются основными.
Выбираю нужный фильтр и вижу, что Израиль растет, появились Эмираты. И мы уже начинаем думать, что с этим можно сделать и какие решения принять, исходя из этой информации.
Churn по когортам. Крутой отчет, один из моих любимых. У меня с ним связана одна показательная история. Когда-то работал у нас менеджер, который продавал не наш продукт, а, видимо, какие-то свои фантазии. Выяснилось это, когда отчет показал churn 57% в первые 3 месяца. Понятное дело — клиенты покупали выдуманный им продукт и, разочаровавшись, уходили. Но система мотивации на тот момент была построена так, что свой процент менеджер получал. С ним после этого быстро попрощались, но проблема осталась — в первые месяцы churn все еще был достаточно большой.
Пример подобного отчета:
Ниже еще один полезный отчет. Разрез: проекты, у которых подключены интеграции, и те, у которых нет. Ниже я оставил показатели, на которых хотел сфокусироваться — это churn, MRR и количество проектов.
С его помощью мы выяснили, что у проектов, использующих интеграции, churn почти в два раза меньше, чем у остальных. Что мы можем сделать, зная это? Прежде всего, в системе мотивации customer success теперь новый KPI — количество проектов, подключивших интеграцию в первый месяц. Второй момент: у разработчиков теперь тоже основной фокус на интеграциях. Ведь чем больше у нас будет интеграций, тем больше клиентов мы ими заинтересуем.
Принципы, которых важно придерживаться при построении дешбордов
- Руководство компании должно понимать суть показателей и бизнеса. Прежде всего, топ-менеджменту нужно понимать, как департаменты взаимодействуют между собой, какие метрики важны и почему, каким образом должен считаться тот или иной показатель. Пока вы в этом не синхронизируетесь, ничего не выйдет. Это еще одна причина, по которой сейчас не имеет смысла привлекать к процессу разработчика.
- Нужно помнить, что данных всегда гораздо больше, чем кажется. И правильно этим пользоваться. К примеру, мы никогда не считали MRR. Факап для SaaS-продукта, но так и было. Но при этом мы считали продление проектов, знали срок, на который продлевали и сумму. И вот он, наш MRR — сумма пополнения, деленная на продление + мы знаем, когда проект продлевал и когда подключился. На деле там чуточку сложнее, но суть та же.
- Все всегда нужно перепроверять. Несколько раз.
- У разных систем свои особенности, которые нужно учитывать. Такой особенностью у MySQL являются переменные — их нужно сбрасывать. Я в свое время этого не знал и здорово обжегся. Или еще один момент в работе с той же MySQL — кеширование. К примеру, есть у меня запрос, который показывает некорректные данные, если его выполнять первый раз. Но если этот же запрос выполнить спустя пару секунд, цифры будут правильными.
- Если есть аномалии, перепроверьте еще раз.
- Всегда используйте удобный нейминг. Когда только начинаешь работать с Google Docs и у тебя там 5-10 документов, об их названиях не задумываешься. Но проходит время и ты уже безуспешно пытаешься найти нужный докс среди сотни других или хотя бы примерно вспомнить его название. Поэтому у нас в команде есть правило называть документы по определенному принципу. В названии пишем максимум запросов, по которым потом этот документ будут искать.
- Старайтесь делать отчеты понятными и юзабельными. Не нужно впадать в перфекционизм, но учитывайте, что дешбордами пользуется топ-менеджмент, время которого дорого.
- Всегда сохраняйте инструкции и примечания. Простой совет, но мне его в свое время не дали, и я к этому приходил очень больно. Я построил дешборд и он меня устраивал абсолютно во всем. Но когда нужно было его обновить, я понял, что не сохранил запросы и мне пришлось все делать с нуля. После этого у нас появилось правило — обязательно сохранять не только запрос, но и комментарий, что с ним нужно сделать.
Как построить бизнес-аналитику для SaaS, не привлекая разработчиков
Теперь расскажу, как поэтапно построить дешборды.
- Определитесь с целью.
Посчитать и вывести можно все, что угодно. Вопрос в том, насколько этим получится пользоваться. Когда у нас очень много данных, становится сложно принимать решения. Это как жонглирование: тремя мячиками может научиться почти каждый, а пятнадцатью — надо быть суперпрофи и иметь врожденные качества. - Выделите показатели и разрезы, которые вас интересуют.
- Определитесь с источниками данных.
- Подготовьте дешборд в сыром виде.
Возьмите spreadsheets и стяните туда нужные данные с помощью функций IMPORTRANGE, QUERY и прочего. Проверьте, что все подтянулось правильно: возьмите конкретный показатель за определенный месяц и вручную его посчитайте. После проверки и визуализации у вас, скорее всего, получится такой себе монстр. Например, наш верхнеуровневый дешборд в сыром виде открывался 15 минут и блокировал работу компа. Поэтому пришлось делать все заново. Я скопировал документ, снес оттуда данные, формулы и попробовал построить все так:- данные храним в BigQuery;
- предобработка с помощью Apps Script — он в данном случае удобен тем, что не надо сильно глубоко шарить: выполняем SQL-запрос, сохраняем данные в другую таблицу MySQL и экспортируем в Spreadsheets, получается так:
- Проверьте. Возьмите новый дешборд и сравните с тем, что вы отложили — если цифры совпадают, можете себя поздравить.
- Дайте инструкции.
Напишите, какие показатели брали и почему, как их считали и т. д. Расскажите людям, которые будут с этим документом работать, куда им смотреть и какие данные важны. Также важно записать, как все делалось — вдруг это нужно будет повторить. Комментарии в коде и разделение его на логические блоки must have.
Подходы и принципы для срезов
Расскажу на конкретном примере, чтобы было понятнее. Предыстория: наш конкурент в смежной тематике внезапно зашел в нашу — причем, с демпинговыми ценами, более чем в два раза ниже, чем у нас. Мы какое-то время никак на это не реагировали, но потом все же решили тоже сделать минимальный, базовый тарифный план.
Теперь о принципах — чтобы построить срез, вам нужно учесть следующие моменты.
Четкая гипотеза
У нас были определенные ожидания:
- из-за низкой цены снизится churn и вырастет LT;
- низкая цена повлечет улучшение conversion rate и снижение стоимости привлечения клиента (CAC или customer acquisition cost);
- клиентам, пришедшим по минимальному тарифу, можно будет делать апсейл до обычных тарифов, на которых мы сможем заработать.
Определиться с показателями
В нашем случае, исходя из гипотез, нужно было считать churn rate, LT, LTV, expansion и downgrade — потому что мы опасались, что на этот тариф начнут переходить те, кто платил нам больше.
Опять-таки учитывать, что данных больше, чем кажется
Показатели, которые были нужны, мы считали хардово, исходя из всех данных, которые есть. К примеру, САС мы считали не просто по маркетингу, а включали в расчеты все расходы на клиента: стоимость обслуживания, бонусы сейлзам, затраты на саппорт. В итоге получили такую картину:
У нас были эти данные и данные по другой фокус-группе — клиентам из других рынков, которым мы по-прежнему продавали старый тариф. Сравниваем две фокус-группы и видим — и lifetime value, и lifetime проектов, зашедших по минимальному тарифу, оказались значительно ниже, чем те же показатели клиентов, которые продолжали платить нам больше. При этом стоимость привлечения проектов на минимальный тариф была не намного ниже, чем стоимость хорошо платящих клиентов. Получалось, что на этом тарифе мы просто теряли деньги.
Аномалии перепроверить еще раз
Мы так и сделали, плюс посчитали Expansion/Downgrade. Получили следующий результат:
Видим, что с этого тарифа мы смогли заапсейлить 6 проектов, 19 перешло на него с других тарифных планов. Соотношение LTV к САС по проектам на минимальном тарифе — 0,66. То есть, на каждом таком клиенте мы теряли 34% денег. Так мы пришли к выводу, что на минимальном тарифном плане немного зарабатываем только в случае, если продаем его сразу на год. Ощутимо зарабатываем — если сразу на три. Я думаю, вы понимаете, какое решение мы приняли в результате.
Юзабельность и фиксация процесса
Когда мы делаем срез, то понимаем, что он нужен единоразово. В лучшем случае мы вернемся к нему через полгода-год для проверки, не изменилось ли что-то. Поэтому:
- не нужно уходить в перфекционизм при оформлении среза — табличка не должна быть идеальной, она должна быть достаточной;
- поскольку к этому срезу мы можем вернуться, лучше все же зафиксировать процесс, что и как мы делали — чтобы через полгода-год быстро воспроизвести все в том же виде.
И все-таки: когда привлекать разработчиков
Разработчик нужен, чтобы зафиксировать и автоматизировать регулярно повторяющийся процесс. К примеру, я ежемесячно захожу в базу данных MySQL, выполняю один и тот же запрос, заливаю те же данные в BigQuery, выполняю три функции в Google Spreadsheets и получаю результат.
Когда этот процесс повторяется три-четыре раза и там уже нет никаких косяков, тогда имеет смысл поставить простую задачу разработчику: возьми запрос, результат его залей в BigQuery, выполни вот эти вот функции, и все — поставь это на крон, пускай выполняется каждый день. Это уже не ручная работа, а за то, что крон отработает, мы не платим. В результате мы получим постоянно обновляющийся дешборд, а срезы по-прежнему продолжаем делать самостоятельно руками.
