Привет. Сервису mybi connect уже более 6-ти лет и за это время у нас несколько раз обновлялись тарифы и условия оплаты. Мы анализируем поведение и потребление ресурсов пользователей, чтобы предложить оптимальный набор функций и ресурсов, который был бы выгоден обеим сторонам.
В этой статье расскажем про развитие наших тарифов, начнем как всегда с истории и покажем, как мы пришли к текущей версии тарифов.
Оплата сервиса для нас изначально стала камнем преткновения... на протяжении длительного времени (5 лет) мы несколько раз меняли систему тарификации, делая ее более удобной, прозрачной для пользователей. Наиболее долгосрочная версия тарифов работала у нас на протяжении 3-х лет, но события 22-ого года подтолкнули нас к оперативным изменениям, но обо все по порядку…
Небольшая преамбула - к моменту запуска сервиса у нас уже был некоторый (10-летний;) опыт продаж и внедрения аналитических и других проектов, в этот раз правила сильно изменились, мы начали заниматься SaaS, который имеет совсем другие принципы в отличии от услуг внедрения, об этом мы еще в первой статье писали -
В связи с этим мы избрали для себя тактику “захода в организацию снизу” - через сотрудников, а не через отдел закупок. Думаю, у такой стратегии есть более энциклопедичное название, но именно в таком виде мне это запомнилось в выступлении Михаила Токовинина, он говорил, что первые установки amoCRM делали самые продвинутые сейлзы, которые хотели работать со сделками эффективнее, и они же потом шли к своему шефу с предложением развернуть CRM в компании для всех.
Примерно так же и мы хотели сделать доступный для аналитика продукт, который потенциально мог бы и из своего кармана его оплатить, потому что он существенно экономил свое время и решал целый пласт задач в построении аналитической системы. С аналитиками нам было проще и интереснее разговаривать, чем с отделами закупок и топ менеджерами - аналитики могли дать обратную связь, сразу начать использовать продукт, проявить его проблемные места и, конечно, показать кейсы применения. Поэтому мы выбрали весьма доступные цены для сервиса - минимальный тариф по стоимости пары чашек кофе, классическая SaaS модель.
Конечно, пользователи, которые сейчас платят нам несколько десятков тысяч рублей могу улыбнуться, читая это, но в данном случае мы просто перепродаем ресурсы других облачных систем, на которых стоит наш софт, если пользователям требуются большие базы и много данных - платить за них неизбежно придется.
2017
Итак, при запуске сервиса мы создали систему тарификации на основе количества настроенных источников данных, если пользователь в своем проекте настроил один источник, то должен был заплатить нам 399 рублей в месяц за него, если же пять источников то 5 * 399р. Стоимость источника была фиксированной в месяц, но источник оплачивался за время его существования. База данных также оплачивалась отдельно (минимум 999 рублей), по аналогии с источниками - за количество секунд ее существования в течении месяца.
Эта система тарификации была очень сложной, как со стороны ее учета так и со стороны понимания ее пользователем, а еще и сильно дорогой. К примеру, у нас сейчас есть проекты в которых на постоянной основе настроено более 700 источников, и если бы мы брали по 399 рублей за каждый из них, то стоимость использования сервиса составила бы более 279 тыс. рублей. Кроме этого и источники бывают разные, к примеру выгрузка из одного занимает минуту, из другого пару часов... и тарифицировать их одинаково как-то совсем не правильно, но об этом мы узнали уже после запуска первых тарифов;)
2018
Спустя некоторое время использования первоначальной схемы, мы решили ее изменить, так как ее несовершенство было очевидно. Мы начали рассматривать способ тарификации, который использовался в западных аналогах, за количество обработанных строк:
Вот только с этим была одна проблема, все ETL-сервисы использовали пользовательские базы данных, в то время как мы дополнительно к обработке данных предоставляли и БД.
Необходимость предоставления своей БД обусловлена архитектурой mybi connect. Если обычные ETL-сервисы просто "льют" данные в таблицы, как получили их из API, то мы же осознано формируем уникальную структуру под каждый сервис, загружаем в нее данные и поддерживаем их актуальность в таблицах.
Наш подход сложней для разработки новых "коннекторов" и накладывает ограничения на используемые ресурсы, в частности обработчик, который получает и загружает данные, должен находиться в том же датацентре, что и база данных. При загрузке данных в БД формируется большое количество запросов, а когда обработчик и база данных находятся в разных датацентрах, запросы выполняются через интернет, это значительно увеличивает время их выполнения. В результате чего загрузка, которая в "правильном" окружении выполнялась бы 3-4 минуты, требует несколько часов.
Мы не могли отказаться от собственной БД, но переход на "строки" был более чем логичен... в результате появился "гибрид" - новые тарифы кроме оплаты за количество строк включали также и оплату за базу данных, аналогично первой версии. Этот вариант получился значительно лучше - стоимость сервиса для пользователя начала коррелировать с его реальным потреблением ресурсов. Но разделение стоимости за строки и за базы данных вносило некую “смуту”.
2019
Со временем нам удалось оптимизировать расходы на используемые ресурсы в Azure, и мы решили немного доработать тарифы и включить стоимость базы данных в стоимость самого тарифа. Это значительно упростило систему тарификации, но создало ограничение по количеству проектов на тарифе. В результате мы сформировали линейку тарифных планов, которые отличались по количеству включенных строк, которые можно было обработать в течении месяца, и максимальному количеству проектов.
В таком виде тарифы у нас просуществовали более двух лет, и единственной их проблемой была необходимость докупать дополнительные миллионы строк. Каждый тарифный план включает какое-то фиксированное количество строк и, если пользователь расходует больше строк чем включено в тариф, то дополнительные строки покупались автоматически. В результате этого пользователь мог "незаметно" потратить значительно большую сумму в течении месяца, чем он планировал, и даже, если на балансе аккаунта не хватало средств то сумма все равно списывалась и баланс уходил все глубже и глубже в минус. Иногда это приводило к тому, что пользователи просто "бросали" аккаунты, на которых образовался долг, и заводили новые.
Поэтому следующим шагом по доработке тарифов стала возможность управления покупкой дополнительных строк. На данный момент автоматическая покупка строк отключена по умолчанию, и в случае, если все включенные в тарифный план строки были израсходованы, то обработка проектов пользователя останавливается.
2021
Осенью 21-ого года нам удалось довести прошлую систему тарификации до ее логически завершенного вида, но это привело к тому что в ней появился ряд специфических моментов, которые не всегда очевидны на первый взгляд для пользователей. Кроме этого казалось, что можно ее сделать более экономичной, чтобы пользователи могли точнее управлять расходами.
Поэтому мы решили пойти дальше и, собрав вместе наш собственный опыт и наработки по системам тарификации в сторонних сервисах, мы разработали новый тариф, который в ближайшее время будет сочетать в себе все необходимое, но в тоже время будет максимально прост в понимании...
2022
Тарифы мы планировали менять в марте-апреля текущего года, но история вмешалась в наши планы. В этой статье мы рассказали про развитие наших технологий и про появление второго облака Яндекс.
Кроме этого весной все облачные провайдеры стремительно подняли свои цены и смена системы тарификаций стала уже неизбежной для нас.
Из-за дальнейшей неопределенности Azure в РФ мы решили сделать две тарифных сетки: старые тарифы в Azure поднять в 2 раза, а для Яндекса ввести более удобную новую тарификацию.
Вот обновленные тарифы Azure:
Отличительной особенность новой системы тарифов для Яндекс Облака является то, что на ней по сути нет отдельных тарифных планов, а есть только количество строк, которым можно динамично управлять, все остальные параметры усреднены, но таким образом, что их будет достаточно большей части пользователей:
По умолчанию пользователь сервиса получает возможность создать до 4-х проектов с базами данных по 5ГБ. Подобной конфигурации будет более чем достаточно тем, кто планирует использовать mybi connect для внутренних целей компании или работает с небольшим количеством клиентов. Для компаний, которые специализируются на внедрение отчетности своим клиентам, доступна опция расширения, позволяющая увеличить или вообще снять ограничения. Для крупных компаний расширенная опция позволяет получить большую и производительную БД.
На тот момент при включенной опции расширения, у пользователя появилась возможность создавать до 10 проектов с базами данных по 10ГБ, но у нас в планах была реализация более гибкой настройки, о ней позже... Кроме этого на расширенном тарифе появляется возможность управления пользователями, что может быть удобно при наличии в компании большого количества сотрудников, работающих над разными проектами, и еще несколько фичей, которые находятся в разработке.
Стоит отметить что в новой системе тарификации, в отличие от предыдущей, отсутствует возможность докупать дополнительные строки в течении месяца, но в случае если у пользователя заканчиваются строки, то он может перейти на “старший тариф” в любой момент времени. Аналогично это работает и в обратную сторону, если у пользователя осталось много строк, то он может перейти на “младший тариф” и на баланс пользователя вернется разница стоимости тарифов.
Как мы писали ранее, на тот момент mybi connect мог работать с облаками как Microsoft так и Яндекс, но использование новой системы тарификации предусмотрено только для Яндекс.Облако. В первую очередь это было обусловлено неопределенностью в возможности дальнейшего использования Microsoft Azure в контексте все новых и новых санкций. Microsoft не любит уведомлять кого-либо о своих планах, а просто ставит своих пользователей перед свершившимся фактом, но в последнее время наблюдается явное сокращение их активности на территории РФ. В связи с чем мы не могли гарантировать стабильную долгосрочную работу сервиса в облаке Azure и… ход событий показал, что мы были правы в своих прогнозах .
Кстати, в момент внедрения этой линейки мы столкнулись с расхожим мнением, что Яндекс якобы должен быть дешевле чем Microsoft… с чего вы это взяли, я не знаю, но на практике это не так. Да, некоторые ресурсы в облаке Яндекс дешевле, в основном это виртуальные сервера, но опять же не на много. Что же касается баз данных, то все наоборот… в Azure использование SQL Server значительно дешевле, чем использование PostgreSQL или MySQL в Яндекс.Облако, а базы данных составляют львиную долю расходов на использование облака, неважно какого. Поэтому все наши попытки снизить стоимость использования сервиса на новом тарифе основались не на дешевизне ресурсов в другом облаке, а на том что мы пытаемся искать иные схемы расчета стоимости использования сервиса.
2023
Текущая статья была опубликована нами летом 2022 года и сейчас, в начале 2024-го, уже не выглядит актуальной, при этом пользователи все еще изучают ее и адресуют нам вопросы об устаревших условиях, поэтому мы решили дополнить ее еще одним разделом про текущее состояние дел.
Итак, самое заметное обновление, через которое мы прошли вместе с пользователями - отключение баз данных Azure. Летом 2023 года вслед за новостями об ограничении приема платежей Microsoft из РФ мы в скором порядке начали переносить базы данных оставшихся в Azure пользователей на ресурсы Яндекса в одностороннем порядке.
К этому моменту мы научились самостоятельно разворачивать базы с PostgreSQL с корректными сертификатами в облаке Яндекс, которые позволяли работали с MS Power BI (и десктопной, и облачной версии) без использования шлюза. Это было достаточно существенным изменением, которое вернуло пользователям удобство работы с данными - дополнительная настройка в виде локального шлюза, который получал данные из БД и далее передавал из в Power BI, создавало много проблем.
В результате тарифная линейка Azure была полностью устранена, а сам переезд прошел лучше наших ожиданий - большая часть пользователей отнеслась с пониманием к внешним факторам и продолжила использовать сервис с новым расположением баз данных. Об этом мы даже написали статью:
Следующий важный вопрос для решения касался крупных, можно сказать “оптовых” выгрузок. Наши стандартные условия на тот момент ограничивались возможностью использования 10 баз данных и 25 млн. строк, но это устраивало не всех, у нас есть ряд пользователей со значительно большими запросами.
Мы предполагали, что сможем решить этот вопрос аналогично Azure - выгрузкой данных в собственные базы пользователей, развернутые по нашему ТЗ. Но тут мы столкнулись с массой проблем в администрировании: если базы данных находятся не под нашим управлением - мы не можем гарантировать работоспособность и, когда появляются проблемы, для их решения нужно подключать третьих лиц, высвобождать место, искать источники проблем, не связанные с нами. Эти организационные вопросы ведут к простою сервиса и потенциальным проблемам для других его пользователей, поэтому от выгрузки данных в пользовательские базы мы отказались.
Вместо этого мы добавили возможность увеличения количества баз данных на нашем Расширенном тарифе и продлили “ползунок” выбора количества строк до 300 млн.
Еще пара позитивных прошлогодних апдейтов не связаны с тарифами, но напрямую влияют на удобство оплаты для пользователей. Мы продлили срок хранения баз данных неоплаченных проектов до 14 дней на обычном и 21 дня на расширенном тарифе. Ранее неоплаченные проекты удалялись через 7 дней, что многие пользователи считали недружелюбным, но для нас это было необходимо, потому как эти правила распространялись и на триалы тоже, которых у нас создается достаточно много и абсолютное большинство остается неоплаченными.
Кроме этого мы добавили возможность активации тарифа сегодняшним числом, не дожидаясь завершения тарифного месяца. В некоторых случаях это позволяет сэкономить при смене тарифа, здесь можно найти анонс функционала с пояснениями.