在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
根据海拔数据构建徒步路线难度评级
仅凭距离来评定一次徒步的实际难度，并不是好办法。一条沿河岸的六英里平坦路线和一条攀登山峰的六英里路线，在一款路线指南应用的目录中都被标为“中等，六英里”，这种分类引来了源源不断的投诉，因为相信“中等”评级的徒步者发现自己走上了一段远比预想困难的攀登。
该应用已经把每条路线存储为描绘其路径的一串坐标，这些坐标来自贡献者提交的 GPS 记录。它缺少的是沿路径的海拔，正是这项数据才能在相同距离下区分平坦的散步和真正的攀登。/v1/elevation 接收一条路线的完整坐标列表（因为批量请求接受一个点列表并为每个点返回海拔），应用由此获得了记录路径上每个点的海拔值，顺序与提交时相同。
根据这份列表计算总爬升（即路线上每一次向上变化的总和）只是简单的算术，由应用自己的后端完成。总爬升与距离相结合，产生了比单纯距离真正有用得多的难度信号：短距离内爬升大的路线，无论在纸面上看起来多短，都被评为陡峭困难；而长而平坦的路线，尽管距离长，却被评为较容易，这比旧的仅按距离评定的系统更贴近徒步者在实地的真实体验。
该应用围绕这一综合数值重建了难度评级，并追溯重新计算了目录中已有的每条路线，这是一次覆盖整个路线库的一次性批量作业。这批请求是该应用发送过的最大的一次请求，而且由于批量海拔请求中每个点（而不是每条路线）计为一个计费项，作业的确切规模取决于整个路线库中有多少个坐标点，而不是路线的数量，团队在事先估算费用时就考虑到了这一点，而不是事后才感到意外。
除了醒目的难度评级之外，同样的海拔数据还让应用能在每个路线页面上显示爬升剖面图，类似于骑行应用所显示的那种，使徒步者能准确看到陡峭路段位于路线的哪些位置，而不只是知道一个总体难度标签。对于想为某段特别艰难的路段做准备、而不只是知道路线整体很难的徒步者来说，这张图比单独的标签更有用。
初始批量作业之后的持续海拔查询由新提交的路线驱动，其请求量比一次性的重新计算项目小得多，也更平稳，按该应用贡献者通常的新提交速度，轻松落在每天的免费配额之内。
评级系统的好坏取决于其背后的数据，而海拔正是该应用难度评级一直缺少的输入。该端点的文档（包括每个请求的点数限制）位于 /docs/elevation-lookup/。