应用场景

为目录收录核验商家地址

任何人都可以在提交表单里输入地址,但输入的地址并不都是真实的。一个允许商家自助提交列表的本地商家名录吃过这方面的苦头:不断有用户投诉,说他们开车到列出的地址,却发现那里什么都没有。有时是因为无心的笔误,偶尔则是有人恶意提交列表,想用虚假的本地存在来操纵搜索排名。

该名录在任何提交的列表上线前增加了一个验证步骤。提交的地址会发送到 /v1/forward,它尝试进行匹配并报告解析的置信度,区分干净的匹配、仅部分解析的匹配以及完全无法解析的情况。另外,表单中填写的邮政编码会通过 /v1/postcode 进行检查,确认它与表单中同样填写的城市和地区相符。这样就能捕获一种特定且出奇常见的情况:提交者从完全不同的地点复制了邮政编码,不管是出于失误还是故意。

未通过任一检查的提交并不会被自动拒绝,因为匹配度差并不等于地址是假的,很多合法商家的地址就是因为新建工程或偏僻的乡村位置而无法完美解析。相反,被标记的提交会进入人工审核队列,由工作人员在发布前快速看一眼,而不是让每一条提交都需要同样的人工关注,不管它有多干净。

这彻底改变了审核流程的经济账。在加入检查之前,每条提交都需要人工查看,因为不逐条手动检查就无法判断哪些可疑。加入检查之后,绝大多数提交(匹配干净、邮政编码与所填城市一致的那些)会自动发布,而工作人员的时间则专门用在少数确实需要的提交上,也就是验证步骤本身标记出来的那些。

该名录在内部明确说明了这种方法的局限。干净的地理编码匹配只能确认地址格式正确、在地理上真实存在。它不能确认有商家确实在那里经营,不能确认商家名称准确,也不能确认该列表没有在与地址字段无关的方面误导他人。验证步骤只处理信任问题中的一个部分,即地点本身是否存在、描述是否正确,其余一切仍由名录保留的其他审核措施负责。

调用量直接随提交量变化,对一个地区性名录来说数量不大且可预测,大多数月份都远在密钥附带的每日免费配额之内。仅凭减少的人工审核时间,这项改动就已经收回了成本许多倍,这还没算上一个以发布无效地址出名的名录所要付出的声誉代价。

两个端点的文档(包括匹配置信度的表示方式)见 /docs/forward-geocoding/ 和 /docs/postal-code-lookup/。