Монетизация с использованием Управления API Azure
ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API
Современные веб-API лежат в основе цифровой экономики. Они предоставляют доступ к интеллектуальной собственности компании для третьих лиц и обеспечивают получение дохода следующим за счет:
- формирования интеллектуальной собственности в виде данных, алгоритмов и процессов;
- предоставления другим лицам возможности обнаружения и использования полезной интеллектуальной собственности в согласованном, удобном виде;
- предоставления механизма прямой или косвенной оплаты этого использования.
Успех API всегда зависит от наличия работоспособной бизнес-модели. Ценность создается и передается между всеми лицами в устойчивом виде.
Стартапы, известные компании и те, которые находятся еще на стадии развития, как правило, начинают цифровое преобразование с разработки бизнес-модели. API позволяют реализовать бизнес-модель, предоставляя простой и экономичный способ для маркетинга, внедрения, использования и масштабирования лежащей в ее основе интеллектуальной собственности.
Организации, публикующие свои первые API, сталкиваются с необходимостью принятия ряда сложных решений. Несмотря на то, что платформа Управления API Azure уменьшает риски и обеспечивает ускоренную работу ключевых элементов, организациям по-прежнему нужно настраивать и создавать свои API в соответствии с их уникальной технической и бизнес-моделью.
Разработка стратегии монетизации
Монетизация — это процесс получения денежного дохода от чего-либо в деньги, в данном случае API. Взаимодействия по API обычно включают три отдельные стороны в цепочке создания ценности:
Стратегия монетизации API включает следующие категории:
Стратегия монетизации API | Description |
---|---|
Бесплатно | API упрощает интеграцию B2B, например оптимизирует цепочку поставок. API не монетизируется, но создает существенную ценность, обеспечивая эффективность бизнес-процессов как для поставщика, так и для потребителя API. |
Платит потребитель | Пользователи API вносят оплату в зависимости от количества операций с API. В данном документе основное внимание уделяется этому подходу. |
Потребитель получает оплату | Например, потребитель использует API для внедрения рекламы на свой веб-сайт и получает долю от полученного дохода. |
Косвенная монетизация | Монетизация зависит не от количества операций с API, а от других источников дохода, обеспечиваемых с помощью API. |
Примечание.
Стратегия монетизации устанавливается поставщиком API. Она должна быть разработана в соответствии с нуждами потребителя API.
Так как на разработку влияет широкий спектр факторов, монетизация API не может быть универсальным решением. Стратегия монетизации делает ваш API отличным от предложений конкурентов и позволяет получить максимальный доход от него.
В следующих шагах объясняется, как реализовать стратегию монетизации для API.
Шаг 1. Понимание клиента
Продумайте этапы вероятного пути потребителя API от первого обнаружения API до максимального использования.
Например, этапы пути клиента могут быть следующие:
Этап пути клиента Description Исследование Предоставление потребителю бесплатной и легкой возможности опробовать API. Реализация Предоставление достаточного доступа к API для поддержки работы по разработке и тестированию, необходимой для интеграции с ним. Предварительный просмотр Предоставление клиенту возможности запустить свое предложение и понять первоначальный спрос. Первоначальное использование в рабочей среде Поддержка раннего внедрения API в рабочую среду, когда степени использования не полностью понятны и нужна готовность к неблагоприятному исходу. Первоначальный рост Предоставление потребителю API возможности увеличить степень использования API в ответ на повышение спроса от конечных пользователей. Масштабировать Стимулирование потребителя API к увеличению объемов покупок, если API стабильно активно используется каждый месяц. Глобальный рост Поощрение пользователей API, которые используют API в глобальном масштабе, путем предложения им оптимальной оптовой цены. Проанализируйте ценность, которую будет создавать ваш API для клиента на каждом этапе его пути.
Продумайте стратегию ценообразования на основе ценности, если непосредственная ценность API для клиента хорошо понята.
Рассчитайте ожидаемую степень использования API за время его существования для клиента и ожидаемое число клиентов за время существования API.
Шаг 2. Квантифицируйте затраты
Рассчитайте совокупную стоимость владения API.
Себестоимость | Description |
---|---|
Стоимость привлечения клиентов | Стоимость маркетинга, продаж и подключения. У наиболее успешных API с увеличением степени внедрения стоимость привлечения клиентов стремится к нулю. API должны в основном степени предлагать возможности для самостоятельного подключения. Они зависят от наличия документации и удобной интеграция с платежными системами. |
Технические расходы | Сотрудники, привлекаемые для создания, тестирования, эксплуатации и обслуживания API в течение времени существования. Как правило, это наиболее существенная составляющая затрат. Там, где это возможно, для минимизации расходов следует использовать услуги облачных платформ и бессерверные технологии. |
Затраты на инфраструктуру | Затраты на базовые платформы, вычисления, сеть и хранение, необходимые для поддержки API в течение времени его существования. Для реализации модели оплаты инфраструктуры пропорционально интенсивности использования API следует использовать облачные платформы. |
Шаг 3. Проведение исследований рынка
- Исследуйте рынок для выявления конкурентов.
- Проанализируйте стратегии монетизации конкурентов.
- Изучите конкретные возможности (функциональные и нефункциональные), которые они предлагают в своих API.
Шаг 4. Проектирование модели доходов
Разработайте модель получения дохода на основе результатов приведенных выше шагов. Можно работать в двух направлениях:
Измерение | Description |
---|---|
Качество обслуживания | Ограничьте предлагаемый уровень обслуживания, установив лимит на использование API. Определите квоту на вызовы API, которые можно совершить в течение определенного периода времени (например, 50 000 вызовов в месяц), а затем заблокируйте вызовы после достижения значения квоты. Можно также задать ограничение частоты, регулирующее количество вызовов, которое можно сделать за короткий период времени (например, 100 вызовов в секунду). Ограничения по общему количеству и частоте применяются совместно, чтобы пользователям не расходовали свои месячные квоты за короткий период в результате частых вызовов API. |
Price | Задайте цену за единицу услуги, выплачиваемую за каждый вызов API. |
Увеличьте доход за время существования, получаемый от каждого клиента, разработав модель, поддерживающую клиента на каждом этапе пути.
- Сделайте его максимально удобным для клиентов, чтобы масштабировать и расти:
- Предлагайте клиентам перейти на следующий уровень в модели получения дохода.
- Например, предлагайте для клиентов, которые приобретают больший объем вызовов API, более низкую цену за единицу услуги.
- Как можно проще сохранить модель доходов:
- С одной стороны необходимо предоставить достаточные возможности выбора, но при этом не следует перегружать клиентов слишком большим числом вариантов.
- Сократите количество критериев, определяющих различные уровни модели получения дохода.
- Будьте прозрачными:
- Предоставьте четкое описание различных вариантов.
- Предоставьте клиентам необходимые инструменты для выбора модели получения дохода, которая наилучшим образом соответствует их потребностям.
Определите диапазон необходимых моделей ценообразования. Модель ценообразования описывает конкретный набор правил для поставщика API, определяющих уровень дохода в зависимости от использования API клиентом.
Например, для поддержки приведенных выше этапов клиента потребуется шесть типов подписки:
Тип подписки | Description |
---|---|
Free |
Позволяет потребителю испробовать API бесплатно и без обязательств, чтобы определить, подходит ли он для конкретного варианта использования. Это устраняет все барьеры для первоначального использования. |
Freemium |
Позволяет потребителю использовать API бесплатно с возможностью перехода на платное обслуживание по мере роста спроса. |
Metered |
Потребитель API может делать столько вызовов в месяц, сколько требуется, и будет оплачивать фиксированную сумму за каждый вызов. |
Tier |
Потребитель API оплачивает установленное количество вызовов в месяц. В случае превышения этого ограничения он оплачивает определенную сумму за каждый дополнительный вызов. Если ограничение превышается регулярно, потребитель может перейти на следующий уровень. |
Tier + Overage |
Потребитель API оплачивает установленное количество вызовов в месяц. В случае превышения этого ограничения он оплачивает установленную сумму за каждый дополнительный вызов. |
Unit |
Потребитель API платит за установленное количество вызовов в месяц. В случае превышения этого ограничения он должен оплатить количества вызовов для следующего уровня. |
Модель получения дохода будет определять набор продуктов API. Каждый продукт API реализует определенную модель ценообразования для конкретного этапа в жизненном цикле потребителя API.
Несмотря на то, что модели ценообразования обычно не изменяются, может потребоваться адаптировать их конфигурацию и применение для модели получения дохода. Например, может потребоваться скорректировать цены с учетом предложений конкурента.
На основе приведенных выше примеров, применив модели ценообразования, можно создать общую модель получения дохода следующим образом:
Этап жизненного цикла клиента | Модель ценообразования | Конфигурация модели ценообразования | Качество обслуживания |
---|---|---|---|
Исследование | Бесплатно | Не реализовано. | Для потребителя устанавливается квота с ограничением до 100 вызовов в месяц. |
Внедрение | Условно бесплатно | Выпускные уровни:
|
Квота не устанавливается. Потребитель может продолжить совершать вызовы и оплачивать их с ограничением не более 100 вызовов в минуту. |
Предварительный просмотр | Измеренный объем данных | Для потребителя устанавливается оплата в размере 0,15 доллара за 100 вызовов. | Квота не устанавливается. Потребитель может продолжить совершать вызовы и оплачивать их с ограничением не более 200 вызовов в минуту. |
Первоначальное использование в рабочей среде | Уровень | Для потребителя устанавливается оплата в размере 14,95 долларов в месяц. | Для потребителя устанавливается квота с ограничением до 50 000 вызовов в месяц и не более 100 вызовов в минуту. |
Первоначальный рост | Уровень + превышение | Выпускные уровни:
|
Квота не устанавливается. Потребитель может продолжить совершать вызовы сверх установленного количества и оплачивать их с ограничением не более 100 вызовов в минуту. |
Масштабировать | Уровень + превышение | Дифференцированные уровни:
|
Квота не устанавливается. Потребитель может продолжить совершать вызовы сверх установленного количества и оплачивать их с ограничением не более 1 200 вызовов в минуту. |
Глобальный рост | Unit | Дифференцированные уровни с фиксированной суммой для каждого 749,95 доллара в месяц для 1 500 000 вызовов. | Квота не устанавливается. Потребитель может продолжить совершать вызовы сверх установленного количества и оплачивать их с ограничением не более 3 500 вызовов в минуту. |
Два примера интерпретации модели получения дохода на основе приведенной выше таблицы:
Многоуровневая модель ценообразования
Применяется для поддержки потребителей API на этапе жизненного цикла Первоначальное использование в рабочей среде. При использовании многоуровневой модели ценообразования потребитель имеет следующие обязательства и возможности:- Оплачивает 14,95 доллара в месяц.
- Может совершать не более 50 000 вызовов в месяц.
- Может совершать не более 100 вызовов в минуту.
Этап масштабирования в жизненном цикле, реализуемый путем применения модели ценообразования Уровень + превышение, в которой потребители имеют следующие обязательства и возможности:
- Оплачивают 449,95 доллара в месяц за первые 500 000 вызовов.
- Оплачивают дополнительные 0,06 доллара за каждые 100 вызовов, совершенных после первых 50 000.
- Могут совершать не более 1 200 вызовов в минуту.
Шаг 5. Калибровка
Откалибруйте цены в модели получения дохода следующим образом:
- Установите цену для API, которая не будет завышена или занижена, в соответствии с исследованием рынка в шаге 3, приведенном выше.
- В модели получения дохода избегайте любых моментов, которые несправедливы или заставляют клиентов обходить модель, чтобы получить более выгодный тариф.
- Убедитесь, что общая сумма, получаемая в соответствии с моделью на протяжении всего времени существования, покрывает общую стоимость владения и позволяет получить прибыль.
- Убедитесь, что качество предложений услуг на каждом уровне модели получения дохода может быть поддержано вашим решением.
- Например, если вы предлагаете поддержку 3 500 вызовов в минуту, убедитесь, что комплексное решение может масштабироваться для поддержки этого уровня пропускной способности.
Шаг 6. Выпуск и мониторинг
Выберите подходящее решение для получения оплаты за использование API. Поставщики, как правило, делятся на следующие две группы:
Платежные платформы, такие как Stripe
Вычислите размер платежа на основе необработанных метрик использования API, применив конкретную модель получения дохода, выбранную клиентом. Настройте платежную платформу в соответствии со стратегией монетизации.
Платежные сервисы, такие как Adyen
Применяются только для осуществления платежной транзакции. Перед использованием этого сервиса необходимо применить стратегию монетизации (например, определить размер платежа для метрики использования API).
Используйте Управление API Azure для ускорения реализации и исключения рисков благодаря встроенным возможностям, предоставляемым в Управлении API. Для получения дополнительных сведений о конкретных функциях Управления API см. раздел с описанием, как Управление API поддерживает монетизацию.
Создайте гибкое решение для реализации стратегии монетизации на основе базовых систем, используя тот же подход, что и в примере проекта. Гибкая программная реализация позволит оперативно реагировать изменения с меньшими рисками и затратами.
Для реализации примера проекта в вашей подписке Azure руководствуйтесь документацией репозитория GitHub по монетизации.
Регулярно контролируйте использование API, чтобы принимать решения на основе фактической информации. Например, если по наблюдениям происходит отток клиентов, повторите шаги 1-5 выше, чтобы выявить причину и постараться решить проблему.
Постоянное развитие
Регулярно проверяйте стратегию монетизации, повторно просматривая и переоценивая все шаги, приведенные выше. С течением времени вам может потребоваться развивать стратегию монетизации, так как вы будете больше узнавать о клиентах, о затратах на предоставление API и о том, как реагировать на изменения конкуренции на рынке.
Помните, что стратегия монетизации является только одним из множества аспектов успешной реализации API. К другим аспектам относятся следующие:
- Опыт разработки
- Качество документации
- Юридические условия
- Способность масштабировать API в соответствии с утвержденными уровнями обслуживания.
Next Steps
- Как Управление API поддерживает монетизацию.
- Разверните демонстрационную версию интеграции с Adyen или Stripe с помощью связанного репозитория Git.