Освоение API Analytics для программ API: воронка разработчика

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

Этап предварительной интеграции

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

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

Это означает, что ваш продукт является freemium, имеет бесплатную пробную версию или другое.

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

Разработчики не могут перейти на этап песочницы по многим причинам, включая:

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

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

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

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

Этап производства

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

Разработчики не могут перейти на стадию производства по многим причинам, включая:

• Приоритеты проекта. Ошибки клиентов или другие особенности проекта могут иметь приоритет. Ваша интеграция с API коммуникаций отошла на второй план только потому, что разработчик получил кучу билетов на Jira.

• Законность и соответствие. Особенно в регулируемых отраслях, таких как финансы и здравоохранение, разработчику, возможно, придется подождать, пока не получат необходимые разрешения от юридического лица.

• Функциональное и эксплуатационное тестирование. Компания может иметь внутренние политики для тестирования сторонних сервисов, которые должны быть завершены в первую очередь.

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

Создание целей воронки

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

Чтобы сделать их интеграцию простой, они могут:

• Привлечение пользователей для индексации нового объекта через POST /1/indexes/конечную точку
• Используйте пример данных для начальной загрузки примера индекса, который может запросить разработчик

Допустим, мы идем с (1), тогда нашей точкой преобразования воронки будут любые разработчики, которые выполнили хотя бы одну POST /v1/indexesоперацию. Алголии может потребоваться более точный показатель конверсии, чтобы они могли отслеживать любого разработчика, который выполнил хотя бы одну POST /v1/indexesоперацию И одну POST /1/indexes/{indexName}/queryоперацию ГДЕ ответ Content-Length> 0 . Это означает, что разработчик успешно проиндексировал хотя бы один объект и смог прочитать его обратно.

• Электронное письмо
• имя
• Название работы
• Ссылающийся сайт

Рекомендуемые переменные для отслеживания в компаниях включают в себя:

• доход компании
• количество работников
• Промышленность
• Alexa Rank
• План МРР

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

Отслеживание компаний (т. Е. Учетных записей) отдельно от пользователей гарантирует, что вы сможете создавать показатели количества разработчиков или групп в организации, использующих ваше решение.

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

Это похоже на веб и мобильное MAU и может дать общий обзор роста и состояния здоровья. Однако вместо отслеживания отдельных пользователей, выполняющих взаимодействия пользовательского интерфейса, например нажатий кнопок в вашем приложении, API MAU отслеживает отдельных пользователей, выполняющих программные взаимодействия с вашим API. В зависимости от вашей отрасли, отдельный пользователь может быть отдельным пользователем или разработчиком, или это могут быть отдельные компании или учетные записи. Продукты API Analytics, такие как Moesif, могут отслеживать, что очень важно для аналитики на уровне аккаунта.

Почему 28 дней?

Несмотря на то, что мы говорим MAU, мы должны измерять активность в фиксированных 28-дневных окнах, а не весь месяц. Используя 28 дней, мы можем игнорировать систематическую ошибку, поскольку количество дней в месяце не является постоянным. Кроме того, 28 дней гарантирует, что каждое временное окно начинается в один и тот же день недели. Это гарантирует, что у нас всегда будет одинаковое количество дней недели и выходных в каждом временном окне. Многие компании, особенно B2B, имеют разные уровни использования в выходные дни по сравнению с рабочими днями. Сохраняя эти цифры согласованными, мы можем устранить эти искажения.