Как инструменты application performance monitoring помогают исправить ошибки платежного шлюза или ошибку при оплате
Содержание
Если вы ведете бизнес в Интернете, вы, вероятно, используете несколькими поставщиков платежных шлюзов. Одна единственная проблема с платежным провайдером может свести на нет СОТНИ часов, потраченных на оптимизацию пользовательских операций с вашими мобильными или веб-приложениями, которые вели покупателя по воронке и совершению покупки. Высококачественная графика, запуск A/B-тестирования для настройки UX или развертывание нового кода становится бесполезным, если человек НЕ МОЖЕТ ЗАПЛАТИТЬ. В среднем 70% пользователей отказываются от конечной покупки.
Рассказываем как избежать проблем с платежным шлюзом, используя бизнес-инструменты Dynatrace. Платформа APM и наблюдаемости дает вам полное представление об ошибках платежей, влияющих на вашу пользовательскую базу: вы видите какие ошибки платежей влияют на пользователей и можете количественно оценить влияние этих ошибок на бизнес. Dynatrace Business Analytics использует Dynatrace Real User Monitoring (RUM), Dynatrace PurePaths и внешние метрики, получаемые через Dynatrace API.
Используя предоставляемую Dynatrace информацию, вы можете:
- Расставить приоритеты платежных ошибок по силе их влияния на доход.
- Принимать в режиме реального времени решения о включении или отключении различных платежных шлюзов.
- Выявлять затронутых пользователей и направлять на них ретаргетинг.
Влияния ошибок платежей на бизнес
Чтобы понять общее влияние на бизнес, можно использовать язык запросов сеансов пользователей (USQL) для создания дашбордов. Ниже мы видим, как 18 пользователей отказались от своей корзины из-за ошибки платежа, а общая стоимость корзины составила 8 376 729,54 тенге (14 401 фунт стерлингов)
Панель инструментов на основе USQL, показывающая количество отказов пользователей за шаг и общую стоимость корзины этих пользователей
На дашборде наглядно видна потенциальная потеря дохода и масштаб проблемы. Затрагивает эта проблема весь сайт? Сколько людей затронула проблема? Далее мы покажем вам, как идентифицировать этих людей для последующего наблюдения или ретаргетинга.
Что касается самих поставщиков шлюзов, Dynatrace может использовать данные из многих источников, чтобы в режиме реального времени получать полезные сведения и отвечать на следующие вопросы:
- Есть ли проблемы с платежными шлюзами?
- Как эти проблемы влияют на результаты бизнеса?
- Какие условия должны запускать автоматическое исправление (например, отключение определенного платежного шлюза)?
Использование данных полного стека для отслеживания работоспособности платежных шлюзов
На приведенном ниже снимке экрана диаграммы слева основаны на данных, полученных из внешнего API, а диаграммы справа основаны на контекстном анализе на стороне сервера от OneAgent. Таким образом мы знаем о времени отклика для каждого провайдера.
В первую очередь нам помогает анализ сессий пользователей. Dynatrace RUM уже дает готовую информацию об ошибках, с которыми сталкиваются пользователи. В приведенном ниже примере пути пользователя мы видим, как пользователь сталкивается с проблемой на этапе проверки кредитной карты. Что послужило причиной отказа от покупки
Мы можем запросить эти данные RUM с помощью USQL, чтобы понять, у скольких пользователей была такая же проблема. Приведенный ниже запрос ищет всех пользователей, у которых произошла ошибка во время оплаты, а затем они отказались от покупки.
Запрос USQL, который подсчитывает количество пользователей, у которых произошла ошибка оплаты, а затем они были брошены.
Но мы можем пойти гораздо дальше! Какая у них была ошибка? Какой платежный шлюз был ответственным? Каков статус всех наших платежных шлюзов? То, как вы извлекаете эту информацию, зависит от того, где она представлена; Dynatrace может получить его из браузера пользователя или по мере того, как он проходит через ваш код.
Если большая часть взаимодействия происходит в браузере, лучше всего подойдут свойства сеансов пользователя (user actions). Их используют для извлечения дополнительных сведений с помощью селекторов CSS (если сведения находятся в HTML) и из глобальных переменных JavaScript. Довольно часто переменные JavaScript уже существуют для инструментов аналитики или в качестве стандарта, реализованного командой веб-разработчиков для предоставления полезных данных (dataLayer — это тот, который мы видим довольно часто).
Если взаимодействие происходит на стороне сервера, вы можете получить данные, используя атрибуты запроса. В приведенном ниже примере мы извлекаем идентификатор платежа и провайдера шлюза, поскольку он передается через код в службу автоматического мониторинга.
Каким бы ни был источник (селектор CSS, переменная JavaScript или атрибут запроса), его можно связать с отдельным пользователем, как показано ниже. Кроме того, таким образом можно получить значение «корзины» или «заказа», чтобы мы могли начать количественную оценку влияния на бизнес, помимо числа затронутых пользователей.
На высоком уровне это теперь позволяет нам повторно посетить наш запрос USQL и расширить его, чтобы получить список пользователей (с их идентификатором, чтобы мы могли их отметить), которые отказались от своей покупки из-за ошибки платежа, и перечислить конкретные ошибка, которую они получили, а также идентификатор платежа, чтобы помочь устранить неполадки с провайдером шлюза. Эта информация также может быть использована при перенацеливании, когда вы можете предложить помощь юзеру или какой-либо стимул для завершения неудачной покупки.
Даже после того, как платежи переданы поставщику, информация может быть получена для визуализации их статуса. Например, многие платежные шлюзы предоставляют API для запроса платежей и их статуса. Эту информацию можно передать в Dynatrace с помощью API-приема, как показано в примере Postman ниже.
Как только эта информация об ошибке попадает в Dynatrace, она анализируется нейросетью и визуализируется в формате понятного отчета на дашборде. Да, ошибки с платежами неизбежны, но только от нас зависит как быстро мы их исправим, тем самым увеличив прибыль компании.