Аналитика показателей подписки: как рассчитать MRR, показатель оттока, ARPPU и многое другое

О милый МРР! Критерий прогресса для бизнеса SaaS / подписки / членства / регулярного дохода.

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

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

Хорошо, давайте остановимся.

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

Так что же это за показатели подписки? Что означает весь этот жаргон?

У нас есть подробные объяснения этих показателей SaaS / подписки / повторяющихся бизнес-показателей. А пока позвольте мне дать вам краткий обзор.

Самое простое объяснение бизнес-метрик подписки в интернете

• MRR, ARR: ежемесячный регулярный доход и годовая скорость выполнения. По сути, сколько денег вы зарабатываете в месяц?
  Подписки, которые не повторяются с интервалом в месяц, «конвертируются» в ежемесячные. Например, сумма годовой подписки делится на 12, недельная подписка может быть умножена на 4,33 и т. д.
• Отток: что вы теряете каждый месяц — доход, клиентов, количество подписок. Обычно обозначается в процентах от MRR.
• Переключатели: люди меняют свои планы подписки. Вы хотите отслеживать обновления и понижения. Модернизация увеличивает MRR, понижение сокращает его.
• Пробные версии : количество пробных версий, процент конверсии пробных версий в платные. Пробную версию можно рассматривать как план продукта, и вы можете считать ее «обновлением», когда люди переходят на платный план. Но он заслуживает измерения сам по себе.
• ARPU, ARPPU, ARPA: средний доход на пользователя (или на платного пользователя, или на аккаунт). По сути, это MRR, разделенный на количество клиентов (или количество платных клиентов, если у вас есть бесплатные пробные версии). В некоторых ситуациях может потребоваться объединить всех пользователей из организации и подсчитать их общий доход как средний доход на учетную запись.
• CLTV, LTV: пожизненная ценность клиента. В большинстве случаев люди инвертируют коэффициент оттока, чтобы получить среднее количество месяцев, в течение которых клиент остается активным. Затем умножьте это на ARPU, чтобы получить LTV.
• CAC: стоимость привлечения клиента. Часто это внутренний показатель, поскольку системы отчетности сами по себе не учитывают затраты. Сравнение CAC с LTV показывает, насколько выгоден клиент на протяжении всей жизни. Быстрая безубыточность означает лучшую масштабируемость и лучшую оценку!
• Quick Ratio: сколько денег вы добавляете в месяц, деленное на то, сколько денег вы теряете. Быстро показывает, плаваете вы или тонете!
  Формула будет (Новый MRR + Расширяющийся MRR) / (Сократившийся MRR + Измененный MRR).
  Вы даже можете измерять подписки по их статусу — «Новые», «Активные», «Повторно активированные», «Отмененные», «Приостановленные» и т. д.
  Еще один важный показатель — «Неудачные списания». Срок действия кредитных карт истекает постоянно, и по мере роста вашей клиентской базы количество неудачных попыток списания средств будет увеличиваться.
• Даннинг: Это процесс предотвращения этих неудач и восстановления после них. Хорошее решение для напоминаний может легко увеличить ваш доход на 10-20%.
• Возвраты: многие люди не включают возвраты в отток, так как это скорее изменение денежного потока. Если возврат средств отменяет подписку, это будет считаться оттоком.
• Денежный поток: наличные — это здравомыслие, другие — тщеславие. Отслеживание движения денежных средств имеет решающее значение для бизнеса.
  Разделение всех этих показателей по продукту и варианту. Независимо от того, называете ли вы свои продукты по подписке «планами» или как-то еще, это, безусловно, поможет отслеживать важные цифры для каждого продукта.

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

Ты можешь в это поверить? Мое простое объяснение было таким длинным?

Измерение и расчет MRR и других показателей — простое, но комплексное решение

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

Но это полезно, если вы понимаете это. В конце концов, это математика, и это слишком простая математика.

Это самый полный, но простой подход, который мы нашли. Вскоре вы увидите элегантность решения.

Хорошо, давайте погрузимся.

Часть 1. Хранение важной информации

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

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

Расчет MRR по этой таблице — не лучшая идея.

Как рассчитать МРР?

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

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

Нам также необходимо хранить идентификатор клиента, чтобы мы могли рассчитывать показатели даже на уровне клиента — помните, что у них может быть несколько активных подписок!

Вот выдержка из этой таблицы.

2018-07-25123john@domainputlergrowthupdated10079USD

На простом английском,

• Джон записался на пробное занятие 10 июля. 25 числа перешел на платный тариф за 79 долларов в месяц.
• 15 августа был повышен до более высокого тарифного плана в размере 249 долларов США в месяц.
• Почему-то он не хотел продолжать, поэтому отменил 10 декабря.
• Но так как его месячная подписка была оплачена до 14 числа месяца, он использовал продукт до 14 числа, а 15 числа срок его действия истек.
• Снижение нашего MRR с 249 долларов до 0.

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

• Здесь мы завоевали еще двух клиентов – Энни и Марка.
• Энни начала с пробной версии Putler Starter, а на следующий день перешла на платный план.
• В конце концов, она также купила другой продукт, 10x Formula, по цене 99 долларов за м, у которого не было пробной версии.
• Марк подписался на пробную версию, начал платить 79 долларов в месяц через 20 дней.
• В конце концов, он перешел на более низкий план с годовой оплатой (29 долларов в месяц, но 290 долларов в год), снизив MRR до 290 долларов/12 = 24,17 долларов.

Часть 2. Расчет MRR, Trials to Paid, Churn и многое другое…

Давайте посчитаем разные показатели по состоянию на 20 декабря 2018 года.
Найти MRR проще всего!

Вы можете спросить, зачем вычитать old_mrr из new_mrr? И если вы не знакомы с SQL-запросами, бит SUM может вас смутить.

Подумайте об этом немного. Возьмите ручку и бумагу, посчитайте разницу и суммируйте ее.

Затем с помощью этой логики рассчитайте MRR на разные даты.

На самом деле, потратьте немного времени и обдумайте это. Как только вы полностью это поймете, все остальное будет просто.

…

Сделанный?

Ok.

Как рассчитать отток?

Это говорит о потере MRR из-за оттока и количестве подписок, которые ушли.

Не слишком сложно, верно?

Как рассчитать испытания для оплаты?

Давайте посмотрим на что-то более сложное.

Ух ты! Вы уже многого добились!

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

• Переключатели: когда тип события «обновляется», а новый MRR больше, чем старый MRR, это обновление. В противном случае понизьте рейтинг.
  Сходным образом, все новые MRR + апгрейды = расширение MRR. Все оттоки + понижение рейтинга = сокращение MRR.
• Активные подписки: уникальные идентификаторы подписок, за исключением отмененных или непреобразованных пробных версий.
• Средний доход на платного пользователя: MRR, разделенный на количество активных подписок. (Если вам нужны «пользователи», а не «подписки», вы можете выбрать количество уникальных клиентов с активными подписками.)

Вы получаете картину!

Так почему же я называю это ящиком Пандоры???

Кто такая Пандора? А что у нее в коробке?

Пандора — персонаж греческой мифологии.

Прометей украл огонь с небес, в наказание Зевс (царь богов) подарил Пандору брату Прометея Эпиметею.

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

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

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

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

Если ваш расчет показывает MRR в размере 12000 долларов, но вы забыли вычесть из него отмены, то это не сработает.

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

Итак, мы согласны с тем, что точные показатели необходимы. Но как это становится все более и более сложным??

Вот как отчеты о доходах от подписки становятся действительно сложными!

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

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

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

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

• Не существует общепринятого метода расчета всех этих показателей: в разных решениях для создания отчетов используются разные методы расчета. Поэтому, если вы сравниваете свои данные с кем-то еще, вы можете увидеть несоответствия.
• Мусор на входе, мусор на выходе: если журнал всех транзакций неполный или противоречивый, в нашей таблице событий подписки будет недостаточно записей. Например, если вы создаете данные о событиях подписки на основе транзакций за последние два года, вы можете пропустить важные события, произошедшие до этого периода. Или, если ваш платежный шлюз / система электронной коммерции устанавливает одну и ту же дату для создания и первого платежа — или любые другие несоответствия — метрики будут неправильными.
• Системы электронной коммерции и API-интерфейсы платежных шлюзов меняются: они могут изменить тип данных, которые они предоставляют. Это означает две вещи: во-первых, вам нужно постоянно обновлять свою логику — и это нормально; но во-вторых, старые данные могут быть в старом формате, новые данные в новом стандарте. В таком случае вам нужно будет нормализовать и привести все в тот же формат!
• Новые события подписки: каждый раз, когда происходит новое событие подписки, вам необходимо проверить и при необходимости обновить таблицу. Большинство шлюзов не указывают на апгрейды/даунгрейды. Многие не указывают пробную информацию. Поэтому нам нужно разумно идентифицировать эти закономерности.
• Несколько валют: если вы принимаете платежи в разных валютах, вам нужно будет искать обменные курсы и конвертировать все в «базовую» валюту. Это может быть проблемой само по себе.
• Несколько платежных шлюзов / систем электронной коммерции: если вы принимаете для платежей как Stripe, так и PayPal, тип информации, которую они предоставляют позже о транзакции, будет другим. Например , API PayPal не предоставляет интервалы подписки и дату окончания. В таких случаях нам приходится строить «нечеткий» метод обнаружения подписок и их деталей. Консолидировать такие различия между шлюзами и унифицировать данные чрезвычайно сложно.
  Мы уже подготовили метрики для продуктов и вариантов. Но названия продуктов/планов постоянно меняются. Для большей точности нам нужно построить систему для объединения/группировки товаров.
• Неточность данных в системах электронной коммерции. Когда вы используете систему электронной коммерции, в ней могут быть не самые точные данные. Для подтверждения необходимо свериться с платежными шлюзами. Этот процесс дедупликации является интенсивным.

Хотите отслеживать повторяющиеся показатели дохода? Вот ваши варианты…

Это удачная аналогия. Если вы не отслеживаете свои ключевые показатели эффективности, вы не знаете, куда идете. (И, кстати, если вы не читали «Пересечение пропасти», прочтите, когда представится такая возможность.)

Каждый серьезный деловой человек знает о важности отслеживания ключевых показателей. И нет недостатка в инструментах аналитики и отчетности.

Но сначала: не делайте ошибку, используя электронную таблицу Excel (или Google!) для отслеживания показателей подписки SaaS и KPI. Это не будет масштабироваться.

Итак, каковы ваши варианты?

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

Даже аналитические решения общего назначения, такие как Google Analytics и Mixpanel, позволяют отслеживать доход от электронной коммерции. Вы можете использовать их, но не получите KPI подписки, которые мы обсуждали — MRR / Churn и т. д.

Учитывая рост SaaS и повторяющуюся бизнес-модель, десятки стартапов запустили решения, специализирующиеся на показателях SaaS. Есть много вариантов, особенно когда вы используете Stripe. ChartMogul, Control, ProfitWell, Compass, Statsbot, Supermetrics… — список можно продолжить. Многие из этих решений также работают с другими платежными шлюзами.

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

Даже мы скопировали Baremetrics, когда построили аналитику доходов от подписки в Putler.

Да, Putler предоставляет вам полный спектр повторяющихся бизнес-отчетов.

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

Наш опыт предоставления платформы для электронной коммерции и аналитики доходов от подписки

Putler начинался как простой инструмент отслеживания продаж PayPal еще в 2010 году. Он оставался настольным приложением в течение многих лет и приобрел тысячи пользователей. В 2016 году мы переработали всю систему и перенесли ее в Интернет.

Посмотрите на панель управления подпиской Putler.

Putler — это значимая платформа для аналитики электронной коммерции, одна из лучших.

Почему?

В основном из-за наших замечательных клиентов. Мы построили Putler с постоянной обратной связью от клиентов. Мы решили реальные проблемы людей.

Putler делает то, что не делает большинство других аналитических решений.

Вот как Путлер сравнивается с конкурентами

Итак, какое решение лучше всего подходит для SaaS/подписной аналитики и отчетности?

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

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

• Это работает только с Stripe? Или конкретный шлюз или система электронной коммерции? Если это так, это может ограничить вас в будущем.
  Даже если вы используете шлюз, для которого создана система, будет ли он работать в вашем случае? Например, для некоторых решений требуются планы/продукты, определенные на уровне Stripe/шлюза. Если вы используете систему электронной коммерции, например WooCommerce, и используете Stripe только для платежей, большинство решений не будут работать.
• Может ли решение обрабатывать разовые платежи? Даже для SaaS не каждый доллар возвращается. Вам нужно что-то, что может справиться со всем.
• Есть ли у платформы готовая интеграция с вашей системой оплаты/электронной коммерции? У всех есть API, но использование API для заполнения ваших данных может оказаться сложной задачей.
• Дает ли он вам большинство (если не все) показателей, которые вы хотите отслеживать? Может ли он извлекать данные из других систем, таких как Google Analytics, чтобы дать вам лучшее представление о вашем бизнесе?
• Как система справляется со сложностями, о которых мы говорили ранее? Изменения в системе, смена плана, возмещение, несколько валют и т. д.?
• У вас есть несколько платежных шлюзов/предприятий/сайтов? Если да, то может ли решение точно объединить их все в одном месте?
• Можете ли вы предоставить ограниченный доступ членам вашей команды? В отдел маркетинга или поддержки клиентов?
• Это просто инструмент отчетности или выходит за рамки? Обогащает ли это профили клиентов? Можно ли отправлять отчеты по электронной почте? Может ли он обрабатывать напоминания/неудачные платежи?
• Сколько стоит? Даже если это бесплатно, сколько времени и усилий вам придется потратить, чтобы заставить его работать? Как предлагаются дополнительные продажи премиум-класса?
• Легко ли им пользоваться? Получаете ли вы необходимую информацию, не прыгая туда-сюда?
• Выживет ли платформа? Или он исчезнет в ближайшие несколько лет?

Вопросов было намного больше, чем вы ожидали?

Но я думаю, что важно рассмотреть все эти аспекты.

Что вы думаете?

Попробуйте их. Тогда решите.

Справедливый?