В этом документе описываются методы, которые следует учитывать при проведении A/B-тестирования API автозаполнения мест и проверки адресов платформы Google Карт.
Вот несколько преимуществ использования API автозаполнения мест и проверки адресов:
- Улучшенный клиентский опыт: предоставляя своим клиентам предложения в реальном времени по адресам и местам, вы можете помочь им завершить оформление заказа быстрее и проще. Это может привести к улучшению клиентского опыта.
- Улучшенная точность данных: API автозаполнения и проверки адресов Place Autocomplete может помочь вам повысить точность данных о клиентах. Это может быть особенно важно в электронной коммерции, поскольку точные данные об адресах необходимы для успешной доставки посылок.
Чтобы улучшить качество ваших адресов, проведите A/B-тест, чтобы оценить, какое решение для проверки лучше всего соответствует вашим потребностям. Это дает вам возможность количественно решить, какой продукт лучше всего подходит для вашего варианта использования.
Тест A/B — это способ сравнить две версии веб-страницы или приложения друг с другом. Это тип контролируемого эксперимента, который используется для определения влияния изменения переменной на измеримый результат.
Чтобы провести A/B-тест, создайте две версии страницы или приложения: одну в качестве контроля и другую с измеримым изменением. Затем вы показываете эти версии разным пользователям и измеряете, как они с ними взаимодействуют. Версия, которая работает лучше, становится победителем.
Обзор архитектуры системы
Давайте рассмотрим A/B-тестирование проверки адреса в случае использования электронной коммерции. Архитектурная диаграмма ниже показывает, как клиент будет взаимодействовать с вашим опытом торговли, что позволяет вам определить более эффективную стратегию проверки.
[Системный контекст] Проверка адреса A/B-тестирования
Системы, задействованные при A/B-тестировании значения API проверки адресов.
Процесс A/B-тестирования
Когда вы думаете об общем процессе A/B-тестирования, следует рассмотреть четыре этапа.
- Подготовка — определение требований к тестированию, объема и сроков.
- Создание — реализация API автозаполнения и проверки адресов в среде, в которой будет выполняться тест.
- Выполнить — собирать показатели во время выполнения теста, пока не будут получены значимые результаты или не истечет время.
- Анализ — сравнение результатов с гипотезой и определение следующих шагов.
Мы поговорим о каждом из них по очереди.
Подготовка
Принятие решения о требованиях к A/B-тестированию
Первоначальное открытие
Спросите себя: Почему вы добавляете или меняете поставщика проверки адреса? Например, используя Google Maps Places Autocomplete:
- Экономит время: вам не нужно вводить полное название места, когда вы можете просто начать печатать и увидеть предлагаемые варианты.
- Уменьшает количество ошибок: если вы неправильно написали название места, функция автозаполнения мест Google Карт все равно предложит правильное место.
Проведение валидации имеет множество преимуществ, в том числе:
- Улучшенные показатели доставки: Проверка адреса может помочь улучшить показатели доставки, гарантируя, что почта и посылки будут отправлены по правильному адресу. Это может сэкономить время и деньги для бизнеса и повысить удовлетворенность клиентов.
- Улучшенное качество данных: Проверка адресов может помочь улучшить качество данных, выявляя и исправляя ошибки в адресах. Это может повысить точность маркетинговых кампаний и других инициатив, основанных на данных.
Принятие решения по гипотезе
Определите, какую гипотезу вы хотите проверить. Вот два примера:
1. Коэффициент конверсии
При добавлении решения type ahead обычно наблюдается небольшое увеличение коэффициентов конверсии, и это хороший показатель для отслеживания. Если вы меняете решение type ahead от другого поставщика, то следует ожидать фиксированного коэффициента конверсии. Если коэффициент конверсии снижается, первым делом следует проверить реализацию.
Коэффициент конверсии важен, но он может не отражать всю историю. Добавление решения по проверке адреса призвано удержать людей от отправки некачественных адресов в точке входа и может добавить некоторые естественные помехи для сбора адреса в некоторых сценариях. Это может привести к снижению общих коэффициентов конверсии, но это не обязательно следует рассматривать как что-то плохое. Незавершенные заказы из-за добавления проверки адреса могли быть связаны с некачественными адресными данными, что привело бы к расходам для бизнеса из-за возвратных платежей за доставку.
2. Сокращение количества некачественных адресов
Вот где хорошее решение для проверки адресов может действительно проявить себя. Внедрив проверку адресов, вы должны ожидать сокращения количества некачественных адресных данных.
Если вы сравниваете новое решение с существующим, может возникнуть соблазн просто сравнить показатели совпадения «хорошего адреса» и выбрать службу, которая обеспечивает более высокий показатель совпадения. Это может ввести в заблуждение, поскольку одна служба может предоставлять больше ложных срабатываний, чем другая.
Вместо этого более эффективной метрикой является сравнение успешного результата использования адресных данных. Если взять в качестве примера электронную коммерцию, то желаемым результатом сбора адреса будет успешная доставка посылки.
Строить
Теперь самое интересное! Пришло время создать новое решение для ваших клиентов. У нас уже есть удобное руководство по внедрению Place Autocomplete и Address Validation API в кассу электронной коммерции. Мы рекомендуем вам ознакомиться с ним при выполнении этого шага.
Даже если вы не разрабатываете приложение специально для электронной коммерции, большая часть информации все равно будет актуальна, особенно руководство по определению качества адреса на основе выходных данных API проверки адреса.
Архитектурная схема
Ниже приведен пример контейнеров, которые можно использовать для создания A/B-теста в среде электронной коммерции:
[Среда выполнения] Проверка адреса A/B-тестирования
Важные приложения, службы и хранилища данных в ключевых системах, обеспечивающих работу архитектуры. (Нажмите для увеличения.)
Проверка реализации
Плохо реализованное решение приведет к ненадежным результатам тестирования. Перед запуском A/B-теста важно сначала проверить решение на небольшой группе пользователей, чтобы убедиться, что оно работает так, как и ожидалось. Это могут быть внутренние тестировщики QA и/или выбранная группа внешних тестировщиков, которым вы доверяете давать конструктивную обратную связь.
Бегать
Медленно нарастает
Даже если решение проверено, все равно хорошей идеей будет постепенно наращивать темпы тестирования, начиная с небольшой группы пользователей. Благодаря этому ошибки или другие проблемы можно обнаружить на ранней стадии и быстро устранить, не затрагивая большой процент пользователей.
Полный тест
После того, как решение будет протестировано небольшой группой пользователей и все проблемы будут устранены, мы можем перейти к полному тесту A/B. Это не обязательно должно быть истинное разделение трафика 50/50, но оно должно быть сопоставимо по размеру со случайно выбранным набором реального использования.
Сбор метрик
Во время теста вы должны убедиться, что собраны соответствующие данные для поддержки вашей гипотезы. Вы можете использовать платформу A/B-тестирования во время этого процесса, чтобы облегчить сбор данных и последующий анализ. Платформа Google Карт также собирает метрики использования API, которые могут быть полезны, вы можете проверить эту страницу , чтобы узнать больше об использовании наших инструментов отчетности.
Ниже приведены некоторые предлагаемые показатели:
Автозаполнение места
Коэффициент конверсии: повысился ли коэффициент конверсии/заполнения вашей формы по сравнению с отсутствием решения по автозаполнению?
Взаимодействие с инструментами: больше ли пользователей успешно взаимодействуют с Place Autocomplete по сравнению с предыдущим решением?
Проверка адреса
Успешность доставки: произошло ли сокращение количества неудачных доставок из-за качества адресов?
Изменение адреса: Сократилось ли количество сборов за изменение адреса, которые вы получаете от курьеров?
Жилые и коммерческие помещения: произошло ли улучшение в сборе данных по жилым и коммерческим помещениям? ( только на некоторых рынках )
Анализировать
Теперь, когда тест окончен, пришло время проанализировать результаты в соответствии с первоначальными критериями и гипотезами теста. Если вы использовали платформу A/B-тестирования для завершения процесса, некоторая информация может быть вам уже доступна.
Возвращаясь к разделу Сокращение адресов низкого качества выше, вы также можете использовать другие метрики, которые могли не быть зафиксированы платформой тестирования A/B. Это может быть частота неудачных доставок между сценариями тестирования, с примерами данных, такими как этот:
| Решение А | Решение Б | |
|---|---|---|
| Неудачные поставки | 1,75% | 1,23% |
Рассматривая приведенный выше базовый пример, становится ясно, что для данного варианта использования лучшим выбором будет решение B.
Заключение
Мы надеемся, что это руководство дало вам достаточно информации, чтобы начать свой путь A/B-тестирования! Хотя в нем использовались примеры из сферы электронной коммерции, те же основные принципы можно применять везде. Определите успешный результат наличия качественных адресных данных в вашем бизнесе и отслеживайте это как свою основную гипотезу.
Мы снова включили ссылки, упомянутые в руководстве, ниже, как рекомендуемые для дальнейшего чтения.
Удачного тестирования!
Следующие шаги
Загрузите технический документ «Улучшение оформления заказа, доставки и операций с помощью надежных адресов» и просмотрите вебинар «Улучшение оформления заказа, доставки и операций с помощью проверки адресов» .
Рекомендуемая дополнительная литература:
- Проверка адреса для оформления заказа в электронной торговле
- Место автозаполнения документации
- Документация API проверки адреса
- Отчетность платформы Google Maps
Участники
Основные авторы:
Хенрик Валв | Инженер по решениям платформы Google Maps