My Geocode

ガイド

訪問者のタイムゾーンを初期値にするタイムゾーン選択を作る

· 3分で読めます · My Geocode · #タイムゾーン#IP検索#フォーム#UX

タイムゾーン名の一覧をスクロールして自分のものを探すのは小さな手間ですが、適切な初期値があれば、ほぼすべての人にとってその手間はなくなります。

タイムゾーンを検出する

/v1/ipエンドポイントはtimezoneフィールドを直接返すため、タイムゾーンのエンドポイントを別途呼び出さなくても、1回の呼び出しで所在地とタイムゾーン識別子の両方を取得できます。

GET /v1/ip?ip=203.0.113.88
{
  "status": "ok",
  "ip": "203.0.113.88",
  "version": 4,
  "found": true,
  "country": "Australia",
  "country_code": "AU",
  "region": "New South Wales",
  "city": "Sydney",
  "postcode": "2000",
  "lat": -33.8688,
  "lon": 151.2093,
  "timezone": "Australia/Sydney",
  "asn": 7890,
  "org": "Example Networks"
}

選択肢を事前に選んでおく

このレスポンスのtimezoneの値を、設定フォームが最初にレンダリングされる時点で、ページが訪問者に届く前にサーバー側で選択済みの項目として設定します。事前に選択する値は例にあるような標準的な識別子の文字列にすぎないため、選択欄が標準のタイムゾーン識別子のドロップダウンでも検索可能なリストでも、同じように機能します。

2つ目の例：1件の予約に複数の人がいる場合

複数の旅行者の情報を集める旅行やイベントの予約フォームでは、フォームに入力している人のタイムゾーンを一度だけ検出し、旅行者ごとに検索し直すのではなく、それをすべての旅行者の共通の初期値として適用すると便利です。団体予約には、フォームに入力している人とは別のタイムゾーンから参加する人が含まれることが多いため、各旅行者の欄は個別に変更できるようにしておきます。

訪問者が変更できるようにする

タイムゾーン選択が存在するのは、まさにIPに基づく検出が常に正しいとは限らないからです。特にVPNを使っている訪問者や旅行中の訪問者ではそうです。欄は必ず変更可能にしておき、検出した初期値よりも訪問者が明示的に選んだものを保存し、次回の訪問時に再検出して選択を上書きしないでください。

避けるべきよくある間違い

例として試した検索でたまたまきれいな識別子が1つだけ表示されたからといって、大きな国が単一のタイムゾーンに対応すると考えないでください。複数のタイムゾーンにまたがる国では、訪問者の実際の所在地に合った特定のタイムゾーンが返されます。これこそがIPに基づく検出を国レベルの推測より有用にしている点ですが、それはフォームが国全体に単一の初期タイムゾーンを当てはめるのではなく、返された特定の識別子を信頼する場合に限られます。

訪問のたびではなく一度だけ検出する

検出は、訪問者が初めてアカウントや設定を行うときに一度だけ実行し、その結果を保存します。ログインのたびに実行し直しても、価値を生まずにリクエストを無駄にするだけです。訪問者が意図的に設定したタイムゾーンは、本人が変更しない限りそのまま保たれるべきだからです。

訪問者が入力した配送先住所のように、IPアドレスではなく特定の座標がすでにある場合は、/v1/timezoneが緯度と経度から直接タイムゾーンを解決します。特定のタイムスタンプを指定することもできるため、現在ではなく特定の時点で適用されていたタイムゾーンを知る必要がある場合に便利です。

コスト

新規アカウントまたは設定1件につき検索1回で、1リクエストです。毎日新しいユーザーが次々と登録するサービスでも、この機能だけであれば、すべてのキーに含まれる、またはキーなしで1つのアドレスから利用できる1日あたりの無料リクエスト2,500件の範囲に十分収まります。

適切な初期値を検出したら、あとは邪魔をしない。これがタイムゾーン選択にとって正しいバランスです。フィールドの詳細はIPv4検索のドキュメントとタイムゾーン検索のドキュメントに掲載しています。

ガイドのその他の記事

· 4分で読めます

住所と郵便番号を照合する

住所と郵便番号をそれぞれ個別に解決して実際に示す内容を比較することで、注文の発送前に番地と郵便番号の不一致を見つけます。