Лучшие практики биллинга на основе использования для монетизации API

Зачем монетизировать API?

Монетизация API — это отличный способ окупить инвестиции в программы API. Без прямой монетизации вы будете зависеть от других источников капитала для развития программы, таких как другие центры прибыли или венчурный капитал.

Если вы не монетизируете свои API напрямую, вы можете оставлять деньги на столе. Это может быть особенно актуально, если у вас нет никаких ограничений и вы полагаетесь на систему почета.

Сложность продажи API

Когда речь заходит о монетизации, необходимо обратить внимание на две группы проблем. Существуют как инженерные, так и бизнес-задачи. В данном руководстве будут затронуты обе эти темы, но основное обсуждение в этой статье посвящено бизнес-задачам, которые связаны со стратегией выхода на рынок (GTM) и финансами.

Бизнес-проблемы при продаже API

Продавать разработчикам сложно, что усложняет стратегии монетизации API. Даже если предполагаемый экономический покупатель вашего API-решения не является частью инженерного отдела, API являются глубоко техническими по своей природе и требуют широкого участия различных инженерных групп. В рамках любого процесса закупок вам придется обращаться к архитекторам программного обеспечения, инженерам по безопасности, юридическим специалистам и менеджерам по продуктам, каждый из которых может принять решение о покупке API-продукта или наложить на него вето.

В первую очередь обращайтесь к разработчикам

Вместо того, чтобы пытаться обратиться к каждой заинтересованной стороне, сосредоточьтесь на разработчиках, осуществляющих интеграцию. Иногда это называют developer-first или bottomoms up, цель состоит в том, чтобы побудить разработчиков интегрироваться и платить символическую сумму за API, даже если это всего 50 баксов или около того в месяц. Поступая таким образом, вы устраняете многие препятствия для покупки. Например, вместо того, чтобы требовать обширной проверки безопасности и юридической экспертизы, индивидуальный разработчик может просто просмотреть стандартные условия предоставления услуг. Закупки не участвуют, так как подписка может быть просто помещена на кредитную карту менеджера.

Продавайте через разработчиков

Только когда ваш клиент уже платит по плану самообслуживания и достигает определенных целей или объемов, можно приступать к продажам. Организация может задуматься о повышении уровня обслуживания, потому что у нее увеличился объем использования или появились расширенные требования. Это происходит только после того, как разработчики уже увидели ценность API и то, как он может соответствовать потребностям их компании.

Получение дохода от расширения

Поскольку самообслуживание и ориентация на разработчиков являются феноменальными стратегиями для начала монетизации API, обычно внедряется некая модель тарификации на основе использования, чтобы установить цену. Однако существуют различные рычаги, которые вы можете настроить в своей модели ценообразования, зависящей от специфики вашего бизнеса, чтобы получить «свою справедливую долю» от ценности, которую получает клиент.

• Биллинг с предоплатой и постоплатой
• Многоуровневые тарифы или тарифы с оплатой по факту (PAYG)
• Когда выставлять счет
• Уровень поддержки/функциональности

1. Выставление счетов: Предоплата и постоплата

Биллинг по предоплате — это когда вы оплачиваете услугу заранее, до ее потребления. С другой стороны, постоплата
это когда вы платите после того, как услуги уже потреблены.

Биллинг с предоплатой

Предоплата — это наиболее распространенная модель для традиционных SaaS и корпоративного программного обеспечения. Поскольку поставщик получает деньги вперед до оказания каких-либо услуг, модели предоплаты могут стать спасением для бизнеса и увеличить денежный поток.
Это особенно важно, если ваши затраты на приобретение или установку высоки, что позволяет вам инвестировать дальше в продукт и рост. Предоплата также выгодна для клиентов, поскольку она обеспечивает предсказуемость расходов и сокращает процессы, связанные с закупками. Покупателю программного обеспечения нужно проходить процедуру закупок только один раз в год и быть уверенным, что у него уже есть бюджет.

Постоплатная тарификация

С другой стороны, постоплата — это другая модель, при которой вы предоставляете кредит своим клиентам, пока они пользуются вашей платформой, до тех пор, пока они не заплатят. Постоплата может упростить бизнес-модели, основанные на потреблении, поскольку клиенту не нужно «угадывать», сколько он будет потреблять. Вместо этого он может просто ввести данные своей кредитной карты и позже разобраться со счетом и узнать, сколько было потрачено (как в ресторане или баре). Благодаря этим преимуществам постоплатная тарификация стала популярной в моделях, основанных на потреблении, например, в индустрии цифровой рекламы, а в последнее время и в облачной индустрии.

Однако у постоплаты есть и обратная сторона. Поскольку вы предоставляете кредит, клиенты могут злоупотреблять им в зависимости от вашего предложения (например, сценарий «обедай и ужинай»). Наличие хороших гарантий и лимитов важно для того, чтобы клиент не накопил «слишком много кредитов» до совершения покупки. Постоплата также может иметь дополнительные отмены. Клиент может использовать гораздо больше дорогостоящей услуги, чем ожидал, а потом сожалеть об этом.

2. Упаковка: Многоуровневая тарификация и оплата по факту (PAYG)

С предоплатой и постоплатой связано то, как упакована ваша услуга. Многоуровневое ценообразование — это техника упаковки, распространенная в SaaS для создания «хорошего», «лучшего» и «оптимального» плана. Клиенты могут выбрать нужный им план на основе заранее определенного набора критериев. С другой стороны, оплата по мере использования (PAYG), также называемая ценообразованием на основе использования или ценообразованием на основе потребления — ценообразование на основе метрики объема.

Многоуровневое ценообразование

Классическое многоуровневое ценообразование позволяет клиентам легко понять свои затраты и делает ценообразование более предсказуемым, что является преимуществом для крупных компаний, приобретающих программное обеспечение. Она широко распространена и хорошо понятна в индустрии SaaS, уменьшая сложности, связанные с выставлением счетов. Кроме того, ее очень легко внедрить. Вам не нужны никакие измерительные или аналитические приборы для отслеживания использования. Вы можете просто внедрить программное обеспечение для выставления счетов за подписку, такое как Recurly, Stripe или Chargebee.

Проблема многоуровневого ценообразования заключается в несоответствии между ценой и воспринимаемой ценностью. Когда клиент приближается к пределам своего тарифного плана, он, естественно, должен перейти на новый тарифный план. Однако переход на следующий тарифный план может быть значительным, что может привести к сценариям, когда клиент «не чувствует себя готовым» к переходу на следующий уровень. Это может быть преувеличено, если при построении уровней используется слишком много различных переменных. Очень редко клиент превышает все лимиты плана, вместо этого он превышает только один лимит. Однако следующий тарифный план имеет «слишком много дополнительных элементов», которые не интересуют клиента (например, дополнительные функции). В то же время вам не нужно больше трех или четырех уровней. Если их будет слишком много, это приведет к параличу принятия решений.

Ценообразование с оплатой по мере использования (PAYG)

Из-за этих проблем с многоуровневым ценообразованием используется более современный подход, при котором клиенты платят за использование. Потребители уже давно используют планы с физическим учетом, например, газовые и электрические компании. Эта концепция учета может быть применена к цифровым продуктам, которые имеют компонент использования. Как правило, учет ведется по объему транзакций, отправленным гигабайтам или уникальным пользователям.

Преимущество ценообразования на основе использования заключается в том, что разрыв между ценой и воспринимаемой ценностью значительно сокращается, поскольку клиенты платят только за то, что им нужно. PAYG является отличным ускорителем роста для компаний, ориентированных на продукты или разработчиков. Вы можете разработать план самообслуживания, который «зацепит» клиентов, а затем позволит им со временем увеличить объем использования. Другими словами, ваша модель ценообразования имеет встроенный доход от расширения.

Выбор метрики потребления

При ценообразовании на основе использования важно выбрать правильную метрику для учета и убедиться, что она примерно коррелирует с
ценности, получаемой клиентом от платформы, не допуская при этом странного поведения, создающего необычный опыт.

Допустим, ваш SaaS или API — это инструмент маркетинга по электронной почте для продаж и маркетинга. Выбор счетчика по количеству сохраненных последовательностей или кампаний будет плохой метрикой, поскольку клиент не получает ценности, сохраняя дополнительные кампании или последовательности в инструменте. Напротив, клиенты получат большие счета, если они составят значительное количество новых кампаний, даже если они не отправили ни одного письма через инструмент. С другой стороны, клиенты будут вести себя странно, например, постоянно удалять последовательность после ее отправки, хотя было бы лучше сохранить последовательность, чтобы отслеживать исторические показатели с помощью инструмента.

Клиенты получают ценность, обращаясь к потенциальным или существующим клиентам, а не от того, хранится ли последовательность в инструменте. Таким образом, более точной метрикой, соответствующей ценности для клиента, было бы количество уникальных контактов, отправленных по электронной почте в месяц, или количество отправленных электронных писем в месяц.

Общие показатели ценности

3. Выставление счетов: Повторяющиеся или основанные на пороговых значениях

После того, как вы определитесь с моделью тарификации и способом упаковки вашего предложения, вам нужно будет определить, когда будут выставляться и генерироваться счета.
В отличие от выставления счетов и упаковки, которые влияют на продукцию и команды, генерирующие доход, такие как отдел продаж, выставление счетов оказывает большее влияние на финансовые команды. При периодическом выставлении счетов вы выставляете счет клиенту по расписанию, например, в месяц или в год. С другой стороны, вы также можете выставлять счета клиентам по пороговому значению, например, при достижении определенного лимита или расхода.

Рекуррентное выставление счетов

Периодическое выставление счетов является более популярным из этих двух видов, поскольку оно было популяризировано традиционными SaaS и легко для понимания клиентами.
Вы можете выставить им счет на предоплату (обычно это фиксированная цена) или отправить счет за использование услуг клиента за предыдущий расчетный период. Покупатели корпоративного программного обеспечения обычно отдают предпочтение периодическому выставлению счетов, поскольку это предсказуемо и легче для финансовых отделов. У периодического выставления счетов есть несколько недостатков, которые обычно проявляются в экстремальных моделях с оплатой по факту. Если у вас есть клиенты с крайне низкими объемами, которые платят всего несколько пенни или долларов в месяц, плата за транзакции превысит стоимость услуг. Аналогично, если клиент может быстро набрать большое количество кредитов в течение расчетного периода или полученная стоимость является очень транзакционной, это может создать большой остаток дебиторской задолженности между расчетными периодами, даже если услуга уже была оказана. Это часто встречается в индустрии цифровой рекламы, где крупные траты могут накапливаться быстро.

Для борьбы с этой проблемой можно использовать пороговое выставление счетов. При использовании порогового метода счет не выставляется до тех пор, пока не будет достигнут определенный долларовый объем. При предоплате это означает, что клиент приобретает кредиты, которые затем можно использовать (что может произойти далеко в будущем). При постоплате счет выставляется после достижения определенного порога, например, 1000 долларов США в расходах на рекламу. Это гарантирует, что у вас есть только $1 000 неоплаченных счетов для клиента за один раз, независимо от его ежемесячных расходов. Пороговое ценообразование не лишено недостатков. Оно может значительно усложнить бухгалтерский учет, поскольку расходы не являются предсказуемыми и не привязаны точно к расчетному периоду, например, квартальному или годовому. Время может быть открытым и нечетко определенным.

Внедрение ценообразования на основе использования

Внедрение тарификации на основе использования создает дополнительные сложности, помимо типичного многоуровневого ценообразования. Вам необходим точный механизм для надежного учета использования услуг клиентами, причем в масштабах компании. Данные об использовании должны быть проверяемы и на них можно положиться при разрешении споров.
В отличие от средств регистрации или мониторинга, эти данные должны быть точными. Вам не нужен сценарий, когда вы считаете, что клиент использовал X, но у него есть доказательства обратного.

Компания Moesif выпустила набор функций биллинга на основе использования, которые упрощают настройку правил учета. Поскольку Moesif имеет готовые интеграции с такими поставщиками биллинговых услуг, как Stripe и Recurly, вся работа по сбору показателей и автоматическому выставлению счетов клиентам уже выполнена.

Подводные камни биллинга на основе использования после релиза

Помимо простого внедрения конвейера данных для обработки ценообразования на основе использования, существует ряд других проблем, особенно в управлении ожиданиями клиентов. Частой проблемой являются клиенты, которые расходуют расход гораздо быстрее, чем предполагалось, что приводит к появлению большого счета, который они не ожидали получить. Это может быть особенно актуально для API и инструментов, которые имеют компонент объема данных.

Важно обращаться к клиентам, чтобы информировать их об этом. Один из способов достижения этой цели — автоматические электронные письма, которые предупреждают клиентов об их использовании при достижении определенных заранее установленных пороговых значений. В этом случае, несмотря на то, что квота не является жестким ограничением, вы сообщаете клиенту, сколько он использовал за месяц.

Также полезно дать клиентам возможность контролировать эти пороговые значения. Никто не хочет получать 10 электронных писем в месяц о своем использовании, даже если это предсказуемый счет. Предоставление пользователям пользовательского интерфейса для настройки пороговых значений поможет им получать уведомления только тогда, когда это необходимо.

---

Хотите узнать, как клиенты используют ваши API? Попробуйте Moesif API Analytics!

---

Эта статья была первоначально написана для блога Moesif Дерриком Гиллингом, генеральным директором и основателем Moesif API Analytics.