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

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

В своей книге “Юнит-экономика”, я посвятил целую часть книге именно когортам, и наглядно показал, как они устроены, с точки зрения сбора реальных данных. И вот пришло время показать как моделировать когорты. 

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

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

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

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

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

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

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

Давайте посмотрим на формирование клиентов в когорте на рисунке, за первый месяц (06.2023) пришло 115 новых клиентов, за следующий (07.2023) еще 42. А теперь посмотрим на возвращающихся клиентов. 

Так как первый месяц — это месяц формирования когорты, то возврат у нас имеется на второй и третий месяц жизни когорты. И видно, что на второй месяц вернулись 60 клиентов из 115 имеющихся на тот момент в когорте, а на третий месяц жизни когорты еще 34, но уже из 157 клиентов (115 + 42). Более подробно можете прочитать про этот механизм в моей книге. 

Ни на конец, расчет числа платежей, которые вы получаете в месяц от клиентов в когорте. Тут логика строиться очень просто, каждый клиент совершает 1 покупку в месяц, на самом деле это не так, и такое приближение годиться только для SaaS, для ecom я ввожу еще один параметр ATP (Average Transaction per Period), среднее число сделок, совершаемое клиентом за один период. И тогда вместо 1 используется это число. А далее мы складываем в каждый месяц транзакции от новых и старых клиентов, до тех пор пока итоговое число APC не достигнет расчетного. 

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