If you know, you know. 🤯 Real-world address data is chaotic, inconsistent, and notoriously difficult to manage at scale. Trying to manage this internally is a massive drain on resources. Don't let bad addresses slow you down. Address data is a mess. We fix it.

Most last-mile problems don’t start in routing. They start earlier at the address. Addresses are text. Deliveries happen in physical space. Turning address text into structured intelligence is what makes last-mile operations truly scalable.

Ok, I’ll admit it: You don’t need normalization… At least not for all addresses. Yes, I know I’m one of the biggest proposers of address normalization around here, and I still believe and can prove that address normalization is one of the most important things you need to do if you want to improve many of the most important KPIs in your delivery operation. But the truth is that many addresses don’t have issues, or at least don’t need the full force of normalization. For these cases you can apply a simple version of normalization that just tries to split it into components, and with that you can geocode the address (using the original input) and then use the components to validate the relevance of the results. This is what a few of our @AddressHub customers said, so we listened. So, in Apple style: 𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗶𝗻𝗴: 𝗟𝗶𝘁𝗲 𝗡𝗼𝗿𝗺𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻 ✨ Or rather, we are now offering a way to process addresses that just applies a lite version of normalization, then attempts to geocode and validate the results using the lite normalization output. If the geocoding result is not good enough (at least rooftop, and confidence score is at least 80%) then we run an uplift process which basically applies full normalization and then tries to geocode again. This covers most of the cases where normalization doesn’t improve the geocoding result but still allows you to evaluate the geocoding results, and leaves the difficult cases to full normalization. Additionally, this comes with a pricing model that allows our customers to pay fair prices for normal processing of an address, and an uplift fee only in the cases where full normalization was needed. All of this is done automatically by AddressHub. All the intelligence to detect this runs with our internal models and algorithms, so you don’t have to build any of it yourself. What do you think? Have you ever wondered if normalization is always needed? Here’s your answer!

I implemented a negative cache for open data geocoding in my internal geocoding service. Context: @AddressHub normalizes an address and geocodes it using a curated, pre-processed list of addresses in the country. Previously, I checked if an address was in the database; if not, I started fallback geocoding. If the same address was requested again, I repeated the database query, which, though fast, was slower than no query. Now, a negative cache stores not-found addresses, so a Redis check in under 2ms confirms if a query is unnecessary. This boosts process speed by at least 15%, with the negative cache still growing. I’m exploring more areas to apply this. The goal is to reduce processing time to under 100ms, still a way to go, but progressing.

Delivery companies using advanced routing software without fixing their addresses first 🤣