A/B Testing を使用した Address Validation の影響の測定

このドキュメントでは、Google Maps Platform の Place Autocomplete API と Address Validation API の A/B テストを実施する際に考慮すべき手法について説明します。

Place Autocomplete と Address Validation API を使用するメリットには、次のようなものがあります。

  • カスタマー エクスペリエンスの向上: 住所や場所の候補がリアルタイムで提示されるため、ユーザーは購入手続きをよりすばやく簡単に行うことができます。これはカスタマー エクスペリエンスの向上につながります。
  • データの精度の向上: Place Autocomplete と Address Validation API を使用すると、顧客データの精度を高めることができます。これは e コマースでは特に重要です。荷物を配送するには正確な住所データが必要となるからです。

住所の品質を高めるには、A/B テストを実施して、ニーズに最も適した検証ソリューションを評価します。これにより、ユースケースに最適なプロダクトを定量的に決定できます。

A/B テストは、ウェブページやアプリの 2 つのバージョンを比較する方法です。変数の変更が測定可能な結果に与える影響を判定するために使用する、対照テストの一種です。
A/B テストを行うには、ページまたはアプリの 2 つのバージョンを作成します。一方はコントロール用、もう一方は測定可能な変化を持たせます。その後、これらのバージョンをさまざまなユーザーに表示し、ユーザーがどのように反応するかを測定します。パフォーマンスの高い方のほうが優先されます。

システム アーキテクチャの概要

では、e コマースのユースケースで Address Validation の A/B テストを見てみましょう。以下のアーキテクチャ図は、顧客がコマース エクスペリエンスとどのようにやり取りするかを示しています。これにより、より効果的な検証戦略を決定できます。

[システム コンテキスト] A/B Testing における住所確認

Address Validation API の値の A/B テストを行う際に使用するシステム。

このアーキテクチャ図は、e コマース ウェブサイトで A/B テストシステムを操作している顧客を示しています。e コマース ショップのソフトウェア システムから、顧客にどのテスト変数を表示するかは、このシステムによって決まります。e コマース ショップが Google Maps Platform ソフトウェア システムに対して API 呼び出しを行います。また、分析ソフトウェア システムによって処理され、A/B テスト システムに報告される A/B テスト分析も収集します。

A/B テストのプロセス

A/B テストのプロセス全体は、次の 4 つの段階を考慮します。

  • 準備 - テストの要件、範囲、期間を特定します。
  • 構築 - テストを実行する環境に Place Autocomplete API と Address Validation API を実装します。
  • [Run] - 有意な結果が得られるか期限が切れるまで、テストの実行中に指標を収集します。
  • 分析 - 結果を仮説と比較し、次のステップを特定します。

それぞれについて順番に説明します。

準備

A/B テストの要件の決定

初期検出

次の点を確認してください。住所確認プロバイダを追加または変更する理由は何ですか?たとえば、Google マップの Places Autocomplete を使用すると、次のようになります。

  • 時間の節約: 場所の名前全体を入力しなくても、入力を始めるだけで候補が表示されます。
  • エラーの削減: 場所の名前をスペルミスした場合でも、Google マップの Places Autocomplete によって正しい場所が提案されます。

検証に対処すると、次のような多くのメリットがあります。

  • 配送率の向上: 住所確認を利用すると、郵便物と荷物が正しい住所に確実に配送されるため、配送率の向上につながります。これにより、ビジネスの時間と費用を節約し、顧客満足度を向上させることができます。
  • データ品質の改善: 住所検証は、住所のエラーを特定して修正することで、データ品質の改善に役立ちます。これにより、マーケティング キャンペーンやその他のデータドリブンの取り組みの精度が向上します。

仮説の決定

テストする仮説を決定する。例を 2 つ紹介します。

1. コンバージョン率

タイプ予測ソリューションを追加すると、通常、コンバージョン率がわずかに上昇するため、これはトラッキングに適した指標です。別のプロバイダからタイプ予測ソリューションを変更する場合は、固定のコンバージョン率が見込まれます。コンバージョン率が低下した場合は、まず導入状況を確認します。

コンバージョン率は重要ですが、全体像を把握することはできません。住所確認ソリューションを追加することは、ユーザーが住所を入力する際に質の低い住所を送信しないようにすることを目的としています。また、状況によっては、住所の取得に多少の負担が加わる可能性があります。これにより全体的なコンバージョン率が低下する可能性がありますが、必ずしも悪いわけではありません。住所確認機能の追加により未完了の注文が住所データの質が低いため、配送料のチャージバックによりビジネスに損害が生じている可能性があります。

2. 低品質の住所の削減

ここで、優れた住所検証ソリューションが威力を発揮します。Address Validation を実装することで、低品質の住所データが削減されることが見込まれます。

新しいソリューションと既存のソリューションを比較する場合、「優れた住所」のマッチ率を比較し、マッチ率が高いサービスを選択したくなるかもしれません。一方のサービスが他方のサービスよりも誤検出の数が多いため、この判断は誤解を招きかねません。

その代わり、より効果的な指標は、住所データを使用した場合の成果を比べることです。e コマースの場合を例にとると、住所を取得することで、最終的に荷物の配送が成功するという結果が得られます。

ビルド

ここからが面白いところです。お客様のために新しいソリューションを構築しましょう。e コマースの購入手続きに Place AutocompleteAddress Validation API を実装するには、便利なガイドがすでに用意されています。この手順を行う際は、この確認を行うことをおすすめします。

e コマース専用に構築していない場合でも、多くの情報、特に Address Validation API の出力から住所の品質を判断するためのガイダンスは重要です。

アーキテクチャ図

e コマース環境で A/B テストを作成するために使用できるコンテナの例を以下に示します。

[実行環境] A/B Testing で住所確認を行う

主要なシステムにある重要なアプリケーション、サービス、データストアがアーキテクチャの基盤となります。(クリックして拡大)

アーキテクチャ図は、A/B テスト ソフトウェア システムを構成するコンテナと、e コマース アプリ ソフトウェア システムを示しています。この図には、e コマース ウェブサイトにユーザーがアクセスし、ロードバランサを操作する様子が示されています。ユーザーはロードバランサを使用して、e コマース ウェブサイト アプリに誘導されます。A/B テスト マネージャーはロードバランサと通信して、ユーザーに表示する A/B テスト変数を選択します。この A/B テストシステムは、A/B テストの結果と構成を任意のデータベースに記録します。e コマース ウェブアプリは、Google Maps Platform ソフトウェア システムの API 呼び出しを行います。また、アナリティクス ソフトウェア システムに分析イベントを報告します。アナリティクス ソフトウェア システムは、テストイベントを A/B テストの結果データベースに記録します。

実装を検証する

ソリューションを適切に実装しないと、テストの結果が信頼できません。A/B テストを実行する前に、まず少人数のユーザー グループでソリューションを検証し、意図したとおりに機能するかどうか確認することが重要です。内部の QA テスター、または建設的なフィードバックを提供してくれる信頼できる外部のテスターを指定できます。

ランニング

徐々に増やす

ソリューションが検証されたとしても、少人数のユーザー グループから徐々にテストを拡大することをおすすめします。これにより、多くのユーザーに影響を与えることなく、バグやその他の問題を早期に発見して迅速に対処できます。

完全なテスト

少人数のユーザー グループでソリューションをテストし、問題が解消されたら、完全な A/B テストを開始できます。これは必ずしもトラフィックの 50/50 の実際の分割である必要はありませんが、ランダムに選択されたライブ使用量のセットとサイズを比較できる必要があります。

指標のキャプチャ

テストでは、仮説を裏付ける適切なデータが取り込まれていることを確認する必要があります。このプロセス中に A/B テスト プラットフォームを使用すると、データ収集と後の分析が容易になります。Google Maps Platform では、有用な API 使用状況の指標も収集されます。Google のレポートツールの使用方法について詳しくは、こちらのページをご確認ください。

推奨される指標は次のとおりです。

Place Autocomplete

コンバージョン率: 以前は予測入力ソリューションを使用しなかったときと比べて、フォームのコンバージョン率や完了率は向上しましたか?
ツールの操作: 以前のソリューションと比較して、Place Autocomplete を操作しているユーザーは増えたか。

Address Validation

配達成功: 住所の品質に起因する配送失敗が減少しましたか?
住所の変更: 配送業者から受け取る住所変更料金の件数は減少しましたか?
住宅と商業施設: 住宅と商業施設のデータの取得において改善はありましたか。(一部の市場のみ

分析

テストが終了したので、元のテストの基準と仮説に照らして結果を分析します。A/B テスト プラットフォームを使用してプロセスを完了した場合は、一部の情報がすでに取得されていることがあります。

低品質の住所の削減」のセクションに戻り、A/B テスト プラットフォームで取得されなかった他の指標を使用することもできます。テストシナリオ間の配信の失敗率などが考えられます。データの例を以下に示します。

解決策 A 解決策 B
配達失敗 1.75% 1.23%

上の基本的な例を見ると、このユースケースにはソリューション B の方が適していることは明らかです。

おわりに

このガイドが、A/B テストを始めるにあたってお役に立てば幸いです。ここでは e コマース分野の例を取り上げましたが、同じ基本原則をあらゆる分野に適用できます。ビジネスの住所データの質が高いことによる成果を特定し、それを主な仮説としてトラッキングします。

参考資料として、ガイドの中でも言及されているリンクを以下に記載します。

ぜひテストを行ってください。

次のステップ

ホワイトペーパー「Optimizing checkout, delivery, and operations with フルアライズ 」ホワイトペーパーをダウンロードし、Address Validation による購入手続き、配達、運用の改善 ウェブセミナーをご覧ください。

関連資料の候補:

協力者

主要な著者:

Henrik Valve | Google Maps Platform ソリューション エンジニア