Подводные камни unit-экономики: как посчитать траты на привлечение клиента и оценить их эффективность

Директор по маркетингу российского провайдера Timeweb Александр Безобразов написал для vc.ru колонку о собственном опыте применения unit-экономики - отслеживания трат на привлечение одного клиента и прибыли, которую он дает.

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

Есть некий набор «подводных камней», с которыми столкнется большинство компаний. В этой колонке я расскажу о том, с какими сложностями столкнулись мы, каким образом они решены и что еще стоит учитывать, если уж вы решили, что unit-экономика - это «про вас».

Что такое unit-экономика

Unit-экономика или, как ее еще называет, экономика продукта показывает нам, сколько мы тратим на привлечение одного клиента и сколько мы на нем зарабатываем. Есть ли смысл дальше работать с продуктом или нет - зависит от unit-экономики.

В unit-экономике отслеживают семь основных метрик:

1. Стоимость привлечения клиента (CAC, Customer Acquisition Cost) - делим расходы на привлечение всех клиентов на количество привлеченных клиентов.
2. Ежемесячную регулярную выручку (MRR) - сумма, которую приносят все клиенты, которые «подписаны» на услуги, за месяц.
3. Количество активных клиентов - те клиенты, которые регулярно оплачивают услуги.
4. Средняя выручка на клиента (ARPU) - делим MRR на количество активных клиентов.
5. Долю «оттекающих» клиентов (churn rate) - доля клиентов, которые становятся неактивными по прошествии каждого месяца. Если вы привлекли 100 клиентов и через месяц 10 из них уже ушли, то у вас churn rate = 10%.
6. Срок жизни клиента (Lifetime) - величина, обратная churn rate. В примере выше - «база» клиентов «утечет» за 10 месяцев.
7. Ценность клиента за время жизни (LTV) - ARPU поделенное на Churn rate. Для "полноценного" LTV в формулу еще включают валовую маржу (gross margin) конкретного продукта в виде множителя.

Иногда мне приходилось встречать мнение, что «unit-экономика - это для стартапов». Это мнение верно лишь отчасти. Интернет-компании, использующие модель продаж SaaS, PaaS или IaaS, однозначно работают с unit-экономикой. Абстрагируясь от технологических решений, unit-экономика подходит - и по факту работает - в любом бизнесе, который продает что-либо по подписке.

Сложности внедрения

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

На этапе внедрения мы столкнулись с тремя типами проблем:

1. Проблемы с данными.
2. Проблемы с измерением метрик.
3. Проблемы с визуализацией данных.

Данные

Первое, с чем мы столкнулись - это отсутствие или некорректность данных. «Хоть какая-то» статистика собиралась с середины 2013 года. Весь остальной период существования компании был «зоной тьмы»: мы не знали, сколько у нас было активных пользователей на день Х, через какое время они уходили. Для unit-экономики, которая опирается на статистику, это существенная проблема.

Данные, которые мы сохраняли с 2013 года, были «избирательны»: мы не знали, откуда конкретно пользователи пришли, не отслеживали изменение ARPU или количества клиентов по каждому из тарифных планов. Некоторые сомнения у нас были и насчет корректности собираемой статистики.

В биллинговой системе было более 1000 активных тарифных планов. Половина из них - уникальные, создававшиеся под клиента; еще часть - «бесплатные/партнерские» тарифы с активными пользователями, которые нам не платили. Попытка посчитать данные с учетом этих клиентов привела бы к некорректным показателям.

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

Поэтому, если у вас уже работающая бизнес-модель, начинайте собирать данные как можно раньше и учитывайте все необходимые «разрезы». В Timeweb теперь собирают описанные выше метрики с детализацией, показывающей сколько стоил и сколько принес «средний клиент из контекстной рекламы, пришедший 11 ноября 2015 года, и оплативший тариф Year+».

Измерение метрик

Вот с расчетами, как раз, было больше всего вопросов: в «теоретических» статьях никто не пишет о тех «нюансах», которые неизбежно возникают при начале работы с unit-экономикой:

• Что считать MRR - цену подписки или сумму списаний со счета клиента? Вы уверены, что это одна и та же цифра?
• Каким образом учесть уход клиента с одного тарифа на другой? А если у вас две услуги - виртуальный и VDS-хостинг?
• Как учесть скидки или бонусы?

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

При нашем объеме клиентов - десятки тысяч - возник еще один вопрос: с какой периодичностью «считать» и сохранять данные - каждый час, день или месяц? В итоге решили считать каждый день, но сохранять только на последний день месяца.

Это решение является компромиссным и порождает еще ряд вопросов: например, если пользователь был активен на начало месяца, стал заблокирован, скажем, десятого числа, а затем разблокирован за три дня до конца месяца - его считать как «полноценный» аккаунт в расчете MRR или «частичный»?

А как, например, быть с пользователем на тестовом периоде - он активный или нет? А если он зарегистрировался в феврале, а оплатил в марте - он в каком месяце привлечен? А что делать с разблокированным в марте пользователем, если в феврале он был заблокирован - считать новым клиентом? И учитывать ли его в оттоке февраля?

Пока мы не нашли ответы на эти вопросы, у нас «не сходилась математика»: условно, мы привлекали 100 пользователей, теряли двух, а клиентская база прирастала на 140.

В итоге мы пришли к следующему решению:

• Пользователь становится «новым активным» в том месяце, когда в первых раз оплатил услуги хостинга.
• Пользователь считается «активным», если на последний день месяца он находится в этом статусе.
• Любой пользователь, который на конец месяца заблокирован, считается в оттоке (churn rate) - у нас нет гарантии, что он вернется сам, без дополнительных действий.
• Пользователь, который «разблокировал» свой аккаунт, попадает в отдельную графу статистики.
• Отслеживаются переходы пользователей с тарифа на тариф - эти пользователи не считаются оттоком, они делают upgrade или downgrade.
• Пользователи, сменившие услугу - это отток.

Таким образом по клиентам на каждом тарифе мы всегда видим:

• Размер базы на начало месяца.
• Количество вновь пришедших клиентов.
• Количество разблокированных клиентов.
• Количество заблокированных за месяц клиентов.
• Количество клиентов пришедших на этот тариф.
• Количество клиентов ушедших с этого тарифа.
• Размер базы на конец месяца.

Именно в таком виде у нас «сошлась математика» по количеству клиентов.

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

Визуализация данных

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

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

Этот запрос выполнялся в программе phpMyAdmin, затем оттуда данные экспортировались в CSV, который открывался в Excel, где и обрабатывался. Каждый раз при обновлении данных приходилось проделывать цепочку действий повторно. Согласитесь, не самое удобное решение для контроля за ключевыми показателями бизнеса?

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

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

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

Набор доступных источников данных огромен: это может быть база данных, откуда информацию получается SQL-запросами; может быть API «Яндекс. Директа», откуда информация забирается JSON-запросом; или даже Facebook, для которого существует стандартный «коннектор».

Плюс решения - простота внедрения: у нас уже были SQL-запросы, нам оставалось только загрузить данные в Excel, сделать один раз все графики и сводные таблицы. А дальше данные подгружаются и обрабатываются автоматически при нажатии кнопки «Обновить».

Сейчас в Timeweb новую аналитику может сделать любой владеющий Excel сотрудник - мы не зависим от ресурса разработчиков.

Сложности использования

На этапе использования unit-экономики стоит учитывать три потенциальные «ловушки»:

• Изменяющиеся затраты.
• Временные периоды.
• Изменение стратегии.
• Учет изменяющихся затрат.

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

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

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

Временные периоды

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

Через 10 минут кто-то из пользователей сменит тариф, кто-то подключит допуслугу, у кого-то еще закончатся средства на счету и аккаунт клиента будет заблокирован. Если у вас 2-3 тысячи клиентов, вы почти не почувствуете этих событий. Если у вас более 100 000 клиентов, то количество всевозможных событий измеряется тысячами.

И здесь как раз работает unit-экономика: на больших числах имеет смысл следить за динамикой группы клиентов, а не одного конкретного клиента. При корректно построенном сборе данных вы всегда сможете «провалиться» до необходимой глубины.

Здесь возникает еще один вопрос: каким образом учитывать разное количество дней в месяце? В феврале 28 дней, в марте - 31. На базе в 100 000 клиентов «колебания» в 3 дня - немалые деньги.

Как уже говорилось выше, мы записываем данные только в последний день месяца. Это позволило пойти путем банков, у которых стандартный год - это 360 дней (12 месяцев по 30 дней). Мы в Timeweb рассматриваем ARPU и MRR как прогнозные значения на следующие Х дней. А вот фактическую реализацию, естественно, отслеживаем по списаниям со счета клиентского аккаунта.

Изменение стратегии

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

А вот при работе со стартапами или при смене жизненной фазы продукта появляется набор сложностей, связанных со связкой стратегии и unit-экономики.

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

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

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

• Имеете ли вы право ожидать такой же продолжительности жизни клиента (lifetime), если подняли цены?
• Останется ли «общая» цена привлечения клиента такой же, если вы измените набор каналов?
• Уверены ли вы, что отключаемые каналы не вносили свой вклад в приток клиентов по другим каналам?

Таких вопросов множество. Я вынужден разочаровать тех, кто ожидает «готового рецепта»: здесь «серебряной пули» нет, и в каждом конкретном случае стратегические решения приходится принимать отдельно. А вот помнить об изменении unit-экономики вашего бизнеса - необходимо.

Быть или не быть

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

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

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

Microsoft