Представьте ситуацию: вам нужно воспользоваться оплаченным (как вы думаете) сервисом — и вдруг оказывается, что он отключен за неуплату. Такая неприятность портит впечатление от бренда, снижая поток прибыли, а внезапно отключенный клиент может не вернуться к сервису. К старту курса о глубоком и машинном обучении делимся переводом о том, как эту проблему решили в Dropbox, где обнаружили, что внедрение ML в обработку клиентских платежей помогает пользователям оставаться довольными и работает лучше внедрённых за 14 лет политик биллинга.

Платежи в Dropbox

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

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

Продление подписки и сбои

Обычно подписчики Dropbox платят за подписку ежемесячно или ежегодно. Если клиент дал нам полномочия снимать оплату, повторный платёж списывается с банковской карты клиента автоматически. Когда оплата проходит успешно, подписка продлевается без каких-либо действий со стороны пользователя.

Однако, если попытка оплаты не удалась, клиент оказывается в потоке, который мы называем сбой обновления. На этот случай у нас есть процедуры восстановления, которые пытаются предотвратить прерывание подписки.

Чтобы определить время платежа от клиента, чья подписка не продлевается, наша платёжная платформа использовала статический набор из примерно 10 различных методов. Так сложилось исторически. Например, мы можем взимать плату с клиента каждые четыре дня, пока платёж не завершится успешно, в течение максимум 28 дней. Если платеж клиента к концу этого срока по-прежнему не выполнен, уровень его учётной записи в Dropbox понижается до бесплатной базовой учётной записи. Конечно, для активных пользователей и команд понижение уровня учётной записи создаёт неприятные впечатления, а для Dropbox недобровольный отток может обернуться упущенной выгодой.

Сбои в оплате могут произойти по ряду причин. Среди них:

• нехватка средств;

• карта с истекшим сроком действия;

• заблокированная карта — возможно, сообщается о потере или краже;

• непредсказуемые сбои обработки.

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

Зачем машинное обучение в работе с платежами?

Последние два года, чтобы выяснить, повлияет ли изменение времени оплаты на её успешность, Dropbox проводил A/B-тестирование. Чтобы разработать набор правил о том, когда взимать плату, эти тесты в значительной мере опирались на интуицию и знания людей в предметной области.

Команда платежей должна была вручную разделить пользователей на группы в зависимости от их признаков — типа подписки, географического местоположения и т. д., а затем выполнить A/B-тест наших десяти или около того различных жёстко закодированных наборов правил, чтобы определить, какие из них лучше всего подходят для этих признаков. Затем команда платежей сохраняла оптимальный вариант политики для этой группы выставления счетов по умолчанию. Периодически команда проводила повторное тестирование, чтобы узнать, изменились ли для разных пользователей лучшие решения.

С другой стороны, этот подход доказал, что момент оплаты влияет на её успех, это позволило Dropbox поддерживать большее количество постоянных подписчиков. Но со временем многие правила перестали работать и достигли потолка эффективности. Кроме того, ручное обновление этих правил — сложный, трудоёмкий процесс.

В стремлении уменьшить непроизвольный отток и необходимый для его поддержания объем работы, команда платежей в партнёрстве с командой прикладного машинного обучения для оптимизации выставления счетов экспериментировала с ML.

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

Применяя машинное обучение, мы со временем выявили множество улучшений, которые не смогла бы просчитать даже команда ведущих экспертов по платежам:

• устранение ручного вмешательства и сложной логики на основе правил;

• например, “Повторяйте каждые X дней” или “Избегайте попыток оплаты в выходные”;

• глобальная оптимизация множества параметров для конкретных сегментов клиентов;

• устойчивость к изменениям клиентов и рынка;

• увеличение общего числа успешных платежей и сокращение времени сбора платежей.

Говоря коротко, применение ML к платежам сделало счастливее и клиентов, и нас.

Как мы сделали это

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

Эксперименты проводились с различными сегментами клиентов, а конкретно — начиная с отдельных клиентов и команд в Северной Америке. Мы построили модель ранжирования с градиентным бустингом, обученную на таких признаках, как типы сбоев платежей, шаблоны использования учётной записи Dropbox и характеристики типа оплаты. Модель ранжирует попытки оплаты по прогнозируемой вероятности успеха для каждого окна оплаты.

Например, мы взяли окно в 8 дней, разделив его на часовые промежутки, так, в общей сложности получилось 192 отрезка времени. Чтобы найти самый протяжённый отрезок времени для попытки обновления, мы использовали наши модели. А также экспериментировали с дневными окнами по 6 и 4 часа.

Сначала эксперименты проводились с оптимизацией каждой попытки независимо. У нас была модель, оптимизирующая решение о том, когда взимать плату с клиента после неудачной первой оплаты. Если рекомендуемая попытка модели также проваливалась, в оставшейся части окна обновления мы по умолчанию возвращались к логике правил. A/B-тесты этой комбинации проводились на отдельных сегментах пользователей в США. Для таргетинга применялся внутренний сервис развёртывания функциональности Stormcrow. Модель стала работать лучше, и мы развернули её.

Нашей целью всегда была сквозная оптимизация неудачных попыток обновления. Процесс начинался с единственной моделью, и этот факт помог подтвердить, что ML применимо к решению задач такого типа. Тем не менее мы быстро поняли, что шаблон проектирования с отдельной моделью для каждой попытки оплаты только создал более сложную систему. Например, если бы мы повторили попытку оплаты 5 раз, прежде чем платёж удался, то так получили бы 5 моделей. И это противоречило цели применения ML — снижению сложности биллинговой системы.

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

Именно эта модель сегодня проходит A/B-тестирование в производстве при помощи Stormcrow со случайным набором команд — участников тестирования Dropbox. Результаты пока положительные.

Predict Service

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

Когда эксперименты только начинались, мы работали с платформой платежей, чтобы загрузить и запустить модели. Из-за добавленных зависимостей архитектура сильно раздулась. Задержки прогноза в среднем составляли около двух минут.

Чтобы упростить процесс, мы воспользовались созданным и управляемым командой платформы ML сервисом Predict Service, этот сервис управляет инфраструктурой для быстрого создания, развёртывания и масштабирования процессов машинного обучения в Dropbox. Применение Predict Service помогло сократить время ожидания при генерации прогнозов модели с нескольких минут до менее 300 мс для 99 % моделей. Переход на Predict Service также обеспечил возможность легкого масштабирования и чистое разделение двух систем.

С помощью этой системы машинного обучения платёжная платформа собирает все относящиеся к клиенту сигналы, запрашивает обслуживаемую через сервис Predict модель, чтобы получить лучшее время выставления счета, таким образом устраняя все наши разработанные и закодированные за 14 лет A/B-тестирования неоптимальные политики биллинга. Рабочий процесс этой системы построен следующим образом:

1. Получение прогноза о следующем лучшем времени списания средств. Когда попытка не удалась, платформа платежей, чтобы получить следующее лучшее время, запрашивает модуль Predict. Запрос выполняется с использованием идентификатора клиента и его типа.

2. Получение сигналов клиентов. Модуль Predict собирает последние сигналы об использовании и о платежах клиентов, а также информацию о предыдущем сбое. Эти данные сохраняются в Edgestore (основной системе хранения метаданных в Dropbox) ежедневным заданием Airflow Job.

3. Запрос прогноза. Собранные сигналы отправляются в Predict Service через вызов GRPC, который кодирует сигналы во фрейм данных о признаках, а затем отправляет их в модель.

4. Генерация прогноза. Модель возвращает ранжированное наилучшее время оплаты. Этот прогноз отправляется обратно в модуль Predict, в свою очередь, результаты — в биллинговую политику.

5. Логирование результатов прогнозов. Модуль Predict, кроме прочего, логирует результаты прогнозирования модели, а также другую необходимую информацию, которая может использоваться для устранения неполадок и анализа.

6. Расписание следующего платежа. Как только сервис платежей получает наилучшее время списания средств, он учитывает это время при планировании следующей попытки оплаты и сохраняет в Edgestore.

ML-операции

При развёртывании наша задача не была выполнена. Мы применили передовые методы DevOps к нашим системам сбора данных и прогнозирования: автоматизировали ежедневные задания по сбору данных и установили мониторинг, чтобы он уведомлял о любых сбоях и задержках этих заданий.

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

Бизнес-метрики

• Коэффициент одобрения счетов. Основная метрика, которую нужно улучшить. При каждом продлении подписки в Dropbox все платежи за продление отслеживаются как часть единого счёта. Эта метрика сообщает нам, было ли обновление подписки успешным.

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

Внутренний мониторинг модели

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

• Охват: процент клиентов, получивших рекомендации от модели, в сравнении с подходом фиксированного интервала в 4 дня.

• Количество сделанных моделью прогнозов: количество рекомендаций, которые модель успешно выполнила без каких-либо ошибок.

• Задержка прогнозирования: сколько времени потребовалось модели для составления каждой рекомендации.

Мониторинг инфраструктуры

Наряду с мониторингом и оповещением для платёжной платформы и сервиса Predict мы также отслеживаем следующее, чтобы определить, насколько хорошо работает инфраструктура:

• свежесть и задержки в конвейерах данных признаков;

• доступность и задержка сервиса Predict;

• доступность EdgeStore.

Для мониторинга нашей модели и метрик инфраструктуры мы используем дашборды Grafana и Vortex. Для бизнес-метрик мы используем Superset. Все эти живые метрики и дашборды помогают нам проактивно отслеживать ожидаемое поведение модели, позволяя принимать соответствующие меры, когда оно отклоняется.

Ответственность за мониторинг этих показателей разделена между командой инженеров по платежам и командой прикладного машинного обучения. У нас есть руководства по устранению неисправностей с чёткими путями эскалации, помогающие дежурным инженерам отладить любые проблемы. Поскольку ML был новым для команды инженеров по платежам, мы потратили время на объяснение принципов работы систем и интерпретацию результатов модели. Это помогло двум командам успешно сотрудничать в работе над проектом и обеспечить бесперебойную работу.

Дальнейшие шаги

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

Наша модель, ориентированная на индивидуальных клиентов, в настоящее время внедрена в производство. Модель оптимизации всего цикла обновления сейчас проходит A/B-тестирование. Компания стремится распространить оптимизацию через ML на всех наших клиентов.

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering