Практики успішної монетизації API на базі Microsoft Management API

Всім привіт!
Сьогодні хочемо обговорити тему управління API. Коли має сенс відкривати свій API, хто має можливість монетизувати свій API і як впровадити систему API менеджменту, щоб витрати, як на початкове впровадження, так і на його експлуатацію були мінімальні.



Ми хочемо поділитися своїм досвідом розробки системи управління API на базі Microsoft Management API. Давайте почнемо з самого початку.

1. ЛІКНЕП. КОЛИ ПОТРІБНО УПРАВЛЯТИ API
1.1. Коли відкривати API?
Якщо ви розумієте, що ваші дані, контент або унікальна бізнес-логіка можуть бути корисні іншим компаніям і людям – API можна відкривати.

Як тільки ви розумієте, що ваші API допомагають розвитку бізнесу ваших користувачів – можна пропонувати доступ до API за плату.
Якщо у вас трохи користувачів, ви можете надавати доступ і збирати плату вручну. А якщо багато, вам швидше за все знадобиться API Management система. (API Management system).

1.2. Навіщо потрібна API Management система?
Коротко можна сказати, що призначення Management API системи – це перетворити API в продукт, тобто наділити чисто технічну сутність реальним бізнес-змістом. Більшість API Management систем, на справжній, можуть наступне:
  • Організовувати доступ до API.
  • Визначати політики використання API (повнота запитів, їх частота і ліміт в одиницю часу).
  • Надавати засоби документування API.
  • * Організувати платний доступ до API з урахуванням політик.


2. НЕ ВСІ MANAGEMENT API СИСТЕМИ ОДНАКОВО КОРИСНІ
Наш замовник — велика метеорологічна компанія, велика частка бізнесу якої полягає в платному надання даних, одержаних з метеорологічних станцій. Кілька років тому вона однією з перших у галузі вирішила також відкрити і надавати платно свої API. І на даний момент пропонує клієнтам 14 видів API продуктів, що відрізняються тим, які набори API включені в продукт, який ліміт на використання сету продуктів встановлений.

Для розуміння масштабу проекту, на поточний момент API замовника використовують 4200 розробників, 2400 компаній.

Наша спільна історія – це вже третя спроба замовника реалізувати API менеджмент систему для успішної монетизації своїх сервісів. Перший раз було рішення на основі Mashery, другий раз Apigee, а потім Azure Management API. Як водиться, у російській традиції, з третього разу, зазвичай, все вдається. Тут вийшло саме так.

У результаті ми, по суті, зробили кастомное рішення по управлінню API, в рамках якого:
  • Інтегрували Azure Management API з системою управління ідентифікацією та підписками клієнта.
  • Надали єдиний вхід для роботи з порталом замовника та порталами Online Management API.
  • Зробили оплату через PayPal і інтеграцію з CRM системою SalesForce.


2.1. А що було не так з першими двома?
Потрібно почати з того, що компанія обидва рази вибирала лідерів ринку – Mashery і Apigee. І після року використання йшли від кожного з них. Звучить якось дивно. Це ж лідери?!



По суті вимоги до API менеджмент-систему можна звести до двох основних пунктів:
  1. вартість користування
  2. UX, причому UX як користувача, так і адміністратора
І саме за цими параметрами системи-лідери не були прийняті замовником.

2.2. Вартість користування
Схема монетизації Mashery не дозволяла заздалегідь отримати передбачувану оцінку витрат, і вони дуже швидко стали потужному високими.

Вартість використання Apigee з вбудованою платіжною системою була просто космічної і по суті забирала всі доходи від продажу API.

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

2.3. UX
Крім того, замовники зізналися, що вважають UI Apigee занадто складним та заплутаним. Для порівняння наводимо логічні архітектури Apigee і Azure API Mаnagement:



Як бачите, архітектура Microsoft Management API більш проста. У ній менше елементів. Отже, вона більш проста для розуміння як адміністраторам, так і користувачам.

3. АРХІТЕКТУРА НАШОГО ВИРІШЕННЯ
Архітектура нашого рішення виглядає так:


3.1. В центрі всього – система управління ідентифікацією та підписками (EM).
Вона оперує такими об'єктами:
  • Організація та її користувачі (Authentication).
  • Каталог продуктів для підписки, в тому числі API продукти.
  • Передплата (Authorization) — зв'язок між користувачем і продуктом.


3.2. Користувач взаємодіє з нею через інтерфейс порталу (EM Web Front). Azure API Management управляє доступом до набору наших API.
Основні об'єкти тут це:
  • API — логічна сутність представляє ваш API.
  • Політика — обмеження на використання API. Наприклад, кількість запитів в місяць або обсяг переданих даних.
  • Користувач — у найбільш частому випадку це розробник який буде використовувати ваш API в своєму додатку.
  • Передплата – зв'язка користувача з продуктом.
Azure Management API – з технічної сторони представляє з собою WEB-proxy, яка представляється користувачеві і перенаправляє дзвінки відповідного API на стороні Backend, з урахуванням застосування.

3.3. Блок APIM дозволяє безболісно мапить користувачів EM c користувачами в Azure.

3.4. Окремо виділено універсальний блок обробки платежів – Payments, який поки підтримує в тому числі і повторювані платежі (Recurring Payments). Поки він інтегрований тільки з PayPal. У майбутньому, планується сюди ж підключити Apple Pay і Google Pay

В результаті зараз на порталі користувач одноразово:
  • робить вибір одного з трьох наборів, що охоплюють всі 14 можливих API продуктів,
  • вибирає тариф, який визначає допустиму частоту запитів і загальний ліміт запитів в місяць,
  • переходить до оплати.
Система управління підписками в режимі реального часу отримує дані про оплати і активує доступ.

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


4. КОЛИ ПОТРІБЕН КАСТОМНИЙ АВТОМАТИЗАЦІЯ?
Давайте скажемо чесно – будь-яка «готова» платформа при зустрічі з реальним бізнесом зазвичай потребує доопрацювання. Хоча функціональність «з коробки» надає всі необхідні базові інструменти, які можна і потрібно використовувати для перевірки своїх бізнес-ідей.

Поки користувачів мало, управляти доступом до API можна вручну взявши продукт з коробки без костюмних доробок.
В принципі, всі кроки досить зрозумілі:
  1. Синхронізуємо списки користувачів Online Management API і EM системах.
  2. Синхронізуємо продукти у EM і відповідні продукти Microsoft Management API.
  3. На порталі EM робимо посилання на PayPal для підписки.
  4. При отриманні повідомлення від PayPal – заводимо підписку EM – системі, а також відповідну підписку в Microsoft Management API.
  5. При закінченні терміну дії підписки, видаляємо користувача з підписки в Azure API і EM системах, якщо оплата не була проведена.
Подписочная схема надання Azure API Management в даному випадку дуже зручна – вона дозволяє перевірити концепцію без значних фінансових вкладень в API Management систему та інтеграцію.

А припустимо, що користувачів стає більше. У нашого клієнта понад 4000 активних передплатників. Як розумієте, кількість ручної праці на синхронізацію і надання/відключення доступу стає відверто високим. Однак і коштів від продажу доступу до API нам надходить також більше, і тепер можна вкластися в те, щоб можна автоматизувати ці кроки:
  • Щоб синхронізувати списки користувачів Online Management API є механізм делегації. При вході на developers portal він дозволяє перенаправити користувача, на наш портал, звідки він повертається вже авторизованим. Докладніше описано azure.microsoft.com/en-en/documentation/articles/api-management-howto-setup-delegation
  • Далі пишемо спеціальний сервіс, який дозволяє зіставляти продукти Microsoft Management API з продуктами в каталозі EM системи.
  • Також як і в ручному режимі, на порталі EM робимо редирект на сайт PayPal для підписки. Тут же налаштовуємо можливість повторюваних (recurring) платежів.
  • Наступна завдання – завести підписку при проходженні платежу. PayPal – вміє посилати повідомлення про підтвердження платежу у вигляді дзвінка нашого сервісу, EM-системі. Цей сервіс, заводить, підписку EM, і транслює зміни в Microsoft Management API. Обробник відповідного повідомлення заводить підписку використовуючи Microsoft Management API Rest API: msdn.microsoft.com/en-us/library/azure/dn776325.aspx
  • І, нарешті, після закінчення терміну дії підписки користувача потрібно видалити. Для цього в EM системі ми додавали до підписці аттрибут «дата закінчення». І все, що нам потрібно зробити, це написати JOB, який періодично перевіряє термін дії підписки у EM і блокує доступ до Microsoft Management API.


5. РАЗОМ
Якщо ви тільки замислюєтеся про те, чи варто надавати платний доступ до ваших API сервісів, подписочная схема Azure Management API дозволяє швидко і без капітальних вкладень перевірити вашу бізнес-концепцію.

Коли є розуміння, що на ваш API є достатній попит, кастомное рішення на базі Microsoft Management API дозволить вам забезпечити:
  • Легкість управління. Архітектура платформи Azure APIM дозволяє максимально легко здійснювати управління API.
  • Глибоку інтеграцію серверної частини з порталом.
  • Гнучку інтеграцію з зовнішніми платіжними системами, зручними для замовника.
  • І, звичайно, економічну ефективність платного надання API. У нашому кейсі порівняно з Mashery постійні кости знизилися в 10 разів! Так, були разові витрати на розробку проекту. І клієнт відраховує платіжній системі комісію з кожної операції. Але це вже витрати з прибутку. Яка нарешті з'явилася.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.