在结账前核对地址与所填邮政编码是否一致
订单表单上邮政编码与城市不一致，看起来只是个小笔误，直到包裹被送到国内完全不同的地方。
构建一款从访客所在位置开始的天气应用
天气应用能给人留下的最糟糕的第一印象就是一个空白的搜索框。访客打开页面，想知道今天会不会下雨，得到的却不是答案，而是一个要求先输入城市名称的提示，为了应用本应能够合理推测出的信息而多出一个步骤。
一款天气应用解决这个问题的方法是：在页面加载的那一刻、渲染任何内容之前，在服务器端确定一个大致的起始位置。/v1/ip 接收访客的 IP 地址，返回坐标以及城市和地区，让应用立即拥有一个可以请求天气预报的位置。天气预报本身来自该应用自己的天气数据提供商，以这些坐标作为输入，因此位置查询和天气数据是协同工作的两个独立部分，而不是由一个服务同时承担两项工作。
该应用把检测到的城市当作访客随时可以更正的初始猜测，因为基于 IP 的定位确实有局限：它反映的是连接所来自的网络，通常接近访客的实际位置，但有时会有偏差，尤其是在移动运营商网络上，IP 可能被解析到某个区域枢纽，而不是访客所在的具体城镇。在检测到的城市旁边，就有一个清晰可见的入口用于搜索其他城市，因此纠正错误的猜测只需点击一下，而不会让人觉得应用出了问题。
这个小改动让应用最重要的数字，也就是访客所在地区的今日天气预报，从访客需要主动请求的内容变成了页面加载完成时就已显示在屏幕上的内容。对天气应用而言，其全部价值就在于尽快给出用户想要的答案，因此在“这里天气怎么样”这一常见场景中省去搜索步骤，比该应用当年发布的几乎任何其他功能都更重要。
该应用还根据解析出的地区决定默认显示的单位，因为在使用摄氏度的国家被检测到的访客，与在使用华氏度的国家被检测到的访客，对“72 度”的含义有不同的预期。首次加载时就选对默认单位，可以省去大多数访客根本懒得去做的设置查找，否则他们会悄悄离开，对天气预报留下错误的印象。
每次页面加载都会触发一次查询，对于有一定流量的应用来说，这会很快超出每日免费配额，进入预付额度或 Unlimited 密钥的范围，具体取决于应用的流量模式有多可预测。对于天气应用，流量在暴风雨和异常天气前后出了名地剧烈波动，而恰恰在这种时候，Unlimited 密钥固定的月费比可能在应用最需要发挥作用时突然上涨的可变预付账单更容易规划。
让第一屏无需任何输入就显示正确内容，是一个小小的技术决策，却决定了整个应用给人的感觉。该端点的文档位于 /docs/ipv4-lookup/ 和 /docs/ipv6-lookup/，额度和 Unlimited 两种方案的价格见 /pricing/。