Это черновик первых двух глав раздела «API как продукт».
моя книга о дизайне API. Когда мы говорим об API как о продукте, необходимо четко указать два важных момента.
- API полный продукт , как и другое программное обеспечение.
Вы так же «продаете» его, и к нему в полной мере применимы принципы продакт-менеджмента.
Крайне сомнительно, что вы сможете качественно разработать API, не изучив потребности аудитории, спроса и предложения, рынка и конкурентов.
- API очень специфический продукт .
Вы продаете возможность выполнять какие-то действия автоматически посредством написания кода, и этот факт накладывает большие ограничения на управление продуктом.
программно .
Это не праздный вопрос, поскольку, по опыту автора этой книги, именно отсутствие экспертизы у продакт-менеджеров и маркетологов в области работы с API является самой большой проблемой в разработке API. Конечный пользователь взаимодействует не напрямую с вашим API, а с приложениями, которые разработчики написали поверх API в интересах какого-то стороннего бизнеса (а иногда в цепочке между вами и конечным пользователем бывает более одного разработчика) ).
С этой точки зрения целевая аудитория API представляет собой своеобразную пирамиду, напоминающую пирамиду Маслоу:
- основание пирамиды — пользователи; они ищут удовлетворения каких-то своих потребностей и не думают о технологиях;
- средний уровень пирамиды – бизнес-клиенты; Сопоставляя потребности пользователей с техническими возможностями, озвученными разработчиками, бизнес создает продукты;
- вершина пирамиды — разработчики; Именно они работают напрямую с API и решают, какой из конкурирующих API выбрать.
Если менеджерами по продукту API являются бывшие или нынешние разработчики, они зачастую склонны оценивать конкуренцию на рынке API именно в этом аспекте, и основные усилия направлять на продвижение продукта именно среди аудитории программистов.
"Ждать!" - воскликнет здесь внимательный читатель.
Но здесь ситуация прямо противоположная:
- разработчики, как правило, это наемные сотрудники, выполняющие задачи, поставленные заказчиком (и даже если речь идет о каком-то одном разработчике, он все равно выбирает API в интересах проекта, т.е.
выступает здесь как бизнес-заказчик для себя) ;
- бизнес, в свою очередь, ставит задачи перед разработчиками не из чувства стиля или из соображений красоты кода — заказчик заинтересован в реализации конкретного функционала, необходимого для решения пользовательских задач;
- наконец, пользователь вообще не разбирается в технических аспектах решения: он выбирает тот продукт, который ему нужен, и требует, чтобы он обладал определенным функционалом.
Истина, конечно, лежит где-то посередине.
В некоторых предметных областях и на некоторых рынках все решения принимаются разработчиками (например, какой фреймворк выбрать); в других областях и на других рынках последнее слово остается за бизнес-заказчиком и конечным пользователем.
Кроме того, многое зависит от конкурентной ситуации – если выход на рынок фронтенд-разработки с новым фреймворком не встречает никакого противодействия, то разработка, например, новой мобильной операционной системы требует многомиллионных затрат на продвижение и стратегическое партнерство.
Здесь и далее мы опишем некий «средний» случай, в котором важны все три уровня нашей двойной пирамиды: пользователи (которые выбирают правильный продукт), бизнес (которого волнуют вопросы обеспечения качества и стоимости разработки) и разработчики (которых интересует в простоте использования API и его функциональности).
Бизнес-модели API
Прежде чем перейти непосредственно к принципам управления продуктами API, сосредоточим внимание читателя на вопросе о том, какую выгоду компании приносит наличие API как продукта, а также соответствующие модели монетизации, прямые и косвенные.Этот вопрос, как мы покажем в следующих главах, далеко не праздный, поскольку напрямую влияет на KPI API и принятие решений.
[В квадратных скобках мы приведем примеры таких моделей применительно к нашему примеру обучения с API кофемашины.
]
1. Разработчик = конечный пользователь
Самая простая и понятная ситуация, если разработчиками являются конечные пользователи.Прежде всего, речь идет о всевозможных инструментах для программиста: API языков программирования, фреймворках, операционных системах, библиотеках компонентов, игровых движках и так далее — иными словами, об интерфейсах общего назначения.
[В нашем примере с кофе это означает следующее: мы разработали библиотеку для заказа кофе, возможно, с визуальными компонентами, и теперь продаем ее всем, кто владеет сетью кофемашин, чтобы им было проще разработать собственное приложение .
] В данном случае ответ на вопрос «почемуЭ» предоставить программный интерфейс» не требует пояснений.
Существует множество видов монетизации такого API — по сути, речь идет о моделях монетизации ПО для разработчиков как таковых.
- Фреймворк/библиотека/платформа может быть платной сама по себе, т.е.
распространяться по платной лицензии; В настоящее время такие модели становятся менее популярными из-за растущего проникновения программного обеспечения с открытым исходным кодом, но, тем не менее, по-прежнему широко распространены.
- API может лицензироваться по открытой лицензии с определенными ограничениями, которые можно снять путем приобретения расширенной лицензии; это может быть как ограничение функциональности API (например, запрет на публикацию приложения в соответствующем магазине приложений или невозможность сборки приложения в производственном режиме без покупки лицензии), так и ограничения на использование (например , открытая лицензия может быть «заразной», т.е.
требовать, чтобы код, написанный поверх платформы, распространялся под той же лицензией, или использование бесплатного API может быть запрещено для определенных целей).
- API может быть бесплатным, но компания-разработчик API может предоставлять платные услуги по консультированию и внедрению или просто продавать расширенную техническую поддержку.
- Разработку API может явно или неявно спонсировать владелец платформы или операционной системы [в нашем примере с кофе — производитель умных кофемашин], который заинтересован в том, чтобы у разработчиков было как можно больше удобных инструментов для работы с платформой.
.
- Наконец, компания, разработавшая API, публикуя его под открытой лицензией, тем самым привлекает внимание и надеется увеличить продажи других своих продуктов для разработчиков.
Известны случаи, когда сторонние компании или даже пользователи-энтузиасты самостоятельно реализовывали альтернативные реализации популярного API — так произошло, например, с Java API (альтернативная реализация от Google) и C# (проект Mono) — или каким-то отдельным успешные решения в проектировании функциональности (такие, например, как концепция работы с DOM-деревом путем выбора элементов с помощью CSS-селекторов, изначально появившаяся в проекте cssQuery, позже реализованная в jQuery, причем уже на волне популярности последней был адаптирован непосредственно разработчиками спецификации DOM).
2. API = основной и/или единственный способ доступа к сервису.
Этот случай связан с предыдущим в том смысле, что потребителем API является разработчик, а не конечный пользователь — с той разницей, что продуктом является не сам API, а сервис, к которому он предоставляет доступ.
Чистый пример — API различных облачных платформ, например, Amazon AWS или Braintree API. Да, некоторая работа с платформой возможна через UI, но без API такие сервисы практически бесполезны.
[В нашем примере с кофе, если мы являемся оператором сети облачных кофемашин и доставки кофе дронами, и предоставляем доступ к ним только через API.] Как правило, в этом случае взимается плата за использование самого сервиса, а не API как такового.
Однако зачастую тарифы рассчитываются именно на основе сущностей API, т.е.
взимается плата за количество вызовов методов.
3. API = партнерская программа
Многие коммерческие сервисы предоставляют доступ к своей платформе сторонним разработчикам с целью увеличения продаж или привлечения аудитории.Примеры таких API включают, например, партнерские программы Google Books, API Skyscanner Travel или API Uber. [Наша модель тематического исследования такова: мы — крупная и известная сеть кофеен, и мы стимулируем сторонних разработчиков продавать наш кофе через их веб-сайты и приложения; по сути, мы допускаем более интерактивную и глубоко интегрированную рекламу нашего сервиса — то, что сегодня принято называть «нативной рекламой».
] В этом случае партнерство полностью и исключительно коммерческое: потребители API монетизируют собственную аудиторию, а поставщик API Таким образом компания надеется получить доступ к расширенной аудитории и дополнительным рекламным каналам.
Как правило, владелец API выплачивает вознаграждение партнерам за каждое целевое действие и устанавливает требования к эффективности интеграции (например, в виде минимального соотношения кликов и таргетов), чтобы избежать злоупотреблений API.
4. API = дополнительный доступ к сервису
Если компания обладает какой-то уникальной экспертизой, чаще всего набором данных, которые сложно и/или очень дорого получить самостоятельно, логично, что появится спрос на предоставление этой экспертизы через API. Самый классический пример такого типа API — картографические API; сбор подробных и точных геоданных и поддержание их в актуальном состоянии обходится очень дорого; Более того, практически все услуги, которые только можно придумать, станут существенно лучше и удобнее, если вы добавите карту.[Этот подход сложен для нашего примера с кофе, поскольку данные, которые мы накапливаем в этом случае — расположение кофемашин и типы напитков, которые они готовят, — не имеют самостоятельной ценности вне контекста заказа кофе.
] Этот случай, пожалуй, самый интересный с точки зрения разработчика API, поскольку наличие программного интерфейса в этом случае действительно является мультипликатором возможностей: компания, владеющая экспертизой, физически не способна реализовать все сервисы в мире, которые используют этот опыт. Предоставление API здесь — «беспроигрышная» стратегия: улучшается функциональность сторонних сервисов, а компания-провайдер зарабатывает на этом.
Доступ к API в этом случае, безусловно, может быть платным, хотя более распространены смешанные модели монетизации: API предоставляется бесплатно до достижения определенного лимита или при соблюдении определенных условий (например, для некоммерческих проектов).
В некоторых случаях API предоставляется бесплатно с минимальными ограничениями в целях популяризации той или иной платформы (например, Apple Maps).
Отдельно следует упомянуть об услугах B2B. Поскольку в интересах поставщика услуг предоставить клиенту как можно больше разнообразия, а клиент, в свою очередь, часто хочет использовать доступный функционал как можно более гибко, предоставление API зачастую является лучшим вариантом для обеих сторон.
Крупным компаниям, имеющим собственные отделы разработки, часто необходимо программировать свои бизнес-процессы с помощью API и интегрировать их со своими внутренними системами.
Зачастую таким B2B-сервисом является сама компания — разработчик API, если собственные сервисы компании построены поверх API, а внешний API существует в дополнение к внутреннему (или даже «в аренду»).
5. API = рекламная платформа
В основном речь идет о различного рода виджетах и поисковых системах: чтобы разместить любую рекламу, нужно иметь прямой доступ к конечному пользователю.Наиболее распространенными API этого типа являются собственно API рекламных сетей, но существуют и комбинированные подходы, когда вместе с каким-то API, например поисковым, реклама отображается «в нагрузке».
[В нашем примере с кофе, если наша функция поиска предложений по напиткам каким-то образом начала выделять платные показы на странице результатов.
]
6. API = самореклама и самопиар
Если у API нет монетизации, прямой или косвенной, он все равно может приносить доход за счет развития знаний о компании посредством брендинга — отображения логотипов и других узнаваемых элементов, когда пользователь взаимодействует с API, в исходном виде (если визуальные интерфейсы визуализируются непосредственно с помощью API).сам API) или договорной (потребители API по договору обязаны размещать определенные элементы брендинга, где используется функционал API или предоставляемые через него данные).
Целью компании-разработчика API в данном случае является либо привлечение аудитории к своим основным сервисам, либо продвижение бренда в целом.
[В случае с нашим API для кофе, давайте представим, что мы предоставляем какой-то совершенно другой полезный сервис, скажем, мы продаем автомобильные шины, и посредством предоставления API для кофемашин мы пытаемся повысить осведомленность и заработать репутацию технологической компании.
] При этом возможны вариации относительно целевой аудитории саморекламы:
- вы можете работать над узнаваемостью бренда среди конечных пользователей (размещая свои логотипы и ссылки на сайтах и приложениях партнеров, использующих API) и даже строить таким образом сам бренд [например, если наш кофейный API будет предоставлять рейтинги кофе магазинов, и мы будем работать над тем, чтобы потребитель сам требовал от кофеен указания рейтинга по нашему сервису];
- вы можете работать над распространением знаний о себе среди бизнес-аудитории [например, чтобы партнеры, размещающие виджет заказа кофе, также изучали ваш каталог шин];
- Наконец, вы можете распространять API исключительно с целью создания репутации среди разработчиков — для распространения информации о других ваших продуктах или для улучшения вашего имиджа как работодателя ИТ-специалистов (иногда это называется «техническим пиаром»).
Выгоды от существования таких сообществ весьма значительны: снижение затрат на техническую поддержку, удобный канал информирования о новых сервисах и релизах, возможность получить бета-тестеров разрабатываемых продуктов.
7. API = инструмент обратной связи и пользовательский контент.
Если у компании есть какие-то большие данные, то стратегией может быть выпуск общедоступного API, чтобы конечные пользователи могли редактировать данные или иным образом использовать их разметку.Например, поставщики API карт часто позволяют вам сообщить об ошибке или исправить неточность непосредственно в стороннем приложении.
[А в случае с нашим кофейным API мы могли бы собирать отзывы как пассивно — оценивая заведения, например, так и активно — связываясь с владельцами заведений, чтобы помочь им исправить недостатки; находите через UGC кофейни, которые еще не подключены к API, и активно с ними работайте.
]
8. Терраформирование
Наконец, самый альтруистический подход к разработке API — предоставить его либо полностью бесплатно, либо в формате с открытым исходным кодом и открытыми данными просто с целью изменения ландшафта: если сегодня никто не готов платить за API, то вы можете инвестировать в него.популяризация и продвижение функциональности, надежда найти коммерческие ниши (в любом из вышеперечисленных форматов) в будущем или повысить актуальность и полезность API в глазах конечных пользователей (и, следовательно, готовности потребителей платить за использование API) .
[В случае с нашим примером с кофе, если компания, производящая умные кофемашины, предоставляет API совершенно бесплатно в надежде, что со временем наличие API для кофемашин станет нормой, и можно будет разрабатывать новые монетизированные услуги из-за этого.
]
9. Серая зона
Отдельный источник дохода API-разработчика — анализ запросов конечных пользователей или, другими словами, сбор и дальнейшая продажа некоторой информации.Следует учитывать, что граница между допустимыми способами обработки информации (например, агрегирование поисковых запросов с целью выделения трендов или потенциально выгодных точек для открытия кофейни) и неприемлемыми здесь не слишком очевидна и имеет тенденцию к изменению как во времени и в пространстве (в том смысле, что одни и те же действия могут быть легальными по одну сторону государственной границы и незаконными по другую), поэтому решения о монетизации API такими способами следует принимать с большой осторожностью.
API-ориентированный подход
В последние годы наблюдается растущая тенденция предоставлять некоторые функциональные возможности в виде API (т. е.продукта для разработчиков), где теоретически услуга может предоставляться непосредственно конечным пользователям.
Такой подход известен как «API-first» и отражает растущую специализацию ИТ-сектора в целом: разработка API выделяется как отдельная компетенция, которую бизнес готов передать на аутсорсинг сторонним компаниям вместо того, чтобы тратить ресурсы на разработку внутренних API для собственных приложений.
Однако до тех пор, пока этот подход не станет общепринятым, при запуске службы, ориентированной на API, следует учитывать некоторые факторы принятия решений.
- Целевой рынок должен быть достаточно «прогретым» — на нем уже должны работать компании, обладающие достаточными ресурсами для разработки сервисов поверх вашего API, а также готовые платить за его использование (если только ваша цель — самореклама или терраформирование).
);
- Качество услуги не должно пострадать, поскольку она предоставляется через API;
- Необходимо действительно иметь пресловутый опыт разработки API, иначе велика вероятность допустить непоправимые ошибки.
Теги: #api #Управление продуктом #монетизация
-
Первый Советский Спортивный Автомобиль
19 Oct, 24 -
Атаки На Rfid
19 Oct, 24 -
Самые Короткие Научные Статьи
19 Oct, 24
