在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
为跑步应用构建路线海拔图
规划路线的跑者很在意坡度，而这很难仅凭平面地图判断，因为同样距离的两条路线，根据其中包含多少爬升，跑起来的感受可能完全不同。一款跑步应用的功能需求板上，有一项在榜首附近停留了好几个月：在跑者决定跑一条计划路线之前，先显示它的海拔剖面图。
该应用的路线功能已经能生成描述一次计划跑步的坐标序列，它根据起点、终点以及应用自身沿真实街道和步道的寻路逻辑生成。缺少的是路径上每个点的海拔数据。/v1/elevation 直接填补了这一空白：在一个请求中发送的坐标列表，会以相同顺序返回一份对应的海拔值列表，可以直接根据跑者沿路线的累计距离绘制图表。
由此得到的海拔与距离关系图，正好给了跑者这项功能需求所要求的东西：清楚地看到计划路线上的爬坡位于何处，每段爬坡相对于路线其余部分看起来有多陡，以及一个总爬升数值，它与距离和预计配速一起，成为应用中每条已保存路线显示的主要数字之一。
在这里，采样密度对控制成本很重要，这与骑行应用处理同一问题的方式类似。一段社区附近的短跑需要相当频繁地采样海拔，才能生成平滑、看起来准确的图表；而较长的路线可以使用较粗的采样间隔，跑者扫一眼时并不会觉得图表有明显不同。由于批量海拔请求中每个点计为一个计费项，应用的工程团队专门按路线长度调整采样间隔，以免请求的点数远远超过图表视觉分辨率实际所需。
该应用在同样的数据之上又增加了一个小功能：已保存路线上的“爬坡难度”徽章，根据总爬升相对于距离计算得出，让跑者无需逐一阅读完整图表，就能快速比较两条长度相近的路线。这在思路上类似于徒步应用用同样的底层计算来评定路线难度，只是针对典型跑步较短的距离和不同的配速预期，而不是徒步，进行了调整。
功能上线后，用户对已保存路线的参与度有所提高，应用团队将此具体归因于：跑者一旦能看到一条陌生路线在爬升方面究竟意味着什么，就更有信心去跑它，而不是在第一次跑到半路时才发现路线的难度。
海拔查询按每条已保存路线运行一次，而不是每次跑步都运行，因为一条路线的海拔剖面在每次跑步之间不会改变，这使总请求量与用户创建的不同路线数量成正比，而不是与应用的总使用量成正比，对于活跃用户规模中等的应用，轻松落在每天的免费配额之内。
该端点的文档（包括每个请求的点数限制）位于 /docs/elevation-lookup/。