チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
チェックアウトページの項目が1つ増えるごとに、入力せずにカートを放棄する買い物客が一定の割合で発生し、小売業者はその分を失います。国の選択欄は小さな項目ですが、買い物客が最も離脱しやすい購入の段階で、判断を1つ増やすことになります。十数か国で販売しているあるオンライン小売業者は、この項目を完全になくすことにしました。
代わりに導入したのは、チェックアウトページの描画前に実行されるサーバー側の検索です。/v1/ipは訪問者のIPアドレスを受け取り、国、地域、都市、郵便番号、座標を返します。これらはすべて、買い物客をサイトに運んできたのと同じリクエストから読み取られます。小売業者は国のフィールドを使って配送先の国をあらかじめ選択し、提示する支払い方法を調整し、その市場で複数の言語が使える場合は表示言語を切り替えました。ストアが配送していない国の買い物客には、フォーム全体に入力した末に支払いの段階で行き詰まるのではなく、その旨のメッセージがすぐに表示されました。
これによって買い物客の選択肢が固定されたわけではありません。あらかじめ選択された国は変更可能でした。IPジオロケーションが反映するのはリクエスト元のネットワークであり、本人が使いたい請求先住所とは限らないからです。旅行中の人や、別の国を経由してトラフィックを送る企業ネットワークを使っている人の場合は特にそうです。判定された国を事実ではなく妥当な初期値として扱うことで、顧客が実際に住んでいる場所を信じようとしないチェックアウトページへの不満を避けられました。
小売業者は、同じ判定の上に価格設定を重ねました。特定の市場では、現地の購買力と配送コストに合わせて調整された価格が適用されました。これは商品企画チームが事前に決めたもので、検索で返された国のフィールドに応じて適用されるだけです。これはストアが自社の価格エンジンで行うビジネス上の判断であり、ジオロケーションの呼び出しが単独で決めるものではありません。ただし、そもそも実行するには信頼できる国の情報が必要でした。そしてサーバー側でそれを読み取ることで、買い物客に表示される価格が、改ざんされたり読み込みに失敗したりする可能性のあるクライアント側のスクリプトではなく、チェックアウトで実際に請求される価格と一致するようになりました。
検索はページビューごとではなくチェックアウトのセッションごとに1回実行されるため、売上が好調な月でもリクエスト量は控えめにとどまり、年間の大半は小売業者のキーに含まれる1日あたりの無料割り当ての範囲内に収まりました。季節的な繁忙期には、アカウントが一時的に1リクエストあたり€0.0001のプリペイドクレジットに移行しましたが、その費用は議論に値する項目として取り上げられることがないほど小さなものでした。
この変更全体で、フォームから項目が1つなくなり、誰にも見えないところで行われる検索に置き換わりました。買い物客が気づいたのは、サイトが自分の居場所をすでに知っているように見えることだけでした。これこそがこの種のパーソナライズの目的のすべてです。新しい機能ではなく、手間が減ったと感じられるべきなのです。フィールドの詳細と利用できる形式は/docs/ipv4-lookup/と/docs/ipv6-lookup/に記載されています。