Further work on Section III

src/ru/drafts/04-Раздел III. API как продукт/Идентификация пользователей.md

@@ -33,6 +33,30 @@
 
 Другая опасность заключается в том, что ключ могут банально украсть у добросовестного партнёра. В случае клиентских и веб-приложений это довольно тривиально; в случае серверных приложений проблема стоит гораздо менее остро, но популярный API рано или поздно столкнётся с тем, что украденные ключи будут выложены в свободный доступ (или владелец ключа просто будет делиться им со знакомыми по доброте душевной).
 
-Так или иначе, встаёт вопрос независимой валидации: каким образом можно проконтролировать, действительно ли ключ используется в соответствии с пользовательским соглашением.
+Мобильные приложения удобно отслеживаются по идентификатору приложения в соответствуюем сторе (Google Play, App Store и другие), поэтому разумно требовать от партнёров идентифицировать приложение при подключении API.
+
+Другая опасность заключается в том, что ключ могут банально украсть у добросовестного партнёра. В случае клиентских и веб-приложений это довольно тривиально. К тому же ключи могут украсть и выложить в свободный доступ (или владелец ключа просто будет делиться им со знакомыми по доброте душевной).
+
+Может показаться, что в случае предоставления серверных API проблема воровства ключей неактуальна, но, на самом деле, это не так. Предположим, что партнёр предоставляет свой собственный публичный сервис, который «под капотом» использует ваше API. Это часто означает, что в сервисе партнёра есть эндпойнт, предназначенный для конечных пользователей, который внутри делает запрос к API и возвращает результат, и этот эндпойнт может использоваться злоумышленником как эквивалент API. Конечно, можно объявить такой фрод проблемой партнёра, однако было бы, во-первых, наивно ожидать от каждого партнёра реализации собственной антифрод-системы, которая позволит выявлять таких недобросовестных пользователей, и, во-вторых, это попросту неэффективно: очевидно, что централизованная система борьбы с фродерами всегда будет более эффективной, нежели множество частных любительских реализаций.
+
+Так или иначе, встаёт вопрос независимой валидации: каким образом можно проконтролировать, действительно ли API используется конечным потребителем в соответствии с пользовательским соглашением.
 
 #### Идентификация конечных пользователей
+
+Если к партнёрам вы можете предъявлять какие-то требования по самоидентификации, то от конечных пользователей требовать раскрытия информации о себе в большинстве случаев не представляется возможным. Поэтому все методы контроля, описанные ниже, являются неточными и зачастую эвристическими. Кроме того, следует иметь в виду, что сбор подобного рода информации может регулироваться законодательно (хотя большей частью речь пойдёт об анонимизированных данных, но и они могут быть регламентированы).
+
+  1. Самый простой и очевидный показатель — это ip-адреса; их невозможно подделать (в том смысле, что сервер API всегда знает адрес вызывающего клиента), и поэтому статистика по уникальным ip довольно показательна.
+
+    Если API предоставляется как server-to-server сервис, доступа к IP-адресу конечного пользователя может и не быть, однако весьма разумно в такой ситуации требовать от партнёра пробрасывать IP-адрес клиента (например, в виде заголовка X-Forwarded-For) — в том числе для того, чтобы помочь партнёрам бороться с фродом и непревомерным использованием API.
+  
+    До недавнего времени ip-адрес как единица подсчёта статистики был ещё и удобен тем, что обзавестись большим пулом уникальных адресов было достаточно дорого. Однако с распространением ipv6 это ограничение перестало быть актуальным; скорее, ipv6 ярко подсветил тот факт, что не стоит ограничиваться только подсчётом уникальных ip. Необходимо следить за несколькими агрегатами:
+        * суммировать статистику по подсетям, т.е. вести иерархические подсчёты (количество уникальных сетей /8, /16, /32 и так далее);
+        * наблюдать за агрегированной статистикой по автономным сетям (autonomous networks, AS);
+        * мониторить использование известных публичных прокси и TOR Network.
+
+    Необычно высокое количество запросов из одной подсети может свидетельствовать о том, что API активно используется во внутрикорпоративной сети (или в данном регионе доступ в Интернет в основном предоставляется через NAT).
+
+  2. Дополнительным способом идентификации служат уникальные идентификаторы пользователей, в первую очередь — cookie. Однако в последние годы этот способ ведения статистики подвергается атаке с нескольких сторон: производители браузеров ограничивают возможности установки cookie третьей стороной, пользователи активно защищаются от слежения, и законодатели начали выдвигать требования в отношении сбора данных. В рамках текущего законодательства проще отказаться от использования cookie, чем соблюсти все необходимые требования.
+
+    Всё это приводит к тому, что публичным API, особенно используемым в бесплатных сайтах и приложениях, очень тяжело вести статистику, а значит и тяжело анализировать поведение пользователей. И речь здесь не только о борьбе с разного рода фродом, но и банальном анализе сценариев использования API.
+  

src/ru/drafts/04-Раздел III. API как продукт/Модели монетизации.md

@@ -1,10 +1,10 @@
-### Модели монетизации API
+### Бизнес-модели API
 
-Как мы неоднократно упоминали в предыдущих разделах, предоставление некоторой функциональности посредством программируемых интерфесов — достаточно дорогое удовольствие. Для создания и поддержания API требуется соответствующий отдел разработки, и публикация API представляет собой принятие определённых обязательств по поддержке, от которых нельзя так просто отказаться. Возникает логичный вопрос, зачем и почему вообще предоставлять функциональность именно в виде API, т.е. продукта для программистов, вместо того, чтобы ограничиться продуктом для конечного потребителя. Рассмотрим здесь различные ситуации, когда публикация API может быть выгодна, а также соответствующие модели монетизации, прямой и косвенной.
+Как мы неоднократно упоминали в предыдущих разделах, предоставление некоторой функциональности посредством программируемых интерфесов — достаточно дорогое удовольствие. Для создания и поддержания API требуется соответствующий отдел разработки, и публикация API представляет собой принятие определённых обязательств по поддержке, от которых нельзя так просто отказаться. Возникает логичный вопрос, зачем и почему вообще предоставлять функциональность именно в виде API, т.е. продукта для программистов, вместо того, чтобы ограничиться продуктом для конечного потребителя. Рассмотрим здесь различные ситуации, когда публикация API может быть выгодна, а также соответствующие модели монетизации, прямой и косвенной. [В квадратных скобках будем приводить примеры подобных моделей применительно к нашему учебному примеру с API кофе-машин.]
 
 ##### Разработчик = конечный пользователь
 
-Самая простая и понятная ситуация — в том случае, если разработчики и есть конечные пользователи. В первую очередь здесь речь идёт о всевозможных инструментах для программиста: API языков программирования, фреймворков, операционных систем, библиотек компонентов, игровых движков и так далее, — иными словами, интерфейсы общего назначения. В этом случае ответ на вопрос «зачем предоставлять программный интерфейс» самоочевиден.
+Самая простая и понятная ситуация — в том случае, если разработчики и есть конечные пользователи. В первую очередь здесь речь идёт о всевозможных инструментах для программиста: API языков программирования, фреймворков, операционных систем, библиотек компонентов, игровых движков и так далее, — иными словами, интерфейсы общего назначения. [В нашем кофейном примере это означает следующее: мы разработали библиотеку для заказа кофе, возможно, с визуальными компонентами, и теперь продаём всем желающим-владельцам сети кофе-машин, чтобы облегчить им разработку собственного приложения.] В этом случае ответ на вопрос «зачем предоставлять программный интерфейс» самоочевиден.
 
 Видов монетизации такого API существует множество — по сути, речь идёт о моделях монетизации ПО для разработчиков как таковом.
 
@@ -14,7 +14,7 @@
 
 3. API может быть бесплатен, но компания-разработчик API может оказывать платные услуги по его консультированию и внедрению или просто продавать расширенную техническую поддержку;
 
-4. Разработка API может спонсироваться явно или неявно владельцем платформы (операционной системы), который заинтересован в том, чтобы разработчики имели как можно больше удобных инструментов для работы с платформой;
+4. Разработка API может спонсироваться явно или неявно владельцем платформы (операционной системы), который заинтересован в том, чтобы разработчики имели как можно больше удобных инструментов для работы с платформой [в нашем кофейном примере — производителем «умных» кофе-машин];
 
 5. Наконец, компания-разработчик API путём публикации его под открытой лицензией тем самым привлекает к себе внимание и надеется на повышение продаж других своих продуктов для разработчиков.
 
@@ -22,17 +22,17 @@
 
 ##### API = основной и/или единственный способ доступа к сервису
 
-Этот случай примыкает к предыдущему в том смысле, что потребителем API является разработчик, а не конечный пользователь — с той разницей, что продуктом является не сам API, а сервис, доступ к которому он предоставляет. Чистый пример — это API различных облачных платформ, например, Amazon AWS или Uber Freight API. Да, какая-то работа с платформой возможна и через UI, но без API такие сервисы практически бесполезны.
+Этот случай примыкает к предыдущему в том смысле, что потребителем API является разработчик, а не конечный пользователь — с той разницей, что продуктом является не сам API, а сервис, доступ к которому он предоставляет. Чистый пример — это API различных облачных платформ, например, Amazon AWS или Uber Freight API. Да, какая-то работа с платформой возможна и через UI, но без API такие сервисы практически бесполезны. [В нашем кофейном примере — если мы являемся оператором сети кофе-машин, и предоставляем к ним доступ через API.]
 
 Отдельной монетизации в таких случаях, за исключением совсем экзотических, API не имеет, поскольку оплачивается здесь использование самого сервиса. Часто, однако, тарифы исчисляются именно по сущностям API, т.е. тарифицируется количество вызовов методов.
 
 ##### API = партнёрская программа
 
-Многие коммерческие платформы предоставляют доступ к своей платформе для сторонних разработчиков с целью увеличения продаж или привлечения аудитории на основном сервисе. Примером такого API могут служить, например, партнёрские программы Google Books, Skyscanner Travel APIs или Uber API. В этом случае партнёрство является полностью и исключительно коммерческим: потребители API монетизируют свою собственную аудиторию, а компания — провайдер API таким образом надеется получить доступ к расширенной аудитории, не вкладывая дополнительно в рекламу. Монетизация такого API обычно осуществляется путём фиксации определённых целевых показателей, например, количества кликов по рекламе в отношении к количеству показов.
+Многие коммерческие платформы предоставляют доступ к своей платформе для сторонних разработчиков с целью увеличения продаж или привлечения аудитории на основном сервисе. Примером такого API могут служить, например, партнёрские программы Google Books, Skyscanner Travel APIs или Uber API. [Нашему учебному примеру здесь соответствует вот такая модель: мы — крупная известная сеть кофеен, и мы мотивируем сторонних разработчиков продавать наш кофе через свои сайты и приложения; фактически, позволяем разместить более интерактивную и глубоко интегрированную рекламу нашего сервиса — то, что сегодня принято называть «нативной рекламой».] В этом случае партнёрство является полностью и исключительно коммерческим: потребители API монетизируют свою собственную аудиторию, а компания — провайдер API таким образом надеется получить доступ к расширенной аудитории, дополнительным рекламным каналам. Монетизация такого API обычно осуществляется путём фиксации определённых целевых показателей, например, количества кликов по рекламе в отношении к количеству показов.
 
 ##### API = дополнительный доступ к сервису
 
-Если некоторая компания располагает некоторой уникальной экспертизой, чаще всего — набором данных, который трудно и/или очень дорого получить самостоятельно, вполне логично возникает спрос и предложение на предоставление этой экспертизы через API. Самый классический пример API такого рода — это картографические API; собрать подробные и точные геоданные и поддерживать их в актуальном виде — очень дорого; при этом чуть ли не все сервисы, которые только можно себе придумать, станут существенно лучше и удобнее, если добавить карту.
+Если некоторая компания располагает некоторой уникальной экспертизой, чаще всего — набором данных, который трудно и/или очень дорого получить самостоятельно, вполне логично возникает спрос и предложение на предоставление этой экспертизы через API. Самый классический пример API такого рода — это картографические API; собрать подробные и точные геоданные и поддерживать их в актуальном виде — очень дорого; при этом чуть ли не все сервисы, которые только можно себе придумать, станут существенно лучше и удобнее, если добавить карту. [На наш кофейный пример такой подход ложится с трудом, поскольку аккумулируемые нами в этом случае данные — расположения кофе-машин и типы приготавливаемых ими напитков — не являются чем-то, имеющим самостоятельную ценность вне контекста заказа кофе.]
 
 Этот кейс — пожалуй что самый интересный с точки зрения разработчика API, поскольку существование программного интерфейса в этом случае действительно является мультипликатором возможностей: компания-владелец экспертизы чисто физически не может сама реализовать все на свете сервисы, эту экспертизу использующие. Предоставление API здесь является «win-win» стратегией: функциональность сторонних сервисов улучшается, а компания-провайдер зарабатывает на этом деньги.
 
@@ -42,25 +42,25 @@
 
 ##### API как площадка для рекламы
 
-В основном речь здесь идёт о разного рода виджетах и поисковиках: чтобы размещать какую-то рекламу, необходимо иметь прямой доступ к конечному пользователю. Наиболее распространённые API такого типа — это собственно API рекламных сетей, однако встречаются и комбинированные подходы, когда вместе с некоторым API, например, поисковым, «в нагрузку» идёт показ рекламы.
+В основном речь здесь идёт о разного рода виджетах и поисковиках: чтобы размещать какую-то рекламу, необходимо иметь прямой доступ к конечному пользователю. Наиболее распространённые API такого типа — это собственно API рекламных сетей, однако встречаются и комбинированные подходы, когда вместе с некоторым API, например, поисковым, «в нагрузку» идёт показ рекламы. [В нашем кофейном примере — если наша функция поиска предложений напитков начнёт каким-то образом выделять на странице результатов оплаченные показы.]
 
 ##### API как самореклама
 
-Если никакой — ни прямой, ни косвенной — монетизации API не имеет, он всё ещё может приносить доход, развивая знание о компании через брендирование — отображение логотипов и других узнаваемых элементов при работе пользователя с API, нативное (если визуальные интерфейсы отрисовываются непосредственно самим API) или договорное — потребители API обязаны по контракту размещать определённые элементы брендирования там, где используется фунциональность API или предоставленные через него данные. Целью компании-разработчика API в этом случае является или привлечение аудитории на свои основные сервисы, либо продвижение своего бренда в целом.
+Если никакой — ни прямой, ни косвенной — монетизации API не имеет, он всё ещё может приносить доход, развивая знание о компании через брендирование — отображение логотипов и других узнаваемых элементов при работе пользователя с API, нативное (если визуальные интерфейсы отрисовываются непосредственно самим API) или договорное — потребители API обязаны по контракту размещать определённые элементы брендирования там, где используется фунциональность API или предоставленные через него данные. Целью компании-разработчика API в этом случае является или привлечение аудитории на свои основные сервисы, либо продвижение своего бренда в целом. [В случае нашего кофейного API — представим, что мы предоставляем некоторый совершенно иной полезный сервис, допустим, продаём автомобильные шины, а через предоставление API кофе-машин пытается увеличить узнаваемость и заработать себе репутацию технологической компании.]
 
 ##### Сбор обратной связи и UGC
 
-Если через API предоставляется доступ к большим данным, то оправданной может быть стратегия выпуска публичного API для того, чтобы конечные пользователи вносили исправления в данные или иным образом вовлекались в их разметку. Например, провайдеры картографических API часто разрешают сообщить об ошибке или исправить неточность прямо в стороннем приложении.
+Если через API предоставляется доступ к большим данным, то оправданной может быть стратегия выпуска публичного API для того, чтобы конечные пользователи вносили исправления в данные или иным образом вовлекались в их разметку. Например, провайдеры картографических API часто разрешают сообщить об ошибке или исправить неточность прямо в стороннем приложении. [А в случае нашего кофейного API мы могли бы собирать обратную связь, как пассивно — стоить рейтинги заведений, например, — так и активно — контактировать с владельцами заведений чтобы помочь им исправить недостатки; находить через UGC ещё не подключенные к API кофейни и проактивно работать с ними.]
 
 ##### Найм и формирование комьюнити
 
 ##### Терраформирование
 
-Наконец, наиболее альтруистический подход к разработке API — предоставление его либо полностью бесплатно либо в формате открытого кода и открытых данных просто с целью изменения ландшафта: если сегодня за API никто не готов платить, то можно вложиться в популяризацию и продвижение функциональности, рассчитывая найти коммерческие ниши (в любом из перечисленных форматов) в будущем или повысить значимость и полезность API в глазах конечных пользователей (а значит и готовность потребителей платить за использование API).
+Наконец, наиболее альтруистический подход к разработке API — предоставление его либо полностью бесплатно либо в формате открытого кода и открытых данных просто с целью изменения ландшафта: если сегодня за API никто не готов платить, то можно вложиться в популяризацию и продвижение функциональности, рассчитывая найти коммерческие ниши (в любом из перечисленных форматов) в будущем или повысить значимость и полезность API в глазах конечных пользователей (а значит и готовность потребителей платить за использование API). [В случае нашего кофейного примера — если компания-производитель умных кофе-машин предоставляет API полностью бесплатно в расчёте на то, что со временем наличие у кофе-машин API станет нормой, и появится возможность разработать новые монетизируемые сервисы за счёт этого.]
 
 ##### Серая зона
 
-Отдельный источник дохода для разработчика API — это анализ запросов, которые делают конечные пользователи или, иными словами, сбор и дальнейшая продажа какой-то информации. Следует иметь в виду, что граница между допустимыми способами обработки информации (например, агрегирование поисковых запросов с целью выделения трендов) и недопустимыми здесь весьма неочевидна и имеет тенденцию меняться как во времени, так и в пространстве (в смысле, одни и те же действия могут быть легальны по одну сторону государственной границы и нелегальны по другую), так что принимать решения о монетизации API подобными способами следует с очень большой осторожностью.
+Отдельный источник дохода для разработчика API — это анализ запросов, которые делают конечные пользователи или, иными словами, сбор и дальнейшая продажа какой-то информации. Следует иметь в виду, что граница между допустимыми способами обработки информации (например, агрегирование поисковых запросов с целью выделения трендов или точек совершение заказов с целью геолокации) и недопустимыми здесь весьма неочевидна и имеет тенденцию меняться как во времени, так и в пространстве (в смысле, одни и те же действия могут быть легальны по одну сторону государственной границы и нелегальны по другую), так что принимать решения о монетизации API подобными способами следует с очень большой осторожностью.
 
 ### Подход API-first
 
@@ -72,4 +72,4 @@
 
 3. Необходимо реально обладать пресловутой экспертизой в разработке API, иначе велик шанс наделать неисправимых ошибок.
 
-Иногда раздача API является своеобразным «прощупыванием почвы» для того, чтобы компания-разработчик могла оценить рынок и решить, стоит ли выводить на него полноценный пользователский сервис (мы такую практику скорее осуждаем, поскольку она неизбежно приведёт к закрытию API в будущем: либо потому, что рынок оказался не столь привлекателен, как казалось априори; либо потому, что API начнёт создавать конкуренцию материнскому сервису).
+Иногда раздача API является своеобразным «прощупыванием почвы» для того, чтобы компания-разработчик могла оценить рынок и решить, стоит ли выводить на него полноценный пользователский сервис (мы такую практику скорее осуждаем, поскольку она неизбежно приведёт к закрытию API в будущем: либо потому, что рынок оказался не столь привлекателен, как казалось априори; либо потому, что API начнёт создавать конкуренцию материнскому сервису и будет со временем закрыт или существенно ограничен).

src/ru/drafts/04-Раздел III. API как продукт/Пирамиды.md

@@ -1,14 +0,0 @@
-### Прямая и обратная API-пирамида Маслоу
-
-Прежде чем начинать говорить о продукте API, необходимо прояснить важный вопрос: почему вообще возникает необходимость какого-то отдельного подхода к продукту API? Чем он отличается от технологических продуктов вообще? Вопрос этот не праздный, поскольку, по опыту автора настоящей книги, именно попытка относиться к API как к самому обычному программному обеспечению или веб-сервису и есть одновременно самая большая проблема развития продукта.
-
-Ключевое свойство API, о котором мы упоминали ещё в [главе 2](#chapter-2), — это то, что вы не продаёте его конечному пользователю; конечный пользователь взаимодействует с каким-то решением, которое поверх вашего API написали разработчики, работающие на какой-то сторонний бизнес (причём иногда в цепочке между вами и конечным пользователем находится ещё и более одного разработчика). Консистентность, читабельность, продуманная архитектура и вообще качество дизайна API — обо всём этом знает только разработчик. Бизнес-заказчик, а тем более конечный пользователь всех этих красот оценить не может.
-
-При этом разработчики как аудитория продукта — весьма своеобразная категория потребителей. С одной стороны, разработчики, как правило, образованные и активные люди. У них гораздо выше требования к качеству продукта и гораздо шире знания предметной области, чем у конечного пользователя. Замаскировать недостатки продукта агрессивным маркетингом не получится: в тот момент, когда разработчик сядет разбираться с вашим API, все его качества, все достоинства и недостатки по сравнению с конкурентами окажутся как на ладони. При этом разработчики чаще всего имеют прямое, если не решающее влияние на руководство бизнеса в вопросе выбора технологий — следовательно, именно они принимают решение, какой API выбрать.
-
-С этой точки зрения целевая аудитория API — это некоторая пирамида, подобная пирамиде Маслоу:
-  * вершиной пирамиды являются разработчики: именно они непосредственно работают с API, и они выбирают, какой из конкурирующих API им подходит;
-  * средний ярус пирамиды — бизнес-заказчики; они строят продукт, опираясь на разработчиков;
-  * наконец, основание пирамиды — пользователи; им важно решение их задач, и их обычно совершенно не интересует, каким образом оно достигается.
-
-Непосредственный вывод из этой модели звучит так: в достоинствах вашего API в первую очередь необходимо убедить разработчиков; они, в свою очередь, примут решение о выборе технологии, ну а бизнес оттранслирует концепцию пользователям. Если руководителями продукта API являются бывшие или действующие разработчики, они зачастую склонны оценивать конкуренцию на рынке API именно в этом аспекте, и направлять основные усилия по продвижению продукта именно на аудиторию программистов.

src/ru/drafts/04-Раздел III. API как продукт/Пользователи API.md

@@ -0,0 +1,12 @@
+Специфика пользователей API заключается в том, что:
+
+  * разработчики — высокообразованные люди с практически-прикладным рациональным мышлением; как правило, выбор продукта ими осуществляется предельно рационально (это не исключает определённой вкусовщины в части выбора, скажем, языков программирования или вендоров программного обеспечения; однако *повлиять* на эти вкусы практически невозможно);
+
+      * в частности, разработчики скептически относятся к громким рекламны заявлениям и готовы разбираться в качестве продукта;
+
+  * к разработчикам крайне сложно обращаться через стандартные маркетинговые каналы; помимо того, что они получают информацию в основном из ускоспециализированных сообществ, программисты также смотрят в первую очередь на мнения, подтверждённые конкретными цифрами и примерами (желательно — примерами кода);
+
+      * мнения «инфлюенсеров» в такой среде значат очень мало, поскольку ничьё мнение не принимается на веру;
+  
+  * идеи Open Source и бесплатного ПО распространены среди разработчиков достаточно широко; попытки в том или ином виде зарабатывать на том, что код вашего проекта остаётся закрытым (например, путём лицензирования интеллектаульной собственности на интерфейсы), будут встречать сопротивление.
+

src/ru/drafts/04-Раздел III. API как продукт/Продукт API.md

@@ -1,17 +1,27 @@
 ### Продукт API
 
-Когда мы говорим об API с точки зрения бизнеса, необходимо чётко зафиксировать два важных тезиса.
+Когда мы говорим об API как о продукте, необходимо чётко зафиксировать два важных тезиса.
 
-  1. API — это *продукт*. Вы «продаёте» его точно так же, как и другое ПО, и к нему полностью применимы принципы маркетинга. Весьма сомнительно, что вы сможете качественно продвигать API, не изучив потребности аудитории, спрос и предложение, рынок, конкурентов, потребителей — короче говоря, не проведя всестороннее маркетинговое исследование.
+  1. API — это *такой же продукт*, как и другое ПО. Вы «продаёте» его точно так же, и к нему полностью применимы принципы маркетинга. Весьма сомнительно, что вы сможете качественно продвигать API, не изучив потребности аудитории, спрос и предложение, рынок, конкурентов, потребителей — короче говоря, не проведя всестороннее маркетинговое исследование.
 
-  2. API — это *продукт для очень специфичной аудитории*. Вашими пользователями являются программисты, а это очень-очень специфическая категория потребителей. Помимо прочего это означает, что проводить эти самые маркетинговые исследования — крайне непросто; для изучения рынка требуется весьма специфическая экспертиза в области маркетинга API.
+  2. API — это *очень специфический продукт*. Вы продаёте возможность некоторые действия выполнять автомизированно посредством написания кода, и этот факт накладывает большие ограничения на управление продуктом.
 
-Специфика аудитории API заключается в том, что:
+Для того, чтобы успешно распространять API, необходимо уметь отвечать именно на этот вопрос: почему ваши потребители предпочтут выполнять те или иные действия программно. Вопрос этот не праздный, поскольку, по опыту автора настоящей книги, именно отсутствие у руководителей продукта и маркетологов экспертизы в области работы с API и есть самая большая проблема развития продукта API. Конечный пользователь взаимодействует с каким-то решением, которое поверх вашего API написали разработчики, работающие на какой-то сторонний бизнес (причём иногда в цепочке между вами и конечным пользователем находится ещё и более одного разработчика).
 
-  * разработчики — высокообразованные люди с практически-прикладным рациональным мышлением; как правило, выбор продукта ими осуществляется предельно рационально (это не исключает определённой вкусовщины в части выбора, скажем, языков программирования или вендоров программного обеспечения; однако *повлиять* на эти вкусы практически невозможно);
+С этой точки зрения целевая аудитория API — это некоторая пирамида, подобная пирамиде Маслоу:
+  * вершиной пирамиды являются разработчики: именно они непосредственно работают с API, и они выбирают, какой из конкурирующих API им подходит;
+  * средний ярус пирамиды — бизнес-заказчики; они строят продукт, опираясь на разработчиков;
+  * наконец, основание пирамиды — пользователи; им важно решение их задач, и их обычно совершенно не интересует, каким образом оно достигается.
 
-      * в частности, разработчики крайне требовательны к качеству продукта и готовы разбираться в смысле ваших маркетинговых заявлений;
+Непосредственный вывод из этой модели звучит так: в достоинствах вашего API в первую очередь необходимо убедить разработчиков; они, в свою очередь, примут решение о выборе технологии, ну а бизнес оттранслирует концепцию пользователям. Если руководителями продукта API являются бывшие или действующие разработчики, они зачастую склонны оценивать конкуренцию на рынке API именно в этом аспекте, и направлять основные усилия по продвижению продукта именно на аудиторию программистов.
 
-  * к разработчикам крайне сложно обращаться через стандартные маркетинговые каналы; помимо того, что они получают информацию в основном из ускоспециализированных сообществ, программисты также смотрят в первую очередь на мнения и отзывы других программистов;
+«Постойте!» — воскликнет здесь внимательный читатель. Но ведь дела здесь обстоят с точностью до наборот:
+  * разработчики, как правило, являются наёмными сотрудниками, выполняющими поставленные заказчиком задачи (и даже если мы говорим о каком-то разработчике-одиночке, он всё же выбирает API в интересах какого-либо проекта, т.е. выступает здесь как бизнес-заказчик для самого себя);
+  * бизнес, в свою очередь, ставит задачи разработчикам не из чувства стиля и не из соображений красоты кода — заказчика интересует реализация конкретной функциональности, необходимой для решения задач пользователя;
+  * наконец, пользователю совершенно не интересны проблемы и разработчиков, и бизнеса: он выбирает тот продукт, который ему нужен.
 
-      * мнения «инфлюенсеров» в такой среде значат очень мало
+Получается, что пирамида, таким образом, должна строиться снизу вверх: это конечного пользователя нам нужно убедить, что он хочет не какую попало кружку кофе, а именно приготовленную через наш API (и отдельный вопрос, как же мы будем доносить информацию о том, что за API работает под капотом, и почему пользователь должен своими деньгами проголосовать именно за наш API!); тогда бизнес поставит разработчику задачу интегрировать наш API, ну а разработчик уже никуда не денется и напишет код (что, кстати, означает, что вкладываться в читабельность и консистентность API не так уж и обязательно).
+
+Истина, разумеется, лежит где-то посередине. В каких-то предметных областях и на каких-то рынках все решения принимаются разработчиками (например, какой фреймворк выбрать); в других областях и рынках конечно слово остаётся за бизнес-заказчиком и конечным пользователем. К тому же, многое зависит от конкурентной ситуации; новому игроку войти на рынок, например, мобильных операционных систем очень дорого и малоперспективно.
+
+Здесь и далее мы будем описывать некоторый «усреднённый» случай, в котором все три яруса пирамиды важны: и пользователи (которые выбирают качественный продукт), и бизнес (которому важны гарантии качества и стоимость разработки), и разработчики (которых интересует удобство работы с API и его функциональность).