Як налаштувати тарифікацію за споживанням: Покроковий посібник
Щоб налаштувати Тарифікація за показниками, ви повинні впровадити системи для моніторингу споживання продукту клієнтом, застосовувати правила ціноутворення до цих даних, а потім виставляти рахунки на основі використання. Існує кілька причин, чому компанія, що надає програмне забезпечення як послугу (SaaS), може розглядати перехід на модель ціноутворення на основі використання. Цей підхід пов'язаний зі здатністю компанії відображати цінність свого продукту у визначеній ціні. Впровадження такої моделі на практиці залежить від ряду змінних.
Цей посібник проведе вас через процес створення покрокової стратегії для вибору параметрів вимірювання, налаштування відстеження подій та впровадження функціональної системи тарифікації за споживанням.
Перед запуском перевірте його на етапі підготовки, розглянувши деякі поширені питання:
- Чи залежить вартість товарів і послуг, що надаються клієнтам, від кількості дій користувача, чи витрати на хостинг є фіксованими, незалежно від рівня використання?
- Чи користувачі, які виконують найбільше роботи, більш ніж у 10 разів цінніші, ніж середній користувач?
- Чи ваші цільові клієнти хочуть зрозумілий місячний рахунок, чи їм зручна ідея сплачувати комісію за кожну дію?
Такі питання допомагають зрозуміти споживання, і особливо, чи є воно базовим, подвійним, або ж це передплачені картки.
Огляд концепції
-
Категорія: Інфраструктура білінгу за підпискою
-
Для кого: B2B SaaS платформи та стартапи
-
Основна мета: Узгоджуйте ціноутворення з обсягом використання
-
Пов'язані поняття: Ціноутворення на основі використання, Облік ліцензій SaaS, Підписка за використанням
-
Етап зростання: Запуск продукту через глобальну експансію
Визначте метрику використання
Розробка правильної метрики це баланс між тим, що технічно можливо відстежити, і тим, чого хочуть клієнти. Метрика повинна бути безпосередньо пов'язана з тим, що користувачі вважають цінним і корисним і, водночас, легким для вимірювання інженерами.
Розробка абстрактної концепції або включення кількох змінних вимірювання до однієї категорії може вплинути на розуміння аудиторією її конкретних компонентів. Застосування абстрактної або багатоваріантної ставки для цілей виставлення рахунків може вимагати від користувачів звернення до служби підтримки для уточнення деталей щодо звірки рахунків. Краще підготувати такі концепції чітко та заздалегідь, і таким чином уникнути ускладнення чистоти платіжних даних, точності значень та створення ефективних нарахувань.
| Тип метрики | Поширений варіант використання | Галузевий приклад | Відповідність цінності для клієнта |
| Кількість | Запити до API, надіслані електронні листи, запущені робочі процеси | Twilio, SendGrid | Чітка, пряма тарифікація на основі дій |
| Сума / Обсяг | Зберігання даних (ГБ), обчислювальні години, токени LLM | AWS, OpenAI | Безпосередньо пов'язує вартість ресурсів з використанням |
| Максимум / Пік | Пікові одночасні місця, максимальна кількість активних проєктів | Datadog | Фіксує потреби в потужностях |
| Останній / Моментальний знімок | Кількість активних користувачів наприкінці циклу | Slack | Просте для розуміння виставлення рахунків за знімком |
Twilio стягує плату за кожен запит до свого API або надіслане SMS, тоді як AWS стягує плату на основі часу та ресурсів.
У 2014 році, Hubspot запровадив тарифний рівень на основі використання, пов'язаний з розміром бази даних контактів на момент IPO. Це коригування було пов'язане з показником утримання чистого доходу майже 100%, оскільки воно пов'язувало витрати зі зростанням клієнтів.
Перш ніж надавати можливість вибору комбінації основних метрик, краще зосередитися на одній метриці. Початок роботи з надмірною кількістю дій або елементів у воронці може створити труднощі для відстеження прогресу та призвести до більшої ймовірності розбіжностей у виставленні рахунків.
Результати дослідження від Rob Roy Consulting опитування показують, що 73% B2B клієнтів визначають аспекти прозорості технологічних постачальників, які потребують уваги. Чіткі, визначені метрики використання, що базуються на єдиному атрибуті продукту, можуть впливати на сприйняття довіри протягом розрахункового періоду.
PayPro Global має потужний функціонал управління каталогом, що дозволяє різним командам використовувати різні стратегії ціноутворення на основі одиниць, тарифних планів, або атрибутів без необхідності змінювати базову структуру бази даних.
БЕЗКОШТОВНИЙ Дієвий Чеклист Тарифікації за Споживанням
Налаштуйте лічильникову тарифікацію, ціноутворення на основі використання та автоматизоване виставлення рахунків SaaS без зусиль.
-
Основні критерії вибору метрик використання
-
Покрокові вимоги до конвеєра прийому подій
-
Відстеження в реальному часі та специфікації інформаційної панелі
-
Повна логіка тарифікації та етапи автоматизації виставлення рахунків
Налагодьте відстеження використання в реальному часі
Щоб створити Конвеєр подій, необхідно негайно, без затримок, розпочати запис активності користувача в додатку, де виконується робота. Кожна дія, що здійснюється в обліковому записі, повинна бути відповідним чином позначена та включати додаткову інформацію, наприклад, час її виконання. Точність запису подій впливає на узгодженість використання ресурсів з процесами виставлення рахунків, дозволяючи уникнути витоку доходу.
Інженерна команда також повинна мати ефективну систему для обробки сплесків обсягу трафік без шкоди для фіксації подій.
Точність фіксації подій впливає на узгодження використання ресурсів з процесами тарифікації.
Використовуйте ідемпотентний ключ для кожного пакета даних події, щоб уникнути подвійного підрахунку однієї й тієї ж події у разі повторних спроб. Функціональність систем впливає на збір даних про використання та продажі, а також інших записів подій; відхилення можуть бути пов'язані зі змінами в показниках доходу.
Щоб уникнути таких ситуацій, пропускайте потоки подій через надійні черги повідомлень, такі як Kafka або SQS, із чергами «мертвих листів».
Ось як виглядає типовий запис журналу подій, коли його надсилають до однієї з точок інтеграції:
Ключ event_id повинен бути унікальним на рівні бази даних і має бути забезпечений за будь-яку ціну. Якщо під час передачі події виникне збій мережі, і клієнт згодом повторить спробу операції, база даних відхилить надлишковий запис.
PayPro Global підтримує вебхуки та REST API для обробки великих обсягів подій, забезпечуючи відсутність проблем з надходженням журналів подій в облікові записи клієнтів.
БЕЗКОШТОВНИЙ Дієвий Чеклист Тарифікації за Споживанням
Налаштуйте лічильникову тарифікацію, ціноутворення на основі використання та автоматизоване виставлення рахунків SaaS без зусиль.
-
Основні критерії вибору метрик використання
-
Покрокові вимоги до конвеєра прийому подій
-
Відстеження в реальному часі та специфікації інформаційної панелі
-
Повна логіка тарифікації та етапи автоматизації виставлення рахунків
Впровадити логіку агрегації та тарифікації
Необроблені дані про використання повинні бути перетворені в реальні гроші шляхом включення відповідних часові періоди або вікна агрегаціїЦей крок усуває необхідність конвертації великих обсягів даних подій з бази даних у конкретні рівні використання. Система тарифікації потім множить ці рівні на тарифні картки, додаючи знижки або об'ємні знижки, де це можливо, за умови дотримання порогових значень.
Точні вікна агрегації мають значення для запобігання подвійним списанням коштів з клієнтів та для встановлення чітких визначень часових поясів між клієнтами в різних географічних регіонах.
Сума → Сумує загальну кількість спожитих одиниць протягом розрахункового періоду (наприклад, загальна кількість переданих гігабайтів).
Підрахунок → Підсумовує окремі дії (наприклад, загальну кількість викликів API).
Макс. → Фіксує найвище пікове значення, зафіксоване протягом циклу (наприклад, пікова кількість одночасних користувачів).
Останнє → Використовує кінцеве зафіксоване значення наприкінці розрахункового циклу (наприклад, зайняте активне сховище).
Система оцінювання повинна включати зведені бали цієї діяльності та базуватися на єдиній ставці, або ставках, скоригованих з урахуванням обсягу, або комбінації цих двох варіантів, коли включено базову передплатну норму.
| Цінова стратегія | Як розраховуються платежі | Найкраще підходить для |
| Чиста оплата за використання | Спожиті одиниці × Тариф за одиницю | Інструменти розробника, хмарні обчислення |
| Багаторівневий з перевищеннями | Плата за базовий план + (Одиниці понад ліміт × Тариф за перевищення) | B2B SaaS платформи |
| Обсяговий | Усі одиниці тарифікуються за нижчою ставкою після досягнення порогового значення | Масова розсилка повідомлень, доставка електронних листів |
| Передплачені кредити | Списання одиниць з гаманця попередньо придбаних кредитів | ШІ-інструментів, обробка GPU |
У різних випадках період виставлення рахунків може відрізнятися від тривалості надання послуг та моменту фактичного споживання ресурсів. Щоб уникнути типових суперечок з клієнтами, спричинених такими невідповідностями, переконайтеся, що мітки часу сервера, зведені дані бази даних та цикли виставлення рахунків працюють за стандартизованим UTC.
БЕЗКОШТОВНИЙ Дієвий Чеклист Тарифікації за Споживанням
Налаштуйте лічильникову тарифікацію, ціноутворення на основі використання та автоматизоване виставлення рахунків SaaS без зусиль.
-
Основні критерії вибору метрик використання
-
Покрокові вимоги до конвеєра прийому подій
-
Відстеження в реальному часі та специфікації інформаційної панелі
-
Повна логіка тарифікації та етапи автоматизації виставлення рахунків
Створюйте клієнтські дашборди використання & Сповіщення
Глибше розуміння використання стосується можливості користувачів керувати майбутніми витратами. Клієнтський дашборд відображає споживання, вартість місячної підписки, та суму залишкового ліміту.
Автоматичні сповіщення надсилаються після досягнення визначеного рівня використання, що дозволяє командам розглянути можливість скорочення активності або зміни бюджетних асигнувань.
це прозорість впливає на передбачуваність кінцевих сум рахунків та корелює зі змінами в клієнтській базі.
| Поріг сповіщення | Подія-тригер | Дія клієнта |
| 50% ліміту | Проміжний етап споживання у циклі | Інформаційний лист про поточний темп витрат |
| 80% ліміту | Наближення до лімітів плану | Попередження щодо оптимізації використання або оновлення |
| 100% дозволеного обсягу | Ліміт тарифного плану досягнуто | Можливість увімкнути автоматичну оплату за перевищення або жорсткі обмеження використання |
Існує взаємозв'язок між непередбачуваними рахунками та фінансовими міркуваннями, що може стосуватися відтік. Створіть систему сповіщень що спрацьовує, коли клієнт досягає встановлених порогових значень рівня кредиту, таких як 50%, 80% та 100%. Користувачі можуть використовувати ліміти витрат або кредитні гаманці для регулювання бюджету та покриття інфраструктурних витрат.
Операційні витрати користувача AWS становлять 1,3 млн доларів США на місяць, які припадають на тестові скрипти без визначеної поточної функції. Автоматичні порогові сповіщення можуть допомогти уникнути таких стрибків, інформуючи відповідних осіб про те, що споживання виходить за історичні ліміти.
Пропонуйте як передоплачені, так і післяплачені варіанти виставлення рахунків. Попереднє поповнення кредиту для клієнтів пов'язане зі здатністю власників корпоративних облікових записів контролювати свої річні бюджети.
БЕЗКОШТОВНИЙ Дієвий Чеклист Тарифікації за Споживанням
Налаштуйте лічильникову тарифікацію, ціноутворення на основі використання та автоматизоване виставлення рахунків SaaS без зусиль.
-
Основні критерії вибору метрик використання
-
Покрокові вимоги до конвеєра прийому подій
-
Відстеження в реальному часі та специфікації інформаційної панелі
-
Повна логіка тарифікації та етапи автоматизації виставлення рахунків
Підключіться до системи виставлення рахунків SaaS
Останній крок — це зв'язати ваші узгоджені дані про використання з автоматизованому виставленні рахунків системою для здійснення платежу. Наприкінці кожного розрахункового періоду, оцінені нарахування додаються до базових підписок, регіональних податків та активних знижок, щоб створити детальний рахунок-фактура.
Автоматизовані білінгові системи обробляють платежі через мерчант-рахунки, а потім зберігають інформацію в головних бухгалтерських системах. Цей крок призначений для полегшення послідовної передачі продуктів, даних про використання та коштів з банку.
Зазначені фактори призводять до процесу з іншим ступенем операційних зусиль порівняно з фіксована ставка виставленням рахунків. Податкова сума не визначається до кінця періоду; отже, податок має розраховуватися для кожної юрисдикції під час генерації рахунка замість того, щоб під час створення всього плану.
Передплачені картки вносять додатковий фактор у поточні розрахунки. Кредити класифікуються як актив на етапі продажу, перетворюючись на зобов'язання після розгортання, при цьому дохід генерується за рахунок їх використання, а не початкового розповсюдження.
При налаштуванні нової інсталяції одним із принципів є уникнення конфліктних подій, тому переконайтеся, що використовуються унікальні поля event_id. Також усі серверні журнали мають бути в UTC і, що не менш важливо, мати локальний буфер для збереження будь-яких подій, які могли бути зібрані, коли сервер не працював.
PayPro Global виступає як Merchant of Record (MoR) з платформою для керування глобальну обробку платежів, створювати рахунки, обробляти місцеві валюти, дотримуватися міжнародних податкових нормативів (VAT/GST), та ефективно захищатися від чарджбеків на єдиній платформі.
Висновок
Щоб досягти модель ціноутворення SaaS за використання, необхідно визначити чіткі метрики споживання, запровадити ідемпотентний пайплайн подій, та забезпечити клієнтів видимістю в реальному часі щодо їхньої діяльності. Цей технічний процес називається Тарифікація за показниками.
Ці кроки створюють основу для автоматизованого процесу білінгу SaaS який пов'язує від використання до доходу. Інструменти моніторингу та порогові сповіщення може впливати на виникнення проблем з виставленням рахунків та стабільність функціонування.
Поширені запитання
-
Тарифікація за використання – це бізнес-стратегія, за якої сума, що стягується з клієнтів, залежить від активності використання продукту. Тарифікація за споживанням – це технічний процес, що включає вимірювання, агрегацію та виставлення рахунків за споживання.
-
Так, такий тип ціноутворення називається гібридною моделлю ціноутворення. Клієнти сплачують фіксовану суму за підписку на платформу, плюс плату за кожну додаткову функцію або програму. При тарифікації за споживанням клієнтам виставляється рахунок за кожну одиницю продукту чи послуги, наприклад, води або електроенергії.
-
Виберіть метрику, яка прямо пропорційна цінності, яку користувач отримує від вас, наприклад, кількість викликів API, збережених ГБ або обчислювальних годин. Одиниця виміру повинна бути простою та зрозумілою у рахунку та легкою для вимірювання командою інженерів..
-
Уникніть неприємних сюрпризів, відображаючи фактичне використання та витрати на клієнтському лічильнику або інформаційній панелі, що оновлюється в реальному часі протягом усього розрахункового періоду. Крім того, важливо створити порогові значення, щоб сповіщати користувачів, коли їхнє споживання досягає певного відсотка від бюджету.
-
Ідемпотентність — це властивість системи, яка гарантує, що якщо одна й та сама подія надсилається кілька разів і має той самий унікальний ідентифікатор, вона буде оброблена лише один раз. Це допомагає запобігти стягненню плати з клієнтів за ненадані послуги шляхом врегулювання ситуацій, коли клієнти повторно подають заявку з тією ж інформацією протягом короткого проміжку часу, а база даних ще не очистила попередні дані заявки.
-
Встановіть розумний ліміт часу — зазвичай від 24 до 72 годин — протягом якого запізнілі події можуть бути зібрані та інтегровані в активний платіжний цикл. Усе, що відбувається після часу відсікання, має бути перенесено на наступний період або оформлено як коригування кредиту.
-
На відміну від фіксованих підписок, тарифікація за споживанням залежить від змінної щомісячної регулярної виручки, що отримується від використання клієнтами. Щоб покращити грошовий потік, багато організацій вимагають мінімального щомісячного зобов'язання або попереднього поповнення балансу кредитними картками.
-
Вам потрібен конвеєр обробки подій, що включає черги повідомлень, систему агрегації для отримання значущої інформації з вихідних метрик та механізм оцінки. Цей шар, розташований між застосунком і платіжним шлюзом, призначений для впливу на пропускну здатність та забезпечення аудиту даних.
Готові розпочати?
Ми були на вашому місці. Дозвольте поділитися нашим більш ніж 20-річним досвідом і втілити ваші глобальні мрії в реальність.
Українська 
English 
Español 
Português 
Português do Brasil 
Français 
Italiano 
Deutsch 
Nederlands 
Polski 
Română 
简体中文 
日本語 
한국어