
Аналітика для SaaS: Які показники потрібно аналізувати і чому
Більше року маю задоволення працювати з Reply. У числі клієнтів команди він ще з серпня 2022 року, тому ми пройшли вже довгий шлях разом. Відгук про нашу співпрацю можна прочитати на головній сторінці.
Reply – це мікс всіх переваг стартапу з їхніми швидкими реакціями на "навколишнє середовище", великої і на рідкість надзвичайно дружньої команди, керівників-перфекціоністів, які ставлять складні, але чіткі задачі та завжди вислухають думку кожного в команді і йдуть на зустріч. Таке ж відношення у них і до клієнта – до кожного з великої кількості клієнтів у Reply дійсно індивідуальний підхід і персоналізований сервіс.
... але для аналітика така персоналізація і відсутність будь-якої шаблонності в сервісі – це челендж)
Втім, пройшовши за цей час вогонь, воду і Reply, саме останній зробив з мене аналітика, тому його роль у моєму житті важко переоцінити.
Це ліричний вступ до того, що поговоримо сьогодні: про мій досвід з SaaS і моє бачення аналітики для такого типу бізнесу. Reply – не єдиний мій SaaS, але він найвизначніший.
Отже, план на сьогодні:
- Що таке SaaS
- Цілі SaaS
- Маркетингова і продуктова аналітика
- Яке джерело користувача важливіше
- DAU WAU MAU
- Дохід, MRR та їхні типи
- Churn і його визначення
- Причини чорну, контракшену. RFM-аналіз і не тільки
- ARPU / ARPA – average revenue per user / account
- LTV – lifetime value
- CAC – customer acquisition cost
- CAC / LTV та магічне число
- Атрибуція даних на дату, але на яку?
- Додатково
- Заключні думки
Що таке SaaS?
Якщо вас зацікавив заголовок, то ви, напевно, знаєте що це, але давайте будемо на одній хвилі.
SaaS (Software as a service) - послуга у вигляді «софта», такий тип бізнесу, який надає певні послуги у вигляді хмарного додатка, програми, з якою можна взаємодіяти через Інтернет. Зазвичай має певні умови, можна сказати «рівні», використання, описані в тарифних планах, які мають свою ціну за певний період часу.
Цілі SaaS
Глобально їх всього 2 – залучення нових користувачів і утримання існуючих. Часто у SaaS вони розподіляються між двома командами – маркетинговою і продуктовою. Відповідно, якщо спростити: залученням займається перша, утриманням – друга. Але хороший SaaS – це не про розділення, це про консолідацію зусиль різних підрозділів задля однієї, ще більш глобальної цілі, – розвитку компанії.
Маркетингова і продуктова аналітика
Це розділення – моє суб'єктивне і доволі умовне, бо обидва підрозділи мають знати показники один одного, просто в меншій деталізації. Наприклад, маркетинг повинен знати churn rate в розрізі каналів залучення користувачів, але йому достатньо розуміти його відсоток і не обов'язково знати причини з деталізацією до кожного користувача, що в свою чергу дуже корисно продуктовій команді.
Тому наступні показники я не розділяю на 2 направлення, бо всі вони взаємопов'язані, однаково важливі для бізнесу в цілому.
Яке джерело користувача важливіше?
Я про джерело залучення користувачів – джерело/канал трафіку на сайт, партнерскі програми, офлайн просування, тощо – джерелом тут я вважаю те, що привело користувача в продукт.
І от яке з них важливіше? Тут у мене відповідь однозначна – перше. Нам потрібно розуміти, які маркетингові активності залучили користувача в продукт. Те, що він потім, вже будучи клієнтом компанії, зайшов з органіки по брендовому запиту і змінив тариф на дорожчий, — неважливо для маркетинга, бо це не новий кастомер. І він зробив так тому, що йому продукт подобається, а це про утримання. В свою чергу продактам не те, щоб дуже важливо з якого джерела юзер підвищив тариф, головне, що він це зробив, а джерело заходу на сайт не впливає на рішення змінити тариф.
Надалі теж піде мова про нюанси, бо як то кажуть “диявол в деталях”. Взагалі SaaS – це завжди про нюанси.
Які ж вони у відношенні джерела? А спробуйте відповісти на питання – що ж таке “перше джерело”?
Припустимо у бізнеса немає офлайн активностей, тільки сайт, який просувається по SEO, PPC, і має партнерську програму. При тому самим партнерам не заборонено просувати продукт у своїх власних рекламних активностях. А на сайті, окрім власне реєстрації в продукті, є ще форми реєстрації на вебінари, лідмагніти з корисними матеріалами і т.і.
Тут я подумала, чи треба нагадувати, що всі маркетингові активності мають бути розмічені UTM-мітками, бо це класика, як мінімум, має нею бути, але досвід переконав, що про мітки треба нагадувати завжди – не забувайте розмічати посилання на сайт UTM-мітками! Але не робіть розмітку на самому сайті…
Так от, у більшості випадків першим джерелом, якому треба віддавати перевагу при аналізі, є джерело, з якого ми отримали контактні дані користувача. При цьому визначати його потрібно за звичною атрибуцією – last non-direct
.
Перше за last non-direct
... ні, це не помилка) зараз поясню.
Чим далі живемо, тим більше стикаємось з обмеженнями у зборі даних. Тому, як на мене, треба намагатись, де це можливо, збирати їх самостійно, а не доручати стороннім сервісам, які підпадають під обмеження.
Ця порада стосується і визначення джерел лідів. Самостійно це зробити не те, що можна, а навіть треба. Реалізується це через написання JS скрипта, логіка якого визначає і зберігає в cookie джерело заходу юзера на сайт, а якщо під час нього було заповнення форми / реєстрація, тобто факт передачі своїх контактів юзером, то з цими даними передаються і джерела з cookie. Таким не надто складним шляхом ви будете знати звідки до вас приходять користувачі і не будете залежати від обмежень, які накладають різноманітні блокувальники, консент, тощо.
Але щодо консенту – обов’язково проконсультуйтесь з юристом, там теж свої нюанси можуть бути)
Таким чином, при наявності цих даних, перше джерело визначається наступним чином:
- Якщо лід від партнера: його джерело – партнер.
- Якщо лід залишили на сайті: його джерело – джерело з лід-форми, після відправки якої цей контакт з’явився в системі. Якщо людина спочатку залишила контакт при реєстрації на вебінар, а через деякий час зареєструвалась в продукті, то його перше джерело – те, що було на момент реєстрації на вебінар, а не в продукті.
При цьому для розгорнутої картини добре записувати також джерело реєстрації в продукті. Такий підхід дасть відповідь на питання – звідки ми залучаємо ліди, і що їх “дотискає” в реєстрацію.
Додатковим і не менш корисним є збереження ще одного набору джерело/канал/кампанія/term/content – того, що було, коли юзер вперше зайшов на сайт. Тут логіка простіша за попередню – в момент першого входу потрібно визначити джерело, записати його в куки і більше не чіпати. А при відправці форми або реєстрації, передати ці значення додатковими полями в CRM/адмінку.
Так ви зможете побудувати дворівневий аналіз, де перший агрегує дані по джерелу найпершого входу на сайт, а другий – на основі джерела важливої дії на сайті (конверсії). Аналізувати дані тільки на основі джерела конверсії може бути недостатньо, оскільки, грубо кажучи, без першої взаємодії подальших могло і не бути, тому без найпершого джерела можна зробити поспішні висновки і виключити зі стратегії хороше асоційоване джерело.
Щодо асоційованих джерел в ідеалі записувати весь ланцюжок взаємодії користувача з бізнесом допоки він не стане клієнтом. Зберігати джерела всіх сесій до того, як юзер виконає корисну дію, може бути непросто, тому можна зберігати джерела всіх форм, які відправляє незареєстрований юзер, наприклад, якщо ви часто проводите вебінари, або відправляєте корисні матеріали за контакт тощо.
Джерело залучення вашого клієнта – дуже важливий пункт для подальшого аналізу, тому я на ньому так детально зупинилась. Для структурованості давайте підрезюмуємо:
- Обов’язково зберігати джерело контакту, коли він вперше з’явився в вашій базі.
- Дуже корисним буде зберігати джерело першого заходу на сайт – ви будете знати звідки ваші потенційні про вас дізнались.
- Корисно буде зберігати джерело реєстрацій – ви зможете дослідити, що або хто (менеджери) дотискає потенційного в те, щоб він став клієнтом компанії.
- Також корисним буде зберігати джерела всіх відправлених форм, поки користувач ще не став клієнтом. Ви зможете визначити, які ваші активності найбільш цікаві вашим потенційним клієнтам.
- Максимум даних про вплив ваших активностей ви отримаєте, якщо будете зберігати джерела всіх торкань, а не тільки відправлених форм. З цим пов’язані доволі суттєві труднощі з реалізацією. Тому на початку, визначитись чи варто зберігати весь ланцюжок, вам може допомогти Google Analytics 4. Так, з багатьох причин він не зберігає 100% даних про трафік, але кількості даних все одно буде достатньо для того, щоб знайти потрібні відповіді стосовно поведінки більшості користувачів вашого сайту і виначитись, чи достатньо вам інформації від GA4, або потрібно самостійно записувати весь ланцюжок.
Як бачите, зберігати можна багато чого, алене потрібно зберігати те, що не буде аналізуватись. Тому вам треба самим визначитись зі стратегією збору джерел.
DAU WAU MAU
Попередній пункт був цікавий маркетологам і всім, хто вкладає бюджет у просування. У цьому пункті ми розглянемо продуктові метрики, які визначають залученість користувачів в продукт.
- DAU (daily active users) – активні користувачі продукту за добу.
- WAU (weekly active users) – активні користувачі продукту за 7 днів.
- MAU (monthly active users) – активні користувачі продукту за 30 днів.
Тут, як і в більшості випадків, саме бізнес дає визначення поняттю “активний користувач”. Це може бути як той, хто просто зайшов на сайт / у додаток хоча б раз за відповідний проміжок часу, або ті, хто за цей проміжок виконав певну дію. Звісно, що ті, хто виконав певну дію, більше схожі на “активних” користувачів, але знову ж визначення цього поняття – задача бізнеса.
Іноді, щоб виключити випади на графіку, рахують DAU як середнє значення кількості активних користувачів в день за останні 30 днів:
Унікальна кількість юзерів за 30 днів поділена на 30
Це робить графік плавнішим, і на ньому легше побачити тенденції.
Але абсолютні значення без співвідношень не достатньо показові, тому додаю ще їх:
- DAU / WAU – як часто ті, хто був хоча б раз за тиждень, повертаються щоденно протягом тижня.
- WAU / MAU – показник того, як часто ті, хто був “активним” хоча б раз за місяць, повертались хоча б раз за тиждень.
- DAU / MAU – співвідношення, яке використовується найчастіше. Відображає відсоток користувачів за останній місяць, які користуються продуктом щоденно. Чим вищий це показник, тим краще ви утримуєте користувачів.
Зазвичай, ці показники рахуються на основі даних аналітичних систем, які збирають максимум даних про взаємодію з сайтом / додатком, наприклад, Google Analytics 4, тому надважливо передавати в ці системи ваш внутрішній ID користувача при реєстрації, логіні і зі всіма подіями, коли користувач залогінений. Це дозволить об’єднати декілька девайсів одного користувача, а також розрізнити декількох юзерів, які користуються одним девайсом. Для найкращої точності можна ще відстежувати, коли користувач виходить з облікового запису. Це дозволить рахувати користувачів продукту і їхні івенти тільки в період, коли вони залогінені і можуть виконувати певні дії, доступні тільки залогіненим. І оскільки ми говоримо про продуктові метрики, потрібно виключати з розрахунків дані про взаємодії з меркетинговими сторінками, якщо визначенням “активності” користувача ви обрали, наприклад, “відвідування сайту” – в такому випадку це мають бути відвідування сторінок продукту.
Дохід, MRR та їхні типи
От пункт про гроші буде без сумніву цікавий всім, тому давайте теж будемо на одній хвилі.
Дохід – це сума отриманих коштів від користувачів продукту. Але чи бізнес фінально “заробить” весь дохід, отриманий на момент оплати, залежить від багатьох факторів, зокрема принципів вашого білінгу. Чим довший період підписки, тим більша вірогідність, що її змінять до кінця біллінг періоду, а отже і фактичний дохід компанії може відрізнятись від суми первинної оплати, тому що SaaS може повертати кошти за невикористаний період. Але може бути і інша модель, коли підписку змінити завчасно не можна, або при відміні підписки кошти за майбутній невикористаний період не повертаються. У такому випадку сума доходу дорівнює сумі оплати, але все одно цей дохід бізнес “заробляє” не за один день, а протягом всього періоду надання сервісу.
За фактично отриманий дохід відповідає MRR – monthly recurring revenue.
Мені добре відомо, що MRR прийнято називати предиктивною метрикою. Для мене у MRR є дві сторони – якщо ми говормо про минулий період, тоді MRR – це фактичний дохід за цей період. Але MRR може легко використовуватись для прогнозування – достатньо закласти певні умови на майбутнє (наприклад, скільки у вас зараз активних користувачів, скільки ви очікуєте залучити нових кастомерів, а скільки ви втрачаєте зазвичай, тощо), і ви зможете доволі легко спрогнозувати майбутній дохід на основі MRR.
Формула:
Сума оплати / кількість місяців користування продуктом
Таким чином, дохід за річний план в розмірі, наприклад, $1200 буде дорівнювати $100 MRR в кожен з 12 місяців фактичного користування продуктом ($1200 / 12 місяців). Саме фактичного. Якщо у вас передбачене повернення коштів при відміні підписки, і якщо користувач вирішить покенселити підписку через 10 місяців, то ваш дохід складе $1200 і мінус $200 в якості рефанду, а фактично бізнес заробить $1000 – саме така буде сума MRR за період користування сервісом.
У статтях про SaaS всі пишуть про MRR і не так часто про дохід. Якщо у вас підписки тільки на місяць, то різниця між доходом і MRR буде незначна. Але якщо у вас складна і персоналізована модель користування продуктом, то вам треба рахувати обидва показника. MRR більш стабільний, він не покаже вам суттєвої втрати, якщо від вас піде користувач на річній підписці. Ви побачите, що ви втратили $100 в якості churn MRR. А розрахувавши churn revenue, ви побачите суму $1200, бо саме стільки б ви отримали в наступну оплату від цього користувача, якби він з вами залишився. Втрата $1200 спонукає до дій в 12 разів краще, ніж втрата $100.
Таким плавним чином ми підійшли до того, що розуміти суми MRR i revenue недостатньо. В попередньому абзаці я згадала поняття Churn MRR / revenue. Таких типів виділяють більше. Давайте перелічимо їх:
MRR:
- Total – тут все просто. Це сума MRR за обраний місяць.
- New – MRR, отриманий в перший місяць підписки. Його приносить будь-який кастомер в перший місяць користування продуктом.
- Expansion – це сума MRR тих кастомерів, які в поточному місяці мали більший MRR, ніж в попередньому. Тобто ця метрика відстежує чи почав кастомер приносити більше доходу. Додатково варто розраховувати дельту між поточним і попереднім місяцем. Це покаже наскільки більше доходу отримує компанія внаслідок того, що її активні кастомери настільки задоволені, що переходять на дорожчі підписки.
- Contraction – антонім до попереднього пункту. Визначає MRR кастомера, якщо в поточному місяці він почав приносити менше доходу, ніж в попередньому. Тут також важливо рахувати дельту, оскільки вона покаже скільки доходу втрачає компанія. Окрім того, це “дзвіночок” до втрати цих кастомерів – вони ще є активними користувачами, але показують вам, що не готові продовжувати платити вам на тому ж рівні. Пошук причин контракшену та тісний діалог з такими клієнтами дасть вам шанс покращити продукт та утримати цих клієнтів.
- Churn – це страшне слово для SaaS. Означає користувачів та їхній MRR, який ви втратили, бо клієнт від вас пішов. Це єдиний показник, який на 100% не про отриманий дохід, бо це сума, яку ви втратили, що робить цей показник одним з найбільш важливих.
- Reactivation – визначає користувачів та відповідно їхній MRR, коли вони дали ще один шанс вашому продукту і повернулись в ряди ваших кастомерів після чорну.
- Unchanged – цей тип MRR показує вашу стабільність. Фактично це сума, яку продовжують незмінно платити ваші активні користувачі.
Типи revenue визначаються схожим принципом, але це дуже кастомний розрахунок. На відміну від MRR, тут рахуються фактичні суми оплат на час їхнього надходження. Щоб співвіднести ту чи іншу оплату з її типом замість місяця доцільно орієнтуватись на період підписки. На відміну від MRR, такий розрахунок має певну попереджувальну і передбачувальну дію. Якщо ви бачите великий ріст revenue в певний місяць, але при цьому MRR виріс не суттєво, це значить, що скоріш за все у вас виросла кількість підписок на більший період (півроку, рік), тому в подальшому MRR теж збільшиться. В свою чергу якщо ви бачите скачок Churn Revenue, а MRR при цьому змінився не дуже помітно, це значить, що в цей місяць ви втратили дуже багато підписок на тривалий період, що негативно відобразиться на MRR в майбутньому.
Churn і його визначення
Churn – це коли ваш кастомер перестає бути вашим кастомером. Тобто це – клієнти, яких ви втратили.
Виглядає так, що визначення ми дали, і залишилось написати тільки формулу розрахунку. До речі ось вона:
Кількість тих, хто перестав користуватись послугами компанії (зачорнився) протягом заданого періоду / кількість активних користувачів на початок періоду * 100%
Якщо на 1 вересня у вас 1000 активних користувачів, а протягом вересня 50 кастомерів пішли від вас, то churn буде 50 / 1000 * 100% = 5%.
Виглядає просто, чи не так? Так… Допоки не намагаєшся дати визначення складовим формули.
З активними користувачами на початок періоду все відносно просто – це ті, хто був на активній підписці на перше число поточного місяця або на останнє число попереднього.
А що визначає того, хто перестав користуватись продуктом?
Чи вважається у вас churn-ом кастомер, який:
- відмінив підписку?
- відмінив підписку 15-го числа та поновив 20-го того ж місяця?
- залишився активним, але перейшов на безкоштовний план?
- затримав оплату, в результаті чого вона сталась на початку наступного місяця, бо у вас можна користуватись послугою ще 5 днів при затримці оплати?
- покенселив підписку зараз, але період був оплачений ще на наступні 3 місяці, під час яких кастомер може використовувати сервіс? Тут уточнення – ясно, що це чорн, але коли він відбудеться – зараз, в день кенсела, або через 3 місяці, коли підписка буде остаточно закрита? Якщо зараз, а через місяць клієнт передумає і поновить підписку – то це реактивація або чорну як такого просто не було?
Цей список питань можна продовжувати. Головне, що я ним намагаюсь донести: SaaS – це про тонкощі і нюанси кожного бізнеса. Формули зазвичай прості, але, щоб дати визначення їхнім складовим, часто йде дуже багато часу на обговорення, узгодження, донесення до всіх в команді.
Причини churn та контракшену – RFM-аналіз і не тільки
Звісно, що добре спостерігати за ростом New i Expansion customers / MRR і трохи боляче, коли росте Contraction i Churn customers / MRR. Але перші будуть рости, якщо ви будете робити правильні висновки з останніх, бо саме в них – точка росту.
За цими показниками стоять люди, і не просто люди – це ваші клієнти, яких ви або втрачаєте, або вже втратили. Не шкодуйте ресурсів на комунікацію з ними. Це не повинна бути просто якась email-розсилка одна на всіх.
Розділяй і володарюй, як то кажуть. Сегментуйте своїх користувачів. Щодо чорну стане в нагоді RFM аналіз.
RFM – recency, frequency, monetary value – це сегментація бази клієнтів відповідно за давністю останньої взаємодії з вашою компанією, частотою взаємодії (для SaaS це може бути сумарна тривалість підписки в місяцях), та сумарним доходом, який приніс окремий кастомер за весь період взаємодії.
Знову ж таки цей підхід доволі гнучкий, і сумарний дохід можна замінити на середній MRR. Визначивши умови сегментації, ви отримаєте списки тих, хто, наприклад, пробув з вами декілька місяців і зачорнився, – такі не варті вкладень суттєвих ресурсів в повернення, якраз для них можна обмежитись розсилкою з проханням надати фідбек про продукт або пропозицією невеликої знижки.
Також ви отримаєте список тих, хто був з вами довго і приніс вам суттєву долю доходу. Не шкодуйте на дослідження причин їхнього чорну людино-годин ваших найкращих представників з Customer Success.
Також випередити чорн можна комунікацією з тими, хто потрапив в контракшен. Ваші звіти повинні відображати не тільки сухі цифри, а також давати змогу швидко спуститись на рівень окремого кастомера. Цей процес можна автоматизувати – ми використовуємо cloud-функції, які можуть формувати і відправляти відповідальним особам список тих, з ким потрібно зв’язатись в першу чергу на основі певних умов. Навіть оперативно інформувати про проблеми з оплатами у найцінніших клієнтів теж можна.
Перелік кейсів можна розширювати. Основна думка цього розділу – жодні цифри чорну і контракшену не будуть мати користі без діалогу з клієнтами. Персоналізуйте комунікацію з ними, і вони зможуть розказати, як вам покращити продукт.
ARPU / ARPA – average revenue per user / account
Їдемо далі. В цьому розділі знайомлю вас з відносно популярними показниками:
- ARPU – average revenue per user – середній дохід на одного юзера.
- ARPA – average revenue per account – середній дохід на один акаунт.
Ці показники більш класичні для додатків, там виділяють ще ARPPU – average revenue per paying user. Різниця в тому, що ARPU вираховується по формулі весь дохід поділений на всіх юзерів, а ARPPU – весь дохід поділений тільки на тих, хто платить, виключаючи тих, хто користується додатком на безкоштовній основі.
Для SaaS в розрахунку зазвичай беруть участь тільки активні користувачі, тому він спрощується до “ARPU” на щомісячній основі, а формула виглядає так:
MRR / кількість активних користувачів
Якщо ваш MRR становить 50 000 грошей, і в той же місяць у вас було 1000 користувачів, то ARPU буде – 50 000 / 1000 = 50.
Чому саме MRR, а не revenue? Все просто – принцип включає розділення отриманого доходу на кількість кастомерів, а за отриманий дохід відповідає саме MRR.
Звісно, ви можете вирахувати середній дохід на всіх, в т.ч. і тих, у кого безкоштовний план, але, як на мене, це надлишкова інформація, і може дати перекос в якусь сторону, що буде складно пояснити.
Більш простим в розумінні є ARPA. Формула дуже схожа:
MRR / кількість активних акаунтів
Якщо мультиакаунти, коли у одного юзера може бути кілька акаунтів, для вас не часта історія, то ARPU і ARPA у вас мають бути майже однакові. В іншому випадку ARPA дасть вам більш чітке розуміння доходу з одного облікового запису. А якщо ви в решті розрахунків орієнтуєтесь саме на акаунти, то це – ваша єдина правильна формула розрахунку середнього доходу, бо всі формули мають бути на одному рівні, щоб правильно їх аналізувати.
З іншої сторони, якщо ви орієнтуєтесь на юзерів, і у вас може бути таке, що у одного акаунта декілька юзерів, враховуйте цю особливість при розрахунку ARPU.
LTV – lifetime value
LTV (Life-time value) перекладається як “пожиттєва цінність”. І фактично показує вам суму доходу, який принесе вам кастомер за весь період взаємодії з вашою компанією. Так, речення саме в майбутньому часі, бо цей показник прогнозний.
При цьому я часто зустрічаю, що терміном “LTV” називають зовсім інший розрахунок, наприклад, певну варіацію APRU – коли весь дохід, отриманий від користувачів за весь минулий період ділиться на кількість користувачів. Але цей підхід враховує і тих, у кого станом на зараз “термін життя” в вашій компанії ще не завершився, тобто дані відносно пожиттєвого доходу у них неповні.
Те, що має відношення до прогнозування, зазвичай відноситься до складних математичних формул з купою складових, моделювання даних, машинного навчання, data science та інших туманних словосполучень. При цьому прогноз – це прогноз. Коли вам кажуть, що з вірогідністю 99% завтра не буде дощу, а він все ж пішов, ви, як аналітик, скажете – “ну вірогідність, що піде дощ все ж була, 1%”. Більшість правда буде жалітись – “ох вже цей гідрометцентр…”
Тому до прогнозу треба ставитись, як аналітик – вірогідність, що життя не попаде в прогноз присутня завжди. Чи треба в таких умовах будувати надскладні розрахунки? Залежить від бізнесу і ресурсів. Якщо ви – Coca-Cola, Apple або Google, то 100% треба. У вас, можливо, буде штат data scientist-ів, які тільки тим і будуть займатись, що прогнозуванням. Чи будуть враховувати ці прогнози всіх можливих чорних лебедів? Та ні. Завжди є вірогідність… Ну ви, думаю, вже зрозуміли.
У більшості бізнесів немає ресурсу на штат сайєнтистів, та і відверто, даних у більшості недостатньо, щоб по всім канонам статистики і математики розрахувати майбутнє. Тому доводиться спрощувати підходи. Звісно, вірогідність похибки більша, але краще рухатись вперед, маючи хоч якийсь ліхтарик, аніж в цілковитій темряві.
Цим ліхтариком в SaaS і є показник LTV. Його спрощена формула виглядає так:
ARPU / Churn Rate
І продовжуючи приклади з попередніх розділів, при ARPU 50 і Churn 5%, LTV буде становити –
50 / 5% = 1000.
Якщо ви не знаєте Churn, але знаєте доволі точно середню кількість місяців, протягом яких кастомер залишається з вами, формула буде такою:
ARPU * середня кількість місяців користування продуктом.
Отримавши результати розрахунків, ви зможете краще планувати свої рекламні кампанії, розуміючи скільки ви можете вкласти в залучення нового кастомера, бути перший період в певному мінусі, але при цьому знати, що за весь період життя цей кастомер вірогідно з часом окупиться і почне приносити прибуток.
CAC – customer acquisition cost
CAC – вартість залучення кастомера. Зазвичай нового, але знову ж – можуть бути нюанси)
Наприклад, ви можете запускати ремаркетинг на тих, хто зачорнився, і таким чином хочете бачити вартість реактивованого кастомера.
Але перш, ніж продовжити, давайте поглянемо на формулу:
Витрати на залучення кастомерів / кількість залучених кастомерів
Щодо другої частини трохи стало ясніше – вам треба визначитись кого враховувати як залученого користувача. Тільки нового? Або нового і реактивованого? Або всіх? Так теж можна, хоча за класикою враховують тільки нових.
Тепер щодо витрат – є 2 підхода: повноцінний і спрощений.
- Повноцінний – коли у витрати входять всі витрати: бюджет рекламних кампаній, зарплати команди, всі різноманітні операційні витрати, які є у компанії.
- Спрощений зазвичай враховують тільки витрати на рекламні кампанії.
Звісно, раджу рахувати все, але якщо поки немає можливості, а дані потрібні, згадуємо приклад з ліхтариком і йдемо спрощеним шляхом, запланувавши перехід на повноцінний.
І, як завжди, з прикладом, де витрати становили 20 000, а залучили в той же період 40 нових користувачів, тоді CAC буде становити 20 000 / 40 = 500.
CAC / LTV та магічне число
Ми підійшли до найбільш простих по формулі та найбільш потужних показників для SaaS.
Простота заключається в формулі – CAC / LTV. Але до цієї формули ви не просто так прочитали близько 4000 слів, звісно якщо читали все ;)
І якщо читали все, ви вже знаєте, що шлях до цього співвідношення складний, від слова “дуже”.
Цінність і потужність цього показника варте того, щоб пройти весь цей шлях, оскільки один показник може в секунду вам сказати – ваша компанія заробляє або втрачає.
Наприклад, на залучення нового кастомера ви витрачаєте 500 грошей. Пожиттєва цінність становить 1000.
Співвідношення CAC / LTV – 500 / 1000 = 0.5 (50%)
Все, що суттєво менше 1 (100%) – добре, бо це означає, що ви заробляєте більше, ніж витрачаєте.
Число, близьке до 1 (100%) – ви працюєте в нуль.
Все, що, не дай Боже, більше 1 (100%) – ваш маркетинг збитковий, і час приймати стратегічні рішення.
Класичний орієнтир – 1:3 (33%). Не раджу тримати рейт на 75-80%, бо ви ж пам’ятаєте, що LTV - метрика прогнозна, а отже неточна, тому закладайте “подушку безпеки”.
Якщо рейт на 10-15%, інвестуйте в маркетинг, бо ви втрачаєте можливості.
Ще в природі існує таке поняття, як Magic Number. Рахується по формулі LTV / CAC.
Ці два співвідношення, як ROAS і ДРВ (доля рекламних витрат) – про одне і те ж з різних сторін.
Магічне число покаже вам скільки разів окупиться ваш залучений кастомер.
Тут логіка зеркальна:
Все, що більше 1, вказує на прибутковість.
Все, що менше, – на збитковість.
Атрибуція даних на дату, але на яку?
Тепер поговоримо про нюанси з часом. Зазвичай у SaaS далеко не одна "важлива" дата.
Серед них дата, коли юзер вперше:
- потрапив на сайт,
- залишив контакт в формі,
- зареєструвався в продукті,
- скористався сервісом,
- зареєструвався на демо продукту,
- поспілкувався з sales rep,
- оплатив підписку,
- а ще поновив, зачорнив, реактивував
- та й просто місяць, коли користувався продуктом...
І це все різні дати, які при тому ще можуть бути доволі сильно розтягнуті в часі, бо, наприклад, між заходом на сайт і першою оплатою може пройти багато часу.
При цьому з усіх попередніх метрик напевно ви вже отримали відчуття, що SaaS – це зазвичай про щомісячні майлстоуни, тому дані часто виводять помісячно. Але що ж робити з відкладеним інтересом?
Відповідь тут – агрегувати дані за когортною логікою, тобто на певну дату. Але щоб мати можливість аналізувати дані під різними кутами, то і дати мають бути різними.
Корисним буде побудова фанелу з основною розбивкою по місяцям. Він має включати послідовно весь ланцюжок дій вашого клієнта від заходу на сайт до становлення кастомером, а також статус на цей час – expansion / contraction / churn / reactivation.
Агрегувати всі дані в такому репорті треба на одну дату. Наприклад, на дату початку трайлу. І дані починаєте виводити з розрахунком скільки юзерів почали трайл, скільки його активували при тому неважливо коли, скільки почали платити, стали кастомерами, та скільки з них підвищили або понизили план, зачорнились або реактивувались станом на зараз. Таким чином ви будете бачити ситуацію по всім тим, кого ви в конкретний місяць залучили в старт трайлу. Точно за такою ж логікою можна агрегувати дані на дату проведення демо і краще розуміти ефективність sales менеджерів.
Для загальної картини корисним буде побудова схожого фанл-репорту, де кожен розрахунок виводиться на свою дату: відвідування сайту на дату відвідування, трайл – на дату початку трайлу, демо – на дату його проведення, кількість активних кастомерів – на дату користування, churn – на дату чорна і т.д.
Додатково
На цей момент я розглянула, на мою думку, найважливіші аналітичні показники і підходи. Але ще є певні метрики, які трохи простіші і, можливо, менш “потужні”, проте теж можуть бути корисними під час аналізу. Давайте пройдемось по ним трохи швидше.
Lead-to-Customer Rate
Співвідношення тих, кто став кастомером, до загальної кількості отриманих лідів. Показує одночасно “якість” роботи менеджерів і “якість” отриманих лідів, їхню зацікавленість та попередню поінформованість в продукті.
Формула:
Customers / All Leads * 100%
Якщо кастомерами стало 50 людей з отриманих 1000 лідів, то рейт становитиме – 50 / 1000 * 100% = 5%
Months to Recover CAC
Покаже вам скільки в середньому часу ви будете в мінусі від залучення нового кастомера. Після того, як кастомер “проживе” з вами цей час, він почне приносити дохід.
Класична формула:
CAC / (New MRR x GM), де GM – маржа у відсотках.
Таким чином при CAC 500, якщо MRR кастомера в перший місяць буде 100, а маржа становить 80%, то період до окупності становитиме 6.25 місяців.
Хоча, я б трохи модифікувала цю формулу, додавши розрахунок через ARPU, замість New MRR, бо перший MRR може зміниться і доволі сильно – бізнес може видавати знижки в перший місяць, або в подальший період користувач може змінити підписку. На мою думку, ARPU відображає середній дохід в місяць від одного користувача, тому розрахунок через ARPU буде більш наближеним до реальності. Мій варіант формули:
CAC / (ARPU x GM)
Quick Ratio
Це співвідношення швидко дасть вам розуміння куди рухається ваш прибуток – чи ви втрачаєте або отримуєте більше. Чим цей показник вище, тим краще. Дуже показово виводити його на графік.
Формула:
(New MRR + Expansion MRR ∆) / (Contraction MRR ∆ + Churned MRR)
MRR ∆ – різниця між поточним і попереднім місяцем.
ARR
Annual Recurring Revenue. Має на меті спрогнозувати ваш дохід на наступний рік. І фактично це ваш поточний MRR помножений на 12.
Формула:
MRR * 12
ACV
Annual Contract Value. Показує вам середній дохід, який приніс один кастомер за останні 12 місяців. Як на мене, віддалено його мета схожа на LTV, але рахується на фактичних історичних даних, без прогнозування.
Total Revenue за останні 12 місяців / кількість кастомерів
Якщо на зараз у вас 1000 кастомерів, а за попередні 12 місяців вони принесли 2 000 000 грошей, то ACV буде – 2000000 / 1000 = 2000.
Customer monthly growth rate
Свого роду churn навпаки. Показує вам наскільки збільшується ваша клієнтська база щомісячно.
Формула:
Кількість нових кастомерів / Кількість всіх кастомерів на початок періоду.
Customer concentration
Показник, який розкаже вам наскільки багато яєць ви тримаєте в одному кошику)
А точніше: це відсоток доходу, який приносять топ 10% ваших найцінніших кастомерів.
Таким чином якщо сукупний дохід у вас 2 000 000, а топ 10% ваших кастомерів принесли 1 200 000, тоді Customer concentration становитиме 2 000 000 / 1 200 000 = 60%.
Чим від більший, тим більше ваша компанія залежить від рішення чи продовжувати бути з вами невеликого сегменту кастомерів, що звісно не дуже добре.
Company growth rate
Це співвідношення відображає ріст або навпаки просадку доходу компанії.
Формула:
(Дохід за цей місяць - дохід за попередній) / дохід за попередній місяць * 100%
Якщо дохід за цей місяць був 500 000, а за попередній – 475 000, тоді Company growth rate складе – (500 000 - 475 000) / 475 000 = 5.3%
Заключні думки
Ця стаття вийшла насиченою на формули, але я хочу, щоб ви винесли з неї максимум з того, що буде корисним саме вам. Далеко не всім SaaS треба рахувати все на світі. Нікому не треба рахувати всі можливі і неможливі показники. Аналітика будується для того, щоб допомагати бізнесу приймати рішення на основі даних, а не заради красивих звітів, якими в результаті ніхто не користується, бо вони перенасичені / складні / непотрібні.
Розставляйте пріоритети. Ніхто не знає ваш бізнес краще за вас, і ніхто вам не підкаже, які питання для вас важливіші. Як мінімум, ніхто не повинен. Я поділилась з вами своїм досвідом і рекомендаціями, чи приймати їх і які саме – суто ваше рішення.
Інша думка, яку я намагалась донести: кожен бізнес унікальний. На ринку багато пропозицій, які кажуть – підключіть до нашого сервісу ваші системи з даними, і ви будете мати доступ до user-friendly сервісу побудови звітів на льоту і легкого аналізу даних, поєднаних між собою в 3 кліки.
На практиці, ці сервіси хоч і стараються робити прикольні речі, але вони шаблонізовані. Вони розраховують на те, що всі однаково і правильно ведуть CRM, підключають найбільш популярні сервіси оплат і т.п. Тому вони у більшості випадків не можуть втілити в життя ідеї, закладені в них їхніми творцями, бо не можуть адаптуватись під всі нюанси окремого бізнесу.
Я не вірю, що якщо аналітику для SaaS і вдасться шаблонізувати, то з цього вийде щось дійсно класне. Я проти шаблонності. На мою думку звіти мають враховувати якомога більше тонкощів вашого бізнесу, а таке може побудувати тільки той, хто суцільно занурюється у ваші вимоги, вивчає дані по окремих кастомерах, дотошно перевіряє правильність обробки даних, шукає закономірності та причини відмінностей від них. Саме цим якраз і займається команда proanalytics.team
Comments