Как мы создали способ для аккаунтов с устаревшими планами подписки на последние и лучшие

На протяжении большей части существования Hootsuite единственным платным базовым планом был Pro. Затем пакетные планы были выпущены в качестве замены, но участники Pro сохранили свою существующую подписку. Тарифные планы предлагают более полнофункциональный и удобный пользовательский интерфейс. В обновленных версиях надстроек не возникает путаницы с устаревшими концепциями, такими как многоуровневое ценообразование на основе количества. Недавние дополнения к платформе, такие как Hootsuite Inbox, доступны только в рамках тарифных планов. У участника есть множество стимулов к обновлению с Legacy Pro, но единственной задачей, которой мы пренебрегли, было создание в продукте способа выполнения этой операции.

Наша биллинговая инфраструктура также претерпела множество изменений со времен Legacy Pro. Из-за монолитного происхождения Hootsuite учетные записи и их платежные данные изначально хранились в различных базах данных Dashboard. Теперь у нас есть отдельная служба биллинга для хранения планов и подписок и служба прав для предоставления учетных записей с функциями. Еще в 2017 году мы начали перенос устаревших учетных записей из базы данных Dashboard в Billing Service, что было предварительным условием для нашего последнего запуска: чтобы полностью разблокировать процесс модернизации, мы улучшили интерфейс изменения плана и расширили правила биллинга на сервере.

Переназначение существующих страниц изменения плана

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

Поскольку страница подтверждения была создана только для перехода на более раннюю версию плана, когда можно было бы ожидать некоторой потери функций (например, с Team3S на Professional), нам потребовались новый дизайн и описания, чтобы точно передать переход от устаревшего плана к современному; переход может привести к расширению набора функций пользователя, поэтому исходные тексты могут ввести в заблуждение. Dashboard извлекает продукты, на которые подписан пользователь, из Billing Service, чтобы правильно настроить страницу и определить, какой текст отображать пользователю.

Новые компоненты React должны были быть созданы для работы с излишками учетных записей. Избыточные относятся к функциям, таким как количество социальных сетей, емкость которых в новом плане ниже, чем количество, используемое в настоящее время. Если пользователь Legacy Pro хотел переключиться, но у него были излишки в социальных сетях, он не смог бы сделать это, пока пользователь не выберет достаточно, чтобы отказаться, чтобы не выходить за рамки своего нового плана. Чтобы завершить Pro для пакетов, мы добавили поле управления членами команды, идентичное селектору социальных сетей, и добавили панель поиска из набора инструментов компонентов Hootsuite, чтобы пользователи могли быстро определять сети и участников, если они много добавили в свою учетную запись. .

Использование правил для добавления свойств при внесении изменений в план

Перед загрузкой избыточной страницы из приложения React выполняются вызовы Ajax в другие службы для получения сводки использования функции и, при необходимости, членов организации и списков социальных сетей. Эти данные необходимы для заполнения списков элементами для выбора в полях управления.

Нажатие кнопки «Подтвердить POST» приводит к появлению списка изменений плана, включая желаемый базовый план, устаревшие надстройки, которые необходимо удалить, и запрошенный интервал выставления счетов (годовой или ежемесячный). Служба выставления счетов передает изменения через механизм правил, обновляет записи в базе данных, а затем распространяет их на платежную платформу, так что с пользователя будет взиматься пропорциональная плата / оплата в соответствии с их выбором.

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

Ниже приведено правило пропорционального распределения пользователей, уходящих с Pro:

Rule(
 ConjunctivePredicate(
   ProductPredicate((from = Some(ProductCode.PRO)))
   NegativePredicate(
    ProductPredicate((to = Some(ProductCode.FREE)))
   ),
   NegativePredicate(
    IntervalPredicate((from = Some(Annual)), (to = Some(Monthly)))
   )
 ),
 TautologicalPredicate,
 Set[Policy](AlignmentPolicy(Immediate), ProrationPolicy(Credit))
)

Конъюнктивный предикат объединяет три предиката внутри, поэтому для применения правила должны совпадать все условия. Правило будет соответствовать изменениям с Legacy Pro на платный план с интервалами выставления счетов, отличными от годового до ежемесячного. тавтологический предикат области действия всегда возвращает значение true, что означает, что правило будет применяться ко всем другим изменениям в наборе изменений. Набор политик содержит директивы, применяемые к набору изменений. Например, удаление надстройки Legacy Pro в результате перехода также будет немедленным и приведет к возмещению в виде кредита.

Что делает механизм правил, так это то, что он сворачивает список правил и применяет политики соответствия к набору изменений, если эта категория политик еще не имела соответствия. Таким образом, мы можем расставить приоритеты правил в зависимости от порядка . Набор правил по умолчанию сохраняется на тот случай, если пользовательские правила не совпадают.

rules.foldLeft((Map.empty[PolicyType, Policy], Seq[Rule]())) {
  case (
    (map, remainingRules),
    Rule(predicate, policies, scopePredicate)
  )
  if anyOperationsMatchPredicate(operations, predicate) &&
  scopePredicate == TautologicalPredicate =>
    reducePolicies(policies.toSeq, map) -> remainingRules
  case ((map, remainingRules), rule) =>
    map -> (remainingRules :+ rule)
}

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

Куда мы направились?

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

С этого момента следующие шаги будут заключаться в обновлении различных подсказок и всплывающих подсказок, чтобы проинформировать старых пользователей о переработанной странице планов и стимулировать принятие. В дальнейшем мы хотим улучшить обмен сообщениями после завершения изменений плана и уточнить баннеры, представляющие изменения плана в очереди в учетной записи. Hootsuite стремится обеспечить безопасный и прозрачный UX для всех аспектов биллинга - следите за нашей следующей партией обновлений!

Об авторе
Синди Хсу изучает компьютерные науки на третьем курсе в UBC. Это знаменует ее 12-й месяц совместной работы в Billing.
Поприветствуйте в LinkedIn.