チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
銀行向けの「最寄りの支店を探す」ツールを作る
都市名順に並べた40の支店住所の一覧は、自分のオフィスに一番近い支店を知りたい顧客には役に立ちません。ある地方銀行は何年もの間、まさにこのような一覧をウェブサイトに載せており、サポートチームには、事実上その並べ替えを電話で手作業で行ってほしいという問い合わせが絶えず寄せられていました。
これを解決するには、銀行が使える形ではまだ持っていなかった2つの位置データが必要でした。すべての支店の座標と、顧客自身の出発地点を知る方法です。支店の住所は、/v1/forwardに送る1回の一括処理で一度だけジオコーディングされました。一括リクエストでは各住所が1件の課金対象として数えられるからです。これにより、すべての支店に基準となる固定の緯度と経度が与えられました。テキストの住所だけで作られていた以前の一覧では、決して実現できなかったことです。
計算の顧客側については、銀行は2つの方法を用意しました。ページがおおよその位置を検出することを許可した顧客には、訪問者のIPアドレスを都市や地域とともに座標に解決する/v1/ipから位置が与えられ、何も尋ねることなく妥当な出発地点が得られました。住所の入力を好む顧客、たとえば現在地ではなく職場の近くで来店を予定している人によくあるケースでは、その住所が支店一覧に使ったのと同じ/v1/forwardの呼び出しでジオコーディングされ、同じ方法で支店一覧に対して順位付けされました。
両方に座標がそろえば、順位付けは単純な距離計算で、銀行自身のサイトが追加のサービスなしで処理しました。目に見える結果は、都市ごとにまとめられた40の住所をスクロールするのではなく、最も近い5つの拠点をそれぞれわかりやすい距離の数値とともに最初に表示する支店検索でした。
銀行であるため、チームはツールがどれだけ断定的に表示するかに注意を払いました。IPに基づく位置は近似値であり、出発地点としては役立ちますが正確ではありません。特にモバイルネットワークや企業のVPNを使っている顧客ではそうです。銀行の支店検索は、検出した位置を確実なものとして示すのではなく、常に最初の推測であると明示し、簡単に調整できるようにしました。これは気軽な店舗検索よりもここで重要でした。公証の予約のような用件で顧客を誤った支店に案内してしまうのは、誤ったコーヒーショップに案内するよりも大きな迷惑になるからです。
このツールのトラフィックは控えめで予測しやすく、訪問者のセッションごとに1〜2回の検索程度でした。支店検索のトラフィックを増やしたマーケティング施策の期間中でさえ、銀行のキーに含まれる1日あたりの無料枠に十分収まっていました。このプロジェクトによって、銀行は整った再利用可能な支店の座標も手に入れ、後に新支店の開設案内用に簡単な半径マップを描くなど、追加のジオコーディング作業なしで他の用途にも活用しました。
支店検索や店舗検索がジオコーディングのよくある用途の1つであるのは、まさにその効果が非常にわかりやすいからです。距離順に並べる実用的な検索は、明らかにそうでないものと比べて、顧客が使い始めて数秒で気づくものです。関連するエンドポイントのドキュメントは/docs/forward-geocoding/と/docs/ipv4-lookup/にあります。