Сколько нужно программистов, чтобы продавать духи в интернете?

Правильный ответ — зависит от. От того, как, кому и зачем продавать. Привет, меня зовут Андрей Ребров, я технический директор и сооснователь компании Scentbird, сервиса подписки на духи.

Сейчас со мной работает 37 человек в команде разработки — фронтенд, бэкенд и мобайл разработчики, тестировщики, SRE и data scientist. И один из самых частых вопросов, который мне задают, зачем нам в компании столько разработчиков. С одной стороны я попробую ответить на этот вопрос, с другой — расскажу как устроен современный e-commerce/subscription бизнес в условиях, когда в бизнес модели компании есть какие-то особенности. Сразу хочу сказать, что ряд терминов буду приводить и в английском варианте, так как не уверен, какой корректный перевод подобрать.

Началось все в 2013 году, когда мы только начали работать над нашим стартапом и достаточно быстро встал вопрос — хотим ли мы использовать готовое решение, как например делает Warby Parker (вдохновивший нас на нашу первую бизнес модель), который использует Magento, или писать все с 0. Так как безрассудство и опыт в разработке (и знание только java) пьянили голову, то я активно настоял на втором варианте, сказав, что только так мы сможем всегда сделать такой онлайн сервис, который захотим. Ирония в том, что мы действительно несколько раз кардинально меняли бизнес модель. Да и летом 2014 года, общаясь с ребятами из Warby Parker и спрашивая их о совете, самым первым получили — не использовать Magento.

Тут, пожалуй, сделаю паузу и расскажу, как работает сервис. С точки зрения покупателя все просто — заходишь на сайт, регистрируешься, оставляешь данные карточки и адрес и, через несколько дней, тебе приходит твоя первая посылка. Дальше каждый месяц с тебя снимаются деньги и ты получаешь новую посылку. Вроде изян (с) Но к этой бизнес модели еще надо было прийти, так что обо всем по порядку.

Итак, первая составляющая изначальной бизнес модели — подход «try before you buy». Работает следующим образом:

• Клиент выбирает до трех бутылок парфюмов
• Делает заказ
• Неделю пробует, выбирает что оставить, а что вернуть
• Как только мы получаем посылку обратно — проводим заказ на ту сумму, сколько стоят понравившиеся ароматы

Оставим в стороне вопрос фрода и обмана со стороны клиентов (знали бы вы сколько людей в России назвали эту модель "идиотской" и "такое не может работать", между тем выручка Warby Parker — $250 млн, на рынке опять же масса решений для защиты от этого, хотя если идти вглубь, то понадобится кастомное решение. Так вот, сам подход с «try before you buy» стандартные e-commerce решения не предлагают (хотя если вы знаете такие, напишите, интересно будет изучить. Какие здесь нюансы:

• Вариации с тем, сколько денег снимать сразу, сколько в итоге, в зависимости от заказа
• Как долго можно держать транзакцию открытой
• Связь между статусом посылки и статусом транзакции — как только посылка едет обратно, надо транзакцию проводить и так далее

Вторая часть первой бизнес модели — рекомендации. Я тут же предвижу тонны комментариев, что существует масса сервисов, как например Retail Rocket. Да, существует. Но тут несколько «но»:

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

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

• Механизм, который списывает с клиента деньги в нужный месяц и день (день биллинга)
• Механизм автоматического восстановления клиента в тех случаях, когда платеж не прошел, включая коммуникацию с клиентом (recycling & dunning)
• Функционал кастомизации заказа, так как мы позволяем клиенту выбрать, что именно она или он получит в следующем месяце
• Интеграция с системой управления заказами (Order Management System, OMS) для отправки заказов и получения трекинга (tracking number) посылки, а затем и статуса самой посылки

Остановимся и по каждому пункту пройдемся отдельно, так как внутри много интересного

На сегодняшний день существуют множество систем, которые позволяют управлять подписками, то что называется subscription management system. Самые известные из них — Stripe, Recurly, Zuora, Braintree. Они представляют из себя платформу, которая, как правило, имеет следующие возможности:

• Описать план подписки — как часто и на какую сумму проводить транзакцию
• Создать профиль клиента с адресной книгой (billing & shipping address, от последнего в США зависит сумма налога), платежными инструментами и его подписками и платежами
• Создать различные скидки и рекламные предложения (например, второй месяц бесплатно)
• Различная аналитика — количество активных подписок, MRR — monthly recurring revenue (одна из основных метрик подписочных бизнесов, описывает сколько в месяц вы зарабатываете с активных подписок с учетом скидок и прочего), churn rate — скорость потери клиентов и так далее
• Интегрироваться с внешними инструментами для автоматизации налоговой отчетности, защиты от мошенничества (fraud prevention) и тому подобное
• Автоматическое восстановление подписки клиента в тех случаях, когда платеж не прошел

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

Так уж исторически сложилось, что большинство из них работают с чисто цифровыми сервисами, например сервис прослушивания музыки. Мы же — сервис отправляющий физический товар и разница в том, что мы приносим ценность в течении платежного цикла лишь один раз — когда отправляем посылку, а цифровые сервисы — каждый день. В чем тут проблема? В тех случаях, когда у вас есть несколько подписочных планов и вам нужно рассчитывать стоимость смены плана, то в случае digital (а именно это зашито по умолчанию в системы) работает prorate — расчет в зависимости от количества дней, прошедших с дня последнего платежа, в нашем же случае нужно привязываться к факту отправки посылки. Так что это приходится рассчитывать и поддерживать самим.

Идем дальше — профиль клиента. Тут как правило нет проблем, но есть масса нюансов с различными платежными инструментами (Apple Pay, PayPal, Google Wallet) и тем, как хорошо платежный сервис его поддерживают, какую версию и в каком объеме. Так что иногда приходится то тут, то там подставлять костыль.

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

• Скидка X% на первый месяц
• Скидка $Y на первый месяц
• Второй месяц бесплатно
• Третий месяц бесплатно, если оплачиваешь сразу два
• Скидка на 3/4/5 месяца на Z%
• Акции вида Groupon с вариациями (фиксированная длина подписки без автопродления, фиксированная длина подписки с автопродлением, собираем данные карты или не собираем, проводим первичный платеж или нет)
• Пробный период
• Реферальная программа
• …

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

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

• Продуктовая — воронки, эксперименты. Тут очень классно справляется Mixpanel, но он начинает стоить как крыло Боинга, так что сейчас мы смотрим на self-hosted решения
• Маркетинговая — стоимость привлечения клиента, конверсии, средний чек. Неплохо до поры до времени справляется Google Analytics, но удачи вам его настроить без помощи эксперта
• Финансовая — это вообще отдельное развлечение

Опять же повторюсь, что это разделение условное, потому что все эти данные тесно связаны между собой и рассматривать их отдельно друг от друга бессмысленно. И тут вот какая история — сами платежные сервисы дают только базовые вещи, но дают возможность экспорта, так что потом можно работать с голыми данными. Есть много интересных внешних систем (например, Revealytics), но они также имеют зашитые правила подсчета тех или иных метрик, так что вам надо начинать поддерживать определенные подсчеты на своей стороне. При этом, самая дурацкая ситуация случается когда у вас с десяток систем и цифры друг с другом не сходятся.Как говорится «счастливой отладки, сволочи» (с)

В конечном итоге мы 2 года назад пришли к тому, что все данные заливаем в AWS Redshift. Поверх него работает Looker, который позволяет все это визуализировать. Про то, как мы к этому пришли можно послушать в рассказе тимлида нашей команды аналитики Вани Зерина.

А вот теперь поговорим, наверное, о самом критически важном функционале платежных сервисов — восстановление клиентов, чей платеж не прошел в день биллинга. Причин, по которым не проходит платеж может быть много:

• Нет денег на счету (самая популярная причина)
• Карточка закрыта
• Карточка истекла
• Карточка была украдена и закрыта
• Банк подумал, что это fraud
• Это на самом деле fraud
• У банка был maintenance
• И многое-многое другое

Как я уже писал выше, большинство сервисов не проводят платежи сами, а поддерживают один или несколько платежных процессоров. Каждый из этих процессоров имеет (если имеет) свой индивидуальный код для каждой ошибки и дальше платежный сервис либо передает их как есть, либо отдает свое сообщение. По этой причине, мы в свое время отказались от Stripe — для 90% случаев они отдавали generic decline и было непонятно, что делать дальше. Почему важно получать эти коды? Потому что именно в зависимости от ошибки, алгоритм восстановления должен быть разным.

Во-первых, есть деление на hard failure (например, карта закрыта/украдена) и soft failure (нет денег). Сделано для того, чтобы не пытаться проводить лишние транзакции для hard failure, не терять на этом денег и не иметь проблем с Visa/MC. Но и тут нюанс в том, как именно платежный сервис относит ошибку в ту или иную категорию. Например,у PayPal есть ошибка 10417 — Transaction cannot complete — "Instruct the customer to retry the transaction using an alternative payment method from the customer's PayPal wallet" or "The transaction did not complete with the customer's selected payment method". Как мы выяснили, она означает одновременно и что платежный метод недоступен, и что на счету не хватает средств. Наш предыдущий шлюз по умолчанию эту ошибку относит к Hard failure и после реконфигурации мы начали восстанавливать гораздо больше людей.

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

Ну и последний момент про восстановление. Очень важно пытаться проводить транзакцию несколько раз после изначальной попытки, так как есть весьма и весьма высокий шанс, что он пройдет. Мы восстанавливаем около 85% всех не прошедших платежей за счет данной механики. Тут тоже несколько нюансов:

• В штатах разные подходы к выплате зарплаты — 1 числа, 2 раза в месяц по пятницам, каждую неделю в пятницу и так далее. Мы стараемся проводить платежи так, чтобы попадать в дни близкие к описанным, что повысить вероятность успешной транзакции
• Многие банки делают maintenance по ночам, поэтому транзакции лучше делать в дневное время
• Также банк может принять транзакцию за фрод, если она проводится в то время, когда клиент обычно деньги не тратит
• Есть механизм force deposit, позволяющий снимать деньги и уводить баланс счета в минус, но тут надо быть аккуратными, так как может прилететь от Visa/MC

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

Ну и в завершение поговорим про платежные процессоры. Иметь несколько имеет смысл если вы:

• Имеете большой объем трафика и хотите оптимизировать interchange fee (сколько денег вы платите Visa/MC/… за проведение транзакции; разные процессоры имеют разные контракты на разные типы карт)
• Для вас важно иметь запасной процессор, если один по какой-то причине не работает
• Вы работаете в нескольких странах. таком случае разные процессоры по-разному работают с местными банками и национальными платежными средствами (например, в Штатах очень хорошо работает Vantiv, а в Европе — Adyen)

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

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

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

Хорошо, поговорили про платежи, теперь — про посылки. Как я уже писал, мы даем нашим клиентам выбирать, что они хотят получать. Это отличает нас от большинства подписок, где кастомизации или нет совсем или она очень простая (2-3 варианта, как например Dollar Shave Club). Сейчас многие сервисы дают больше выбора, так что они начинают сталкиваться с теми же задачами, что и мы.

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

Базово все достаточно просто, но давайте разбираться, как мы это делали выше. Во-первых, выбор клиента надо закреплять (мы это называет freeze the queue) за день до того, как будет совершена оплата, чтобы потом человек не сказал, что мы прислали ему не то, что нужно. Этот же элемент нужно убрать как только посылка будет доставлена адресату. Но что если человек указал неверный адрес и посылка вернулась? Или если платеж не прошел до конца месяца? А вдруг парфюм на складе кончился и новая поставка придет не скоро? Для всего этого нужно продумывать свои решения.

Во-вторых, у нас существует не один подписочный план, а 46. Само собой человек не видит все эти планы в виде списка на сайте, вот ЭТО было бы безумием. Часть этих планов — это опции апгрейда:

• Оплата сразу за несколько месяцев вперед
• План с 2-3 продуктами
• Комбинация первых двух опций

Затем есть подарочные подписки и возможность сменить частоту получения посылки на раз в два и или три месяца, ну и еще несколько технических планов. К этому добавляем то, что иногда у клиентов могут быть бесплатные месяцы (например, за счет реферальной программы), которые людям хочется видеть. А теперь садимся и думаем, как получить такое из коробки того же Shopify. Никак.

В-третьих, не все парфюмы одинаковы перед лицом клиента. Есть духи с ограниченным тиражом (это значит их нельзя продать больше, чем в наличии), есть духи из более дорогой категории (+$5/$10 за каждый такой парфюм выбранный на текущий месяц). Если у вас голова уже идет кругом — не переживайте, у нас тоже. Слава богу, есть интеграционные и функциональные тесты, которые позволяют не сломать сложный механизм одним простым коммитом.

Допустим, все хорошо, клиент выбрал парфюм, оплата прошла успешно, теперь осталось самое простое — отправить посылку. Да, но нет. Все просто до тех пор, пока не появляются посылки с несколькими товарами.

Тут давайте сделаем шаг в сторону и немного поговорим о логистике в Штатах. Как правило, большинство компаний пользуются услугами партнера по работе с логистикой и складом, так называемые 3PL компании (3rd party logistic). Они берут на себя обязанности по приему товара на складе и его хранению, отправке посылок, работе с возвратами и контрактами с перевозчиками (carriers). Перевозчики как правило это крупные компании (USPS, UPS, DHL, FedEx) и многие сервисы уровня last mile delivery. Last mile delivery — это доставка товара клиенту от последнего склада. Как правило, это либо небольшие региональные компании, либо USPS, который доставляет везде в США. И есть еще спец почта, которая развозит посылки по военным базам, посольствам и так далее. (У нас было несколько клиентов, адрес который указывал на службу на авианосце. В море тоже хочется хорошо пахнуть.)

Так вот, 3PL компании используют в своей работе так называемые WMS системы — warehouse management system. Эти системы предназначены для учета товара на складе, приема и отправки грузов и всех активностей вокруг него. Очень часто WMS является частью большей системы — ERP. Примером ERP является хорошо известная всем система SAP. WMS систем на рынке на текущий момент существует достаточно большое количество, большинство из них хорошо интегрированы с такими сервисами, как Shopify или Magento. Если вы используете их, то все здорово. Но все сноварушится, когда мы начинаем говорить о подписках, потому что есть тот самый фактор биллинг дня, когда после прохождения всех платежей нужно передать большое количество заказов. вот тут случается проблема, так как большинство из этих систем просто не рассчитаны на такую нагрузку.

Первые несколько лет нам удавалось работать с внешними вендорами, но как только мы прошли отметку в 200 тысяч подписчиков, все рухнуло с очередным партнером и нам пришлось в срочном порядке подхватывать это самим. В целом, отправлять посылки просто. Берем товар, карточку, упаковываем в bubble mailer (полиэтиленовая упаковка с пузырчатым покрытием внутри), наклеиваем shipping label (наклейка с указанием куда доставить, с каким тарифом, tracking number и так далее), несем на почту. Profit! Но все несколько сложнее, когда посылок 200 тысяч и даже печать лейблов становится интересной задачей. Давайте ее и разберем.

Начнем с того, на чем печатать. Для этой цели используется промышленный принтер, в нашем случае — Zebra ZT-510, способный выдавать 2 лейбла в секунду, в теории. На практике это где-то 1.6. Простая математика говорит, что где-то за 35 часов мы справимся если будем печатать на 1 принтере без остановки. Но как всегда, есть нюансы:

• Надо менять бумагу ведь в рулоне как правило 2000 листов
• Надо уметь отделять заказы по похожести, то что называется batching
• Иногда принтер жует лист и надо перезапустить печать
• Нельзя допустить дупликации из-за операции выше
• Нужно время от времени чистить печатный валик
• Для скорости нужно брать несколько принтеров, поэтому надо уметь управлять печатью в параллели

Идем дальше — где взять сам лейбл? Правильно, воспользоваться сервисом их генерации. Тут конечно можно делать прямую интеграцию, но мы все-таки не настолько любим проблемы, чтобы копаться в SOAP, так что идем в сервис Shippo и все более-менее в шоколаде.

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

Сейчас спустя два года у нас есть как приложение на Electron для управлению печатью, так и свой WMS для управления работой на складе, алгоритм умного разбиения на батчи и многое другое.

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

• Мобильные приложения, куда активно перетекает наша аудитория
• Расширенная аналитика, в том числе и финансовая
• CRM (client relationship management) для нашей технической поддержки, которая также написана с 0, чтобы поддержать все наши возможности
• Персонализации и рекомендации
• Десятки интеграций с внешними сервисами
• Интеграция с Oracle NetSuite, которая эпична сама по себе
• И многое, многое другое

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

Так что отвечая на вопрос в заголовке — столько, сколько позволят вам построить классный, технологический бизнес.

Кстати, если вам нравятся те задачи, которые мы решаем, пишите мне — мы планируем нанимать QA инженеров и java разработчиков в следующем году!