チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
料金計算ツールに現地通貨の表示を追加する
訪問者が使っていない通貨で表示された価格は、意味を持つまでに頭の中でもう一手間が必要な価格です。料金ページに計算ツールを置いて従量制の製品を販売していたあるソフトウェアベンダーは、自国市場以外からの訪問者が計算ツールのページに明らかに長く滞在し、コンバージョン率も低いことに気づきました。チームが掘り下げたところ、このパターンの原因はまさにその余分な手間でした。
解決策は、計算した価格を訪問者が日常的に実際に使っている通貨で表示し、希望する人のためにベンダーの基準通貨も併記することでした。最初にどの通貨を表示するかの判定は、料金計算ツールのページをレンダリングする前に、訪問者のIPアドレスから/v1/ipを使ってサーバー側で国を解決することから始まりました。ベンダーは、国から表示通貨への小さな対応表と、定期的に更新するおおよその換算レートを独自に管理し、検索結果のcountryフィールドを使って初期値として表示する通貨を決めました。
何が変わり、何が変わらなかったのかを正確にしておく価値があります。My Geocode自体は、APIを利用する顧客の所在地にかかわらず、世界中でEURで料金を設定し請求しています。これは、APIの上に構築されたビジネスが自社の顧客にどの通貨を表示するかとは関係のない事柄です。訪問者の現地通貨で価格を表示するというベンダーの判断は、検索結果の国の情報を入力として使った、完全にベンダー自身の料金設定とローカライズの選択であり、位置情報APIが決めたことでも、国を解決する以上に関わったことでもありません。
ベンダーは、換算した価格が参考のためのおおよその換算であることを明確に表示するよう注意しました。実際の請求は引き続きベンダー自身の基準通貨で行われ、為替レートは変動するためです。つまり、料金ページに表示される数値は役に立つ見積もりであり、実際の決済代行業者で通貨換算が行われたときの具体的な請求額を確約するものではありませんでした。この区別は、実際にいくら請求されるのかについて顧客が混乱しないよう、計算ツールの近くに小さな注記としてページ上で直接明示するほど重要でした。
訪問者は希望すれば1回のクリックで基準通貨に戻すことができました。これは、換算した見積もりではなく実際の請求通貨を直接見たい、製品を評価中の経理チームに便利でした。ベンダーはこの切り替えを目立たない場所に隠すのではなく、目立つ位置に置きました。ローカライズした表示を強制して実際の請求通貨を見られないようにすると、慎重に予算を比較している可能性が最も高い購入者にとって、それ自体が別の種類の摩擦になっていたはずだからです。
料金ページのトラフィックはベンダーのサイト全体の訪問数のごく一部だったため、ほとんどの月で1日の無料の割り当ての範囲内に十分収まりました。製品のリリースやマーケティングキャンペーンで料金ページのトラフィックが異常に多くなったときには、ときどきプリペイドクレジットにはみ出すことがありました。
基になる検索のドキュメントは/docs/ipv4-lookup/と/docs/ipv6-lookup/にあり、My Geocode自体の料金の詳細は/pricing/にあります。