チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
標高データからハイキングコースの難易度評価を作る
距離だけでは、ハイキングが実際にどれほど大変かを評価する方法として不十分です。川沿いの平坦な6マイルのコースと、山を登る6マイルのコースが、あるトレイルガイドアプリの一覧ではどちらも同じ「中級、6マイル」という表示になっていました。この分類は、中級という評価を信じたところ、準備していたよりはるかに厳しい登りに直面したハイカーからの苦情を絶えず生んでいました。
アプリはすでに、投稿者から寄せられたGPS記録をもとに、各コースを経路をたどる座標の列として保存していました。欠けていたのは、その経路に沿った標高、つまり同じ距離の平坦な散歩と本格的な登山を実際に区別するデータでした。一括リクエストは地点のリストを受け付け、それぞれの標高を返すため、/v1/elevationにコースの座標の全リストを渡すと、アプリは記録された経路上のすべての地点の標高値を、送信したときと同じ順序で受け取りました。
そのリストから累積標高、つまりルート上のすべての上り方向の変化の合計を計算するのは、アプリ自身のバックエンドが処理する単純な計算でした。累積標高を距離と組み合わせると、距離だけよりもはるかに有用な難易度のシグナルが得られました。短い距離で累積標高が大きいコースは、書面上でどれだけ短く見えても急で難しいと評価され、長く平坦なコースは長さのわりに易しいと評価されました。これは、以前の距離だけのシステムよりもはるかに、ハイカーが現地で実際に体験することに近いものでした。
アプリはこの組み合わせた数値を軸に難易度評価を作り直し、すでに一覧にあるすべてのコースについて、コースライブラリ全体を対象とする一度きりの一括処理でさかのぼって再計算しました。この一括処理は、アプリがこれまでに送った中で最大のリクエストでした。一括の標高リクエストはコースごとではなく地点ごとに1件の課金対象として数えられるため、作業の正確な規模はコースの数ではなく、ライブラリ全体に存在する座標点の数に比例しました。チームはこの点を、後から驚くのではなく、事前に費用を見積もる際に考慮に入れていました。
目玉の難易度評価に加えて、同じ標高データを使って、アプリはサイクリングアプリで見られるような登りのプロファイルグラフをすべてのコースページに表示できるようになりました。ハイカーは、全体の難易度の表示だけでなく、ルートのどこに急な区間があるかを正確に確認できます。コース全体が難しいと知るだけでなく、特定の厳しい区間に備えたいハイカーにとっては、表示単体よりもグラフのほうが役立ちました。
最初の一括処理の後の継続的な標高検索は、新しいコースの投稿によって発生するもので、一度きりの再計算プロジェクトよりはるかに少なく安定した量でした。アプリへの新規投稿の通常のペースであれば、1日あたりの無料枠に余裕で収まりました。
評価システムの質は、その土台となるデータの質で決まります。そして標高こそが、アプリの難易度評価にずっと欠けていた入力だったことがわかりました。リクエストあたりの地点数の上限を含むエンドポイントのドキュメントは/docs/elevation-lookup/にあります。