チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
訪問者の現在地から始まる天気アプリを作る
天気アプリが与えうる最悪の第一印象は、空の検索ボックスです。訪問者は今日雨が降るかどうかを知りたくてページを開いたのに、答えの代わりに、まず都市名を入力するよう求められます。アプリが本来ある程度推測できてしかるべき情報のために、余計な手順を踏まされるわけです。
ある天気アプリは、ページが読み込まれた瞬間に、何かを描画する前にサーバー側でおおよその初期位置を特定することで、この問題に対処しました。/v1/ip が訪問者のIPアドレスを受け取り、都市や地域とともに座標を返すので、アプリはすぐに天気予報をリクエストする位置を得られます。予報そのものは、その座標を入力として、アプリ独自の気象データプロバイダーから取得しました。つまり位置の検索と気象データは、1つのサービスが両方の役割を担おうとするのではなく、2つの独立した部品が連携して動く形になっていました。
アプリは検出した都市を、訪問者がいつでも修正できる初期推定として扱いました。IPベースの位置情報には現実的な限界があるためです。IPが反映するのは接続元のネットワークであり、通常は訪問者の実際の位置に近いものの、ずれることもあります。特にモバイルキャリアのネットワークでは、IPが訪問者のいる正確な町ではなく地域のハブに解決されることがあります。検出された都市のすぐ隣に、別の都市を検索する方法をはっきり見える形で配置したため、推定が外れていても修正はワンクリックで済み、アプリが失敗したような印象を与えませんでした。
この小さな変更によって、アプリにとって最も重要な情報である訪問者自身の地域の今日の天気予報は、訪問者が自分で求めなければならないものから、ページの読み込みが終わった時点ですでに画面に表示されているものへと変わりました。天気アプリの場合、価値のすべては知りたい答えにどれだけ早くたどり着けるかにあります。そのため「今ここの天気はどうか」というよくあるケースで検索の手順をなくしたことは、その年にアプリがリリースしたほぼどの機能よりも大きな意味を持ちました。
アプリは特定した地域をもとに、デフォルトで表示する単位も決めました。摂氏を使う国で検出された訪問者と、華氏を使う国で検出された訪問者とでは、「72度」が何を意味するかについての期待が異なるからです。最初の読み込みでデフォルトの単位を正しく設定しておくことで、訪問者が設定を探し回る手間を省けました。ほとんどの訪問者はわざわざそんなことはせず、天気予報について誤った印象を抱いたまま黙って去っていたはずです。
ページが読み込まれるたびに1回の検索が発生するため、ある程度のトラフィックがあるアプリではかなり早く1日あたりの無料割り当てを超え、アプリのトラフィックパターンの予測しやすさに応じて、プリペイドクレジットかUnlimitedキーのどちらかを利用することになります。天気アプリのトラフィックは、嵐や異常気象のときに急増することでよく知られています。まさにそうした場面では、アプリが最も力を発揮すべきときに跳ね上がるかもしれない変動制のプリペイド請求よりも、Unlimitedキーの定額の月額料金のほうが計画を立てやすくなります。
入力不要で最初の画面を正しく表示することは、小さな技術的判断ですが、アプリ全体の印象を左右します。このエンドポイントのドキュメントは /docs/ipv4-lookup/ と /docs/ipv6-lookup/ に、クレジットとUnlimitedの両方の料金は /pricing/ にあります。