チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
地域ごとにサブスクリプションの価格を変える
どこでも同じ価格を請求することは、購買力や競争の状況が市場ごとに大きく異なることを無視しています。サブスクリプション製品を販売するあるソフトウェア会社は、一部の市場では価格を下げ、ほかの市場では据え置きたいと考えていました。よくある戦略ですが、それを実現するには、ページに価格が表示される前に、訪問者が実際にどの市場にいるのかを知る必要がありました。
最初に思いついたのは直接尋ねることでしたが、それは誤りでした。料金ページの国の選択欄は、所在地を偽って最も安い選択肢を探すよう促しているように見えますし、できるだけ手間をかけずに訪問者をチェックアウトボタンまで導くことが唯一の役割であるページに、判断を1つ増やしてしまいます。会社が望んでいたのは、正しい価格がただ表示されることでした。
解決策は、料金ページを返す前にサーバー側で実行されました。/v1/ipが訪問者のIPアドレスを受け取り、ほかのフィールドとともに国のフィールドを返し、料金ページはそれを使って表示する料金表を選びました。標準価格の市場からの訪問者には標準価格が表示され、会社が地域別料金を設定した市場からの訪問者にはその料金が表示されました。選択欄も、余分なクリックもなく、何かが判定されたという目に見える形跡もまったくありませんでした。
会社は判定された国を確定した事実ではなく出発点として扱いました。企業のVPNを使っている訪問者や海外旅行中の訪問者は、実際に適用されるべき料金とは異なる市場にいると判定される可能性があるからです。誰かを強制的にブロックするのではなく、顧客の実際の請求先の国がIPの示す国と一致しないまれなケースでは、サポートによる例外対応を認めるチェックアウトフローにしました。これはメインのフローに組み込むのではなく例外として処理されました。訪問者のごく一部にしか影響しない特殊なケースのために、料金ページに常に疑いを組み込んでしまうと、この変更全体が目指していた単純さが損なわれてしまうからです。
財務チームに直接伝えておくべき重要な点が1つありました。My Geocode自体は、提供しているすべての地域でユーロで請求しており、標準の無料割り当て、プリペイドクレジット、Unlimitedキー以外に独自の地域別料金はありません。これは、APIを利用する会社が自社製品に地域別料金を設定したいかどうかとは別の問題で、その判断は完全にAPIの上に築かれたビジネスに委ねられています。検索が提供するのは国の情報だけです。その情報を会社がどう使い、それに基づいてどう価格を設定するかは、その会社自身の判断です。
リクエスト量は料金ページの閲覧数に比例しました。ソフトウェア会社のサイトを訪れる人のほとんどは、その訪問で製品の価格を積極的に調べているわけではないため、通常はサイト全体のトラフィックのごく一部です。そのため、利用量は年間の大半で1日あたりの無料割り当ての範囲に十分収まり、製品の発売前後など料金ページのトラフィックが異常に多い時期にだけ、プリペイドクレジットに移行しました。
うまく設計された地域別料金は、仕組みとしては見えず、結果としては明らかであるべきです。最初の表示で正しい価格が示され、余分な手順はありません。エンドポイントのドキュメントは/docs/ipv4-lookup/と/docs/ipv6-lookup/にあり、API自体の料金の詳細は/pricing/にあります。