Концепция программ с открытым исходным кодом (open-source software) представляет собой удобный способ сотрудничества при создании ПО, и сервис для совместной разработки GitHub делает такое сотрудничество возможным. Созданный в 2008, этот веб-сервис для хостинга IT-проектов, основанный на системе контроля версий Git и ориентированный на идеал объединения программистов всего мира, в настоящее время может похвастаться 26 миллионами пользователей, прибылью в $110 000 000 и оценкой стоимости в $2 000 000 000.
В этом посте мы расскажем, как GitHub использует модель ценообразования, базирующуюся на характерных особенностях своих пользователей.
Содержание статьи
GitHub учитывает уровень своей аудитории
Дифференциация функций как ключ к лучшей стратегии ценообразования
Поиск возможностей для улучшения на растущем рынке
GitHub учитывает уровень своей аудитории
Многие из тех, кто работает в B2B-среде и маркетинге, подкованы в плане технологий и автоматически считают, что их покупатель так же продвинут, а потому поймет все их идеи. Но продемонстрировав цены своим квалифицированным лидам и проведя последующее качественное тестирование, они вдруг обнаруживают, что — о, боже! — все ужасно запутанно, и люди совершенно не «въезжают» в представленные ценовые схемы. Тогда приходит осознание необходимости разработать совершенно новую систему ценообразования, позволяющую двигаться вперед с конкретно этими покупателями.
Мы достаточно часто говорим о необходимости понимания целевого клиента и того, как он взаимодействует с вашими ценами. И не секрет, что если технологически более искушенный покупатель точно знает, что он хочет получить от сервиса, то неподкованному клиенту, скорее всего, потребуются дополнительная поддержка. Именно способность покупателя справляться с определенным уровнем сложности должна диктовать то, как будет выглядеть ваша тарифная схема на на прайс-странице.
Раньше сервис GitHub в основном ориентировался на индивидуальных предпринимателей и независимых разработчиков. Теперь свой код на ресурсе имеют Airbnb, Spotify и даже SAP. Чтобы не отставать от требований рынка, GitHub пришлось скорректировать свои цены. Они отказались от модели, при которой ценностным показателем (Value Metric) выступали частные репозитории, и пришли к политике ценообразования, исходящей из количества пользователей.
По мере роста организаций растет их потребность в количестве репозиториев и разработчиков. Когда команда достигает 16 или более разработчиков, предпочтения в тарифах резко меняются, и исходить из цены за каждый репозиторий становится неактуально.
Относительные предпочтения по показателям ценности разных моделей ценообразования в зависимости от размера команды (на основе данных о 3 311 настоящих, бывших и потенциальных клиентах GitHub). Вертикальная ось — ценообразование в зависимости от (снизу вверх): количества пользователей (Per User), количества репозиториев (Per Repository), функционала (Features and Functionality). Цветовые графики — размер команды: фиолетовый — индивидуальные разработчики, синий — команда из 2-5 разработчиков, голубой — команда из 6-15 разработчиков, розовый — команда из 16-25 разработчиков, желтый — команда из 26+ разработчиков
Отдельные разработчики и команды до пяти человек имеют аналогичные предпочтения: количество нужных им репозиториев очень легко предсказать, и, вероятно, их будет не так много. Для команд в 6-15 разработчиков тенденция начинает меняться в сторону ценообразования на основе количества пользователей, а также предоставляемых функций. Несмотря на то что подобные предпочтения еще не столь ярко выражены, как у более крупных команд, очевидно, что по мере роста осуществляется переход от оплаты за число репозиториев к оплате за каждого пользователя или за функционал.
При переходе к модели ценообразования, основанной на количестве пользователей, GitHub ориентируется на потребность крупных организаций планировать свои относительные расходы. Намного проще определить количество потенциальных разработчиков, необходимых для выполнения определенных проектов, чем число требуемых для размещения и управления кодом репозиториев.
Предпочтения по числу репозиториев (на основе данных о 3 311 настоящих, бывших и потенциальных клиентах GitHub). Вертикальная ось — количество репозиториев. Цветовые графики — размер команды: фиолетовый — индивидуальные разработчики, синий — команда из 2-5 разработчиков, голубой — команда из 6-15 разработчиков, розовый — команда из 16-25 разработчиков, желтый — команда из 26+ разработчиков
Мы видим иное соотношение, когда рассматриваем предпочтения по оплате на основе числа репозиториев. Как правило, с увеличением размера команды требуется больше репозиториев. Но в случае с опрошенными 3 311 существующими, бывшими и потенциальными клиентами GitHub мы видим другую картину. Эти клиенты способны точно прогнозировать, сколько репозиториев понадобится по мере роста команды.
Команде от 1 до 5 разработчиков не нужно много репозиториев, а для групп из 16 или больше человек характерно желание иметь как можно большее количество репозиториев. Но, если команда растет в диапазоне от 5 до 15 человек, потребность в дополнительных репозиториях отсутствует, и клиенты GitHub это понимают.
Так потребители сами поддерживают решение компании о переходе от модели ценообразования на основе репозиториев к модели, отталкивающейся от числа пользователей. Потенциальные покупатели GitHub весьма технологически развиты и отлично осознают потребности своей команды.
Дифференциация функций как ключ к лучшей стратегии ценообразования
Когда мы сравниваем готовность клиентов GitHub платить (Willingness To Pay, WTP) за одного пользователя с тем, что компания предлагает на своей странице с ценами (Pricing Page), мы видим, что ценовая политика была выбрана вполне удачно.
Готовность платить за число пользователей в зависимости от размера команды разработчиков (на основе данных о 3 311 настоящих, бывших и будущих клиентах GitHub). Вертикальная ось — цена. Горизонтальная ось — размер команды (слева направо): один разработчик, 2-5 разработчиков, 6-15 разработчиков, 16-25 разработчиков, 26+ разработчиков
На уровне разработчиков-индивидуалов готовность платить составляет $9,43, что немного выше, чем стоимость пакета «Разработчик» (Developer) за $7 долларов. По мере увеличения численности команды, готовность платить тоже растет. Для 2-5 разработчиков она достигает $10,38 и тянется вверх почти до $15. Наибольшая готовность платить приходится на команды в 6-15 разработчиков, для которых она составляет $17,43 — рост более чем на 60%.
По мере расширения групп до 25 и более пользователей покупателям становятся нужны дополнительные функции, и с этого момента они предпочитают платить за них не для всей команды скопом, а по отдельности за каждого пользователя, который будет прибегать к этим опциям.
Рассматривая зависимость между предпочтениями по функционалу и общей готовностью платить за каждого пользователя, можно заметить, что GitHub предлагает очень широкий диапазон функций. Различия между ощущаемой ценностью (Perceived Value) разных функций и дополнительных настроек говорят о потенциально различных видах пользователей GitHub.
Особенно интересно обратить внимание на общие настройки, связанные с разработкой, такие как разрешение на работу команд и отдельных пользователей, а также неограниченные частные репозитории. Эти функции становятся более важными по мере развития компании, и доказательством этого является готовность платить.
Матрица ценности для пользователей GitHub (на основе данных о 3 311 настоящих, бывших и будущих клиентах GitHub). Верхний левый сектор касается дополнительных предложений (Add-Ons): они обладают низкой ценностью, и продать их можно только потребителям с высокой готовностью платить. Это такие услуги, как 24-часовая поддержка, технология единого входа на базе SAML, продвинутый аудит, мультифакторная аутентификация. В верхнем правом секторе находятся дифференцируемые функции высокой ценности, и пользователи здесь характеризуются высокой готовностью платить. Сюда входят разрешение на использование индивидуальными пользователями и командами, неограниченное число частных репозиториев и возможность сразу нескольким организациям пользоваться сервисом. В нижнем правом секторе располагаются основные функции высокой ценности (неограниченное число публичных репозиториев). Клиенты здесь обладают низкой готовностью платить. Нижний левый сектор — это пустошь, где нечего ловить: невысокая ценность оффера и низкая готовность платить (возможность помещения IP-адресов в белый список)
Много возможностей для GitHub открывается в разделе дополнительных предложений (Add-Ons) этой матрицы ценностей. Хотя функция, вроде поддержки 24/7, может понравиться некоторым пользователям, большинство эта функция не интересует. Таким образом, было бы разумнее предложить ее в качестве услуги, дополняющей основной оффер (то есть как upsell), а не как основную функцию на странице с ценами.
Предпочтения по функционалу меняются со временем, и многофакторная аутентификация, например, приближается к тому, чтобы стать дифференцируемой функцией в будущем. GitHub может многому научиться у таких сервисов, как Dropbox и Box, посмотрев, как варьируются их ценовые предложения. Многие конкуренты GitHub начинают фокусироваться именно на подобных функциях.
Поиск возможностей для улучшения на растущем рынке
На ценовой странице GitHub нет достаточной дифференциации функций.
Рынок, на котором работает компания, сверхконкурентен. Продвигаясь вперед, GitHub потенциально может потерять доход от расширения своего бизнеса. Но сосредоточив внимание на дополнительных опциях и расширении прибыли от своей нынешней клиентской базы, они могут улучшить общий опыт, связанный с ценовой политикой.
Существующая стратегия ценообразования — хорошая стартовая точка для развития. Улучшив дифференциацию функций в разных ценовых пакетах и направив усилия на определение того, что должно стать основой функционала, а какие части могут перейти в add-ons, GitHub может превратить свою уже довольно добротную ценовую модель в нечто еще более значительное. Если вы решили, что ваш прайс тоже нуждается в оптимизации, а стратегия — в пересмотре, то проверить свои гипотезы и выбрать наиболее выгодную комбинацию тарифов, повысить конверсию и прибыль можно с помощью нашей платформы.
Высоких вам конверсий!
По материалам: priceintelligently.com
