Testing location data with edge cases, not just happy paths
An address in a well mapped city center tells you almost nothing about how your system handles a rural route, a disputed border, or a query near the poles. Test the hard cases deliberately.
Reading the confidence and precision fields correctly
Two fields do most of the work in a geocoding response, and they answer different questions. precision describes what kind of match was found, house, street, postcode, or city. confidence is a number between 0 and 1 describing how sure the match is, given the input and the data available. A result can be high precision and low confidence, or low precision and high confidence, and both are valid outcomes worth handling differently.
Take an example. A query for a full street address with a unit number might resolve at house precision but with a confidence of 0.6, because the input had a typo in the street name and the geocoder had to guess which street was intended. A query for just a city name might resolve at city precision with a confidence of 0.98, because there was only one reasonable match and no ambiguity at all. If your code only checks precision, you would treat the second, much safer result as somehow worse, when it is actually the more reliable one for what it claims to be.
The practical rule is to filter on both, not one substituted for the other. If your use case needs rooftop-level accuracy, such as dispatching a delivery, require precision of house and a confidence above a threshold you set based on testing. If you just need to know which city an order shipped to, city precision with high confidence is perfectly usable and rejecting it because it is not house precision throws away good data.
It also helps to treat type as context rather than a filter on its own. A type of address next to a precision of street tells you the input looked like a full address but only matched down to the street level, which is a useful signal that the address itself may have been incomplete or misspelled, rather than a data gap in the geocoder.
Confidence numbers from different providers are not directly comparable, since there is no universal standard for how the number is computed. Treat the scale as relative within one provider's own responses, not as an absolute probability of correctness. Run your own set of representative queries, look at where confidence tends to sit for good matches versus bad ones in your own data, and pick your cutoff from that rather than a number that looked reasonable in the documentation.
Full details on both fields, including the exact precision values returned, are in the forward and reverse geocoding docs.