Що таке гейтування функцій SaaS?

Управління доступом до функцій у SaaS — це практика обмеження або надання доступу до функцій програмного забезпечення на основі рівнів підписки, організаційної ролі користувача або поточного статусу оплати. Замість того, щоб надавати окремі збірки програмного забезпечення різним категоріям клієнтів, єдина кодова база може динамічно змінювати інтерфейс користувача (UI) та доступ до бекенду для користувачів на основі заздалегідь визначених правил тарифікації або пакетів.

Хоча їхні технічні основи майже ідентичні (умовна логіка в коді), їхні цілі та життєві цикли абсолютно різні:

• Функціональні прапорці — це інструменти, що переважно використовуються в контексті розробки, передбачуваний період використання яких зазвичай обмежений. Вони дозволяють інженерам розгортати код у продакшн за певних умов, різних варіантів (A/B) або випускати програмне забезпечення невеликими партіями. Після того, як код пройшов тестування і розробники вирішили випустити його для всіх користувачів, потреба у відповідному функціональному прапорці зникає. Розробники можуть вирішити виключити цей визначений розділ коду.
• Функціональні ворота виступають інструментом для визначення меж продукту; остаточні рішення щодо цих меж приймаються керівництвом, а не розробниками. Функціональні ворота дозволяють команді продукту та продажів керувати різними ціновими рівнями та політиками пакування (наприклад: Free, Pro, Enterprise). Існування цих обмежень є необхідною умовою для успіху моделі підписки. Саме тому вони зберігаються у вихідному коді, навіть протягом багатьох років, якщо це необхідно.

У моделях PLG або фріміум характеристики продукту пов’язані із залученням та утриманням клієнтів. Обмеження доступу до функцій (feature gating) у цьому сценарії працює таким чином:

• Автоматизація воронки конверсії передбачає, що система спонукає безкоштовних користувачів до оновлення (механізм ‘оксамитового канату’) при спробі доступу до Pro-функцій. Це може зменшити пряму участь менеджерів з продажу.
• Для ознайомлення користувачам надається призначена версія програмного забезпечення. Оплата не є умовою для її використання. Саме на більш потужні та складні функції (наприклад, поглиблена аналітика, співпраця або API) їм потрібно оформити підписку, щоб розблокувати їх через блокування функцій, тим самим перетворюючи їх на самостійне оновлення.
• Управління лімітами на основі використання — це баланс між обсягом використання безкоштовного плану та вашими платними планами. Наприклад, якщо користувач має кредитний ліміт у 5 щомісячних кредитів (або функцій, що базуються на використанні) і витратив 3 з них, то завдяки feature gate можна м'яко підштовхнути до платних пакетів, оскільки вони стають все більш залежними від вашого програмного забезпечення.

Існує відображення функцій і планів (матриця прав) — центральна конфігурація, яка пов'язує технічні функції з комерційними тарифними планами.

1. Права доступу в основі: Спочатку потрібно розбити ваш застосунок на найпростіші функції, що контролюються правами доступу, наприклад, export_pdf, sso_login, max_team_members тощо.
2. Не зашивайте функції та плани безпосередньо в логіку продукту: Замість того, щоб “Pro Plan” був жорстко закодованим прапорцем функції у вашій програмі, його слід змінювати, перевіряючи право доступу (if (user.hasEntitlement(‘sso_login’))).
3. Налаштування: Матриця прав доступу — це, наприклад, файл конфігурації (JSON/YAML) або таблиця бази даних. Кожна функція програми є рядком у таблиці, тоді як тарифні плани підписки представлені в стовпцях. Саме через цю таблицю кожна програма має бути активована відповідно до прав користувача, пов’язаних з його підпискою. Крім того, це спосіб визначити, чи є певне право доступу бінарним (наприклад, feature1: true, feature2: false) чи ні (наприклад, feature1: limit = 70; feature2: limit = 100). Цей єдиний документ слугує центральною точкою відліку для інформації, яку спільно використовують бізнес- та технічні команди.

SaaS-компанії зазвичай обирають один із трьох архітектурних підходів для реалізації контролю доступу до функцій:

1. Права доступу білінгового рушія

Цей метод використовує прямі виклики API до платіжна система для перевірки підписок клієнтів та з'ясування, які функції їм доступні.

Встановлення цієї системи є простим, якщо виставлення рахунків вже керується через білінгову платформу.

Процеси верифікації API впливають на час виконання операцій, а кодова база часто тісно пов'язується з фінансовими/білінговими системами.

2. Прапорцеві SDK

Платформи для керування функціями, які розробники можуть використовувати для оцінки шлюзів. Розробники надають атрибути користувачів (наприклад, рівень: ‘підприємство’) до SDK, яка потім виконує локальну оцінку правил доступу.

Атрибути системи включають її швидкість обробки, опції правил таргетування, які вона надає, та її операційну узгодженість.

Ручна синхронізація атрибутів користувачів між платіжними подіями та платформою прапорців необхідна для забезпечення своєчасних оновлень протягом декількох хвилин.

3. Керовані платформи прав доступу

Їх спеціально розроблено для управління архітектурою ціноутворення SaaS. Вони діють як посередник між системою білінгу та кодом застосунку, обробляючи як прапорці функцій, так і складне мультиорендне ціноутворення на нативному рівні.

Можливості охоплюють модифікації ціноутворення з використанням передової логіки, індивідуальні параметри замовлення для клієнтів та підтримку переходу клієнтів між варіантами оплати без залучення розробників.

Залучення стороннього фахівця означає, що основні функції застосунку взаємодіятимуть із зовнішніми системами. Це додає ще один шар до базового стеку застосунку.

Переваги керування доступом до функцій SaaS включають:

• Загальний опис очікуваного покращення шляху клієнта повідомляє про вимоги для переходу на наступний рівень, що може вплинути на складність процесу продажу.
• Аналіз доходу по функціях надає дані командам розробки функцій для виявлення можливостей для певних оновлень. коефіцієнти конверсії що передбачають розблокування (що може вплинути на розподіл інженерних ресурсів).
• Автоматизована PLG воронка конверсії може скоригувати залежність від продажів з високим рівнем взаємодії, оскільки клієнти мають можливість керувати оновленнями продуктів і послуг у додатку.
• Маркетинг та продуктові операції можуть налаштовувати нові пакети, доповненьабо пробні тарифи через інтерфейс інформаційної панелі, впливаючи на залучення інженерних ресурсів для розгортання коду.