Главная » Хабрахабр » Как мы улучшали конверсию платежной формы

Как мы улучшали конверсию платежной формы

Онлайн-платежи стали чем-то настолько же привычным, как и wi-fi дома и скоростной мобильный интернет. И они продолжают эволюционировать, все больше и больше услуг можно оплатить в пару кликов или из мобильных приложений, а тут еще и автоплатежи, напоминалки, контроль расходов и многое другое.

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

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

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

Это не так. Почти все сейчас говорят, что показатель конверсии у платежных форм — это около 99 процентов, а то и выше.

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

Здесь конверсия уже в районе 75-85 процентов. А вот если это обычная покупка, то тут можно легко потерять сразу четверть клиентов в процессе оплаты.

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

Или же с формой все хорошо, но, глядя на цену, человек решает проверить на том же Маркете цены повыгоднее, и уходит с формы. Да и с реальным товаром похоже — тут могут отвлечь и дополнительные поля, человек хочет купить уже наконец пылесос, а форма у него спрашивает и номер телефона, и почту, и кличку кота (мы здесь именно про запросы платежной формы, а не личного кабинета магазина, которому ряд данных необходим для доставки и отслеживания заказа).

Казалось бы, здесь целеустремленность явно выше, чем желание купить себе что-что, перейдя на сайт магазина из письма с темой «Только сегодня скидка 80% на все*!».
*почти на все
**на те два утюга и восстановленный SE
Немного удивительно, правда, было видеть подобное поведение при оплате образовательных услуг.

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

Как измеряли

Большинство проводит измерения примерно вот так.

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

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

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

О напоминаниях

Напоминания — это вообще отдельная история. Мы пробовали тут разные механики. Ожидаемо хреново пошло дело с веб-пушами. Например, был человек на сайте магазина, набрал корзину, получил в платежной формочке счет, который не стал оплачивать, и закрыл окно — а ему потом веб-пуши «Оплатите счет». Такая штука раздражает. Тем более, веб-пуши без адекватного контекста воспринимаются как спам уже.

Потом процентов 10 по ним перейдут. Ну, подпишутся процентов 10 пользователей на такие пуши. А если еще и учитывать, что сама база таких пушей за месяц процентов на 15 протухает… В общем: для среднестатистического сайта с учетом посещаемости такие цифры делают веб-пуши не самым полезным каналом напоминаний.

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

Пошел ты купить новую игрушку в стиме. Например. Через недельку пошел купить какую-нибудь фитюльку на Али, совершаешь оплату, а формочка потом тебе — «Пст, ты тут недельку назад хотел игрушку купить, смотри». Выбрал, начал оформлять заказ, понял, что денег не хватит сейчас, или просто решил отложить на потом. И такие пользователи обычно идут и завершают и предыдущий платеж.

По цифрам — веб-пуш приносит на удельную рассылку 3 рубля.
А подобное напоминание — 60 рублей.

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

Работа протокола

Раньше у нас был просто кошельковский протокол, я о нем уже писал тут.

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

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

А на деле получается, что у покупателя может не быть средств на карте. Со стороны может показаться довольно простым все это — поставил платежную формочку какую-нибудь, и только успевай деньги считать. Ну, бывает такое.

Не хватает на платеж? И тут мы в форме сразу предлагаем в таких случаях альтернативу. Или вообще по Совести вот здесь. Смотри, у нас можно с мобилки по-быстрому это оплатить, через SMS. Или еще чего.

То есть при отсутствии денег не «Не хватает средств» как ошибку, которая ведет только к закрытию окна или попытке ввести другую карту, а сразу предлагать иные способы оплаты, не разворачивая пользователя. Здесь важно то, что клиент видит в таком случае не только проблему, но и варианты ее решения.

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

Гораздо проще поднять ее на 2—3—5 процентов, чем пытаться понизить ставку эквайринга (которая и так в районе 2). А вот конкурировать по конверсии в оплату можно.

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

Не вебом единым

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

И были классные мобильные приложения в топ 3 в маркетах. В 2015 у нас было около 10 процентов заходов с мобилок. Мы решили не очень заморачиваться тогда и в качестве эксперимента сделали простую адаптацию под мобайл. Был выбор — или пилить отдельное веб-приложение под мобильные, или сделать простой адаптивный чекаут. И за полгода у нас эта цифра выросла с 10% до 30%.

Год назад — около 40 процентов.
Сейчас — 51-52.

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

Здесь 14 крупных интернет-магазинов, называть которые мы не будем, но просто знайте — крупные. Вот, кстати, схемка, показывающая распределение продаж в зависимости от того, адаптирован ли магазин или нет.

У кого адаптация или приложение — тоже есть улучшения в продажах, как и у совсем легкой адаптивки. У кого есть мобильное приложение — у того уже в 1,5 раза больше покупок.

Но даже им не так грустно, как синим — у этих с мобилки не работает вообще ничего. Фиолетовые на схеме — парни без адаптива.

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

А сейчас у нас новая версия, которая красиво укладывается над экранной клавиатурой, отлично работает с API от Google и с iOS в плане автозаполнения карт. Мы сделали первый шаг в 2015-м, как я писал выше. И сейчас у нас конверсия по мобилкам почти сравнялась с десктопной. И все это под ключ, чтобы было быстро и удобно. Адаптивка при этом сама определяет, как ей сейчас на каком экране нужно показаться.

Кошелек и интеграция

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

Сессии разбиты на полутокены, то есть половина токена у нас, а половина на устройстве пользователя. Авторизацию мы запоминаем на полгода, как по паролю, так и через SMS. Если что — в 1 клик сессию можно сбросить.

Сквозная оплата работает везде — например, даже в приложении АлиЭкспресса для мобилок открывается наша форма, в которой уже все заполнено, если покупатель ранее этим пользовался.

У нас в базе почти весь активный екоммерс. Мы решили поддержать еще и обратную совместимость, и новый прокачанный протокол работает и у тех партнеров, которые внедрили протокол в 2010-м, и у тех, кто поставил его только вчера. И всю эту базу мы перетащили на новые инструменты.

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

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

Протокол проектировался не только технарями, но и под неусыпным оком бизнеса. Интеграция, к слову, тоже максимально упрощена. В старом протоколе было 5 параметров — ID провайдера, секретный пароль, ID авторизации, валюта, пароль для оповещений. Причем не в плане следить и подгонять, а в плане учесть на старте все бизнесовые сложности и упростить все будущие интеграции.

Публичный ключ для веб-форм, который можно светить наружу, и секретный ключ, который используется в серверном API с полными правами доступа, возможностью отменять транзакции, делать возвраты и прочее. В новом — 2 параметра.

Ранее надо было знать ID счета и номер телефона. Плюс мы сделали возможность передавать любые дополнительные данные. Надо закинуть номер телефона, адрес для доставки — вот оно. А теперь есть custom fields — хочется провайдеру получить внутренний айдишник покупателя — пожалуйста. И во всех оповещениях после успешной оплаты будут возвращаться такие данные. В общем, чтобы не писать свою логику для всего этого, можно просто передать нам.

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

В котором был и процессинг. Ранее все было в монолите. Сейчас получается, что процессинг фактически отвечает за проведение транзакций. Затем он начал по бокам обрастать дополнительными полезными штуковинами. Кстати, для карт мы написали новый — ускоренный, чтобы не тянуть наследие времен.

Благотворительные взносы

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

Проседает бухгалтерия компании, которой мы делаем перечисление — тут в таких случаях нужно делать сложный тройной договор (мы, компания, фонд). Штуковина немасштабируемая от слова вообще.

Передумал ты насчет чайника, вернул его. А еще с возвратом сложно. А сумма за чайник и взнос ушли одной транзакцией.

Поэтому мы решили делать вот так.

Такая схема работает, примерно 3—5 процентов на это готовы идти. После успешной оплаты пользователю предлагается в 1 клик сделать небольшое пожертвование. Если она не сильно превышает 50 рублей, то это ОК и просто. Тут главное сумма. Если больше — тут уже нужен контекст, куда пойдут деньги, а чего за фонд, а чем занимаются и прочее.

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

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

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

Стало около 30 000 — 35 000 в месяц. Ранее прямо осознанных благотворительных платежей на сайте в адрес фонда Хабенского было штук 20 в месяц. Запустили это и подумали, что хорошо бы показывать такое не только с оплаты с Кошелька, но и при любой другой — картой и прочее.

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

Кстати, вы можете попробовать нашу платежную форму, а заодно сделать доброе дело, поддержав один из фондов:

  • Вера — системная помощь хосписам и их пациентам
  • Фонд Хабенского — помощь детям с тяжелыми заболеваниями головного мозга
  • {всем — сразу нескольким благотворительным фондам в равных долях

Пишите, если есть желание. А владельцы сайтов могут помочь любому фонду, разместив виджет или ссылку у себя: widget.qiwi.com/vera, my.qiwi.com/bfkh, my.qiwi.com/vsem или множество других.

Open source

Сейчас в сторону опенсорса мы двинулись довольно активно. Документацию, примеры, SDK и интеграции мы опубликовали на https://github.com/QIWI-API/. Читая документацию, можно нажать на кнопку “редактировать на GitHub” и сделать запрос на исправление.

Оживили и GitHub QIWI, и GitHub QIWI API. Вообще, мы стараемся тащить в опенсорс все, что не является процессингом. Многое активно несем в GitHub. Хотим, чтобы проекты и компоненты лежали отдельно, а документация, различные SDK и библиотеки поверх QIWI API — отдельно.

В принципе, QIWI сейчас разворачивается в сторону BaaS, Bank as a Service. Открываем API Кошелька, чтобы все возможности, доступные внутри компании, были открыты и внешним разработчикам. Поэтому движемся в опенсорс. И наша задача тут — чтобы все апишки были простыми, с общими практиками.

На будущее

Хотим взять все отличное и работающее для оплаты с QIWI Кошелька и использовать это для полноценной работы с картами — все эти напоминания, забытые оплаты и прочее. Добавить способы выставления счетов в банке. Само собой — Apple Pay и Google Pay. Они были сдвинуты в приоритетах довольно сильно, так как не влияли на оборот вообще и были такими себе имиджевыми штуками, потому что в нашем случае это было уже из разряда маркетинга, нежели значимой прибыли для клиентов.

Для WordPress сделали, а для других — в ближайшей очереди. Скоро доделаем официальные плагины для CMS-ок, чтобы владельцы маленьких магазинов могли подключать QIWI Кассу и принимать оплату.

Еще работаем над упрощением интеграции с операторами фискальных данных для соблюдения 54 ФЗ и интересным решением для р2р-переводов и самозанятых.

Стараемся делать так, чтобы бизнес мог просто прийти и быстро подключить себе кучу готовых решений. Kassa.qiwi.com — здесь мы собрали все наши услуги для мелкого и крупного бизнесов.

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

В общем, планов громадье, и общий посыл — сделать интеграцию еще проще и доступнее.

S. P. Кстати, вот страница про нашу команду: kassa.qiwi.com/team

Для желающих в JS Fullstack у нас есть тестовое минут на 15, чтобы можно было пощупать данные, библиотеки и подходы, с которыми мы работаем внутри. Мы всегда будем рады React JS-разработчикам и Java-программистам. 🙂 Справлялись и школьники, но подвисали и шестикуры.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

DWDM: решение дешевле операторского на 30-50% (класс Enterprise)

Теперь можно купить собственные DWDM-юниты, поставить их в стойку в дата-центре. На рынке оптики кое-что поменялось за последние два года. И получить всё это дешевле, чем традиционные операторские решения. Кому нужно точно: Если у вас стоит транспортная сеть DWDM/CWDM, реализованная ...

Как мы построили быстрое и надежное хранилище просмотров объявлений

Одна из малозаметных, но важных функций наших сайтов объявлений — сохранение и отображение количества их просмотров. Наши сайты следят за просмотрами объявлений уже больше 10 лет. Техническая реализация функциональности успела несколько раз измениться за это время, и сейчас представляет из ...