參考數據同數據增值
三千四百萬行數據，作為一個步驟
國家、語言同貨幣。1,340 萬個有人居住嘅地方同地理特徵。1,900 萬個名稱變體。200 萬個郵遞區號。機場、海港、汽車品牌。65 個端點，唔使認證，冇收費表，因為佢就係你個工作流程已經喺上面運行嘅同一個平台。
點解呢樣嘢唔尋常
喺其他所有自動化工具度，「驗證呢個地址」係一個要俾錢嘅第三方整合。你要搵供應商、開戶口、傾收費表、攞 API key、儲起個 key、監察配額，用量變咗仲要重新傾價。查詢本身要二十毫秒；採購就要兩個禮拜。
喺呢度，佢只係選擇器入面嘅一個步驟。呢啲係公開參考數據 — GeoNames、官方代碼表、已發布嘅登記冊 — 由 castomAPI 清理、建立索引同提供服務。佢存在嘅原因係呢個系列入面十幾個產品都需要同樣嘅嘢，起一次平過起十二次。
搜尋係用 trigram 嘅,最少要三個字元,所以打少咗個名或者串錯字都搵到位。呢個下限係刻意嘅:兩個字元會中晒所有嘢,而一個乜都中嘅查詢,仲衰過查唔到。
人哋用佢做嘅三件事
驗證 — 喺門口就擋住爛數據。呢個郵政編碼真係屬於嗰個城市?呢個國家代碼係咪存在,定係某人喺2019年打錯咗、之後一直傳落去嘅錯字?PLN係咪一種貨幣,同埋係咪應該用嚟向呢個客收錢嗰種?
標準化 — 「Warsaw」、「Warszawa」、「Varsovie」同「Варшава」其實係同一個地方、同一個識別碼。一千九百萬個名稱變體喺度,你嘅客戶資料庫就唔使儲四個串法仲扮係四個城市。
豐富 — 一個城市名變成座標、時區、行政區同人口數字。一個機場代碼變成名稱同位置。一個郵政編碼變成佢之上成個層級嘅嘢。本來要人手打嘅六個欄位,二十毫秒就填好晒,唔使錢。
時區係嗰個唔出聲嘅主角
解析一個地方就會攞到佢嘅時區,而時區就係令「朝早九點發送」變成收件人嗰邊嘅朝早九點,而唔係你嗰邊嘅朝早九點。靜音時段、時間表同提醒,成個國際名單都自動啱晒,唔使有人去維護一張對照表。
- 1輸入「ul. Powstańców Śląskich 5, 53-332 Wrocław, PL」
- 2郵遞區號已配對53-332 → Wrocław、Dolnośląskie、PL。
- 3地點已解析51.0938 N, 17.0226 E · Europe/Warsaw · 人口 674 079。
- 4寫返入去自動填咗六個欄位，唔使人手逐個打。
- §費用決定性步驟。唔使 key、冇配額、冇每次查詢收費。
用咗:40 毫秒有 65 個端點可用
三千四百萬行數據。一步搞掂。
實例示範
佢喺邊度發圍
喺快遞公司見到之前
喺買運喺標籤之前,地址已經驗證同標準化好。一張被退回嘅標籤要畀手續費又蝕一日;一個被退回嘅郵政編碼只係二十毫秒。
喺會計見到之前
喺開發票之前,貨幣代碼同國家代碼已經驗證好,比起寄咗出去先驗平好多。
為名單去重
同一個客、同一個城市兩個串法嘅兩條記錄,只要兩個城市解析到同一個識別碼,就可以正確合併。
按地理分派路線
客戶嘅座標加你各倉庫嘅座標,系統就會揀最近嗰個,唔使有人維護一張郵編對倉庫嘅試算表。
語言,啱啱好
一個國家會解析出佢嘅語言,所以發出去嘅訊息會係收件人大概睇得明嗰種 — 由數據決定,而唔係靠睇國旗估。
車隊同物流
車輛品牌、機場同海港都有標準記錄,畀啲工作流程要處理實物移動嘅用。
講真嘅限制
呢個係公開參考數據,唔係商業地址驗證服務。佢會話你知 53-332 係 Wrocław 一個真實郵政編碼,同埋畀你嗰個地點嘅座標。但佢唔會話你知 5 號樓有冇 212 室,或者有冇人住喺度。要驗證到派遞點層面,你要用國家郵政營運商嘅產品,而工作流程可以喺呢個之餘用 HTTP 去呼叫佢。
佢亦都唔係個人資料來源。入面冇任何人。佢只有地方、代碼、名冊同公開事實 — 亦正正因為咁,佢可以唔使認證就提供服務。
關於時效:參考數據變得慢,呢個係按時間表更新,唔係即時。一條新改咗名嘅村,唔會同日下午就出現。啲每個鐘都會變嘅嘢,你應該用事件推送,佢就係為呢樣嘢而設。