Измерение влияния проверки адреса с помощью теста A/B

В этом документе описаны методы, которые следует учитывать при проведении A/B-тестирования API автозаполнения мест и проверки адреса платформы Google Карт.

Несколько преимуществ использования API автозаполнения мест и проверки адреса заключаются в следующем:

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

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

A/B-тест – это способ сравнить две версии веб-страницы или приложения друг с другом. Это тип контролируемого эксперимента, который используется для определения влияния изменения переменной на измеримый результат.
Чтобы выполнить A/B-тест, создайте две версии страницы или приложения: одну в качестве контрольной, а другую с измеримыми изменениями. Затем вы показываете эти версии разным пользователям и измеряете, как они с ними взаимодействуют. Версия, которая работает лучше, становится победителем.

Обзор архитектуры системы

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

[Системный контекст] Проверка адреса A/B-тестирования

Системы, участвующие в A/B-тестировании значения API проверки адреса.

На диаграмме архитектуры показано, как покупатель вашего веб-сайта электронной коммерции взаимодействует с системой A/B-тестирования. Эта система принимает решение о том, какую тестовую переменную отображать покупателю, из системы программного обеспечения интернет-магазина. Интернет-магазин выполняет вызов API к программной системе платформы Google Maps. Он также собирает аналитические данные A/B-тестирования, которые обрабатываются аналитической программной системой и передаются обратно в систему A/B-тестирования.

Процесс A/B-тестирования

Когда вы думаете об общем процессе A/B-тестирования, следует учитывать четыре этапа.

  • Подготовка . Определите требования к тестированию, объем и сроки.
  • Сборка . Внедрите API автозаполнения мест и проверки адреса в среде, в которой будет выполняться тест.
  • Выполнить — собирайте метрики во время выполнения теста, пока не будут получены существенные результаты или не истечет время.
  • Анализ . Сравните результаты с гипотезой и определите следующие шаги.

Мы поговорим о каждом из них по очереди.

Подготовка

Определение требований к A/B-тестированию

Первоначальное открытие

Спросите себя: почему вы добавляете или меняете поставщика проверки адреса? Например, используя автозаполнение мест Google Maps:

  • Экономия времени: вам не нужно вводить полное название места, вы можете просто начать вводить и увидеть предложения.
  • Уменьшает количество ошибок: если вы ошибетесь в названии места, автозаполнение мест на Картах Google все равно предложит правильное место.

Проверка адреса имеет множество преимуществ, в том числе:

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

Решение по гипотезе

Определитесь с гипотезой, которую будете проверять. Вот два примера:

1. Коэффициент конверсии

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

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

2. Сокращение некачественных адресов

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

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

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

Строить

Теперь самое интересное! Пришло время создать новое решение для ваших клиентов. У нас уже есть удобное руководство по реализации API автозаполнения мест и проверки адреса при оформлении заказа электронной торговли. Мы рекомендуем вам проверить это при выполнении этого шага.

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

Схема архитектуры

Ниже приведен пример контейнеров, которые можно использовать для создания A/B-теста в среде электронной коммерции:

[Среда выполнения] Проверка адреса A/B-тестирования

Важные приложения, службы и хранилища данных в ключевых системах, поддерживающих архитектуру. (Нажмите, чтобы увеличить.)

На схеме архитектуры показаны контейнеры, составляющие систему программного обеспечения A/B-тестирования и систему программного обеспечения приложений для электронной коммерции. Он показывает покупателя на вашем веб-сайте электронной коммерции, взаимодействующего с балансировщиком нагрузки, который направляет его в приложение веб-сайта электронной коммерции. Менеджер A/B-тестирования взаимодействует с балансировщиком нагрузки, чтобы выбрать переменную A/B-теста для отображения клиенту. Эта система A/B-тестирования также записывает результаты и конфигурацию A/B-теста в базу данных по вашему выбору. Веб-приложение электронной торговли выполняет вызовы API к программной системе платформы Google Maps, а также сообщает о событиях аналитики в программную систему Analytics, которая записывает тестовые события в базу данных результатов A/B-тестов.

Проверка реализации

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

Бегать

Наращивание медленно

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

Полный тест

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

Сбор показателей

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

Некоторые предлагаемые показатели заключаются в следующем:

Разместить автозаполнение

Коэффициент конверсии. Улучшился ли коэффициент конверсии/заполнения вашей формы по сравнению с отсутствием решения для автозаполнения ранее?
Взаимодействие с инструментом: больше пользователей успешно взаимодействуют с автозаполнением мест по сравнению с предыдущим решением?

Проверка адреса

Успешная доставка: произошло ли сокращение количества неудачных доставок из-за качества адреса?
Изменение адреса. Снизилось ли количество платежей за изменение адреса, которые вы получаете от курьеров?
Жилые и коммерческие объекты: произошло ли улучшение в сборе данных о жилых и коммерческих объектах? ( только на некоторых рынках )

Анализировать

Теперь тест завершен, пришло время проанализировать результаты на предмет соответствия исходным критериям и гипотезе теста. Если вы использовали платформу A/B-тестирования для завершения процесса, некоторая информация может быть вам уже доступна.

Возвращаясь к разделу «Сокращение количества некачественных адресов» выше, вы также можете использовать другие показатели, которые, возможно, не были зафиксированы платформой A/B-тестирования. Это может быть процент неудачных поставок между сценариями тестирования, с примерами таких данных:

Решение А Решение Б
Неудачные поставки 1,75% 1,23%

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

Заключение

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

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

Приятного тестирования!

Следующие шаги

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

Рекомендуемое дальнейшее чтение:

Авторы

Основные авторы:

Хенрик Валв | Инженер по решениям платформы Google Maps