1) CITATIONS - We are in the business of helping folks rank and it's been drilled into us that Citations MUST be consistent across all platforms for them to potentially count. SO...
A) Suite 1st is going to screw up all our existing citations
I don't know if this is so or not. The algos that try to interpret an address passed from Places are poor to non-existent. But the algos that interpret an address when you type it into Google Search are pretty good. So it depends what algos they are using when looking at citations. Can they break it down into suite, street number, steet, etc. with a high success rate?
If they can, then what you should actually be concerned about is that the freehand addresses entered into Places are not being broken down with much success. That right there is a point in favour of having Places have input boxes for each of the components... boxes that have error checking and only allow nearby features (roads, cities, zips, etc.) to be selected. By identifying exactly each component of the address, you can have higher citation matches.
B) We can't make any other citations match up because every single US yellow page and directory PUTS SUITE IN THE RIGHT PLACE FOR US BUSINESSES - WHICH IS AFTER STREET! (sorry to yell but this is just maddening to me!)
People always talk about data being scraped from websites, but the reality is that all the major sources provide it as databases to Google. Using Yellow pages as the example, data isn't being literally being read; it is being passed as data from Yellowpages to Google. I would be highly surprised if YP is not already breaking it down into suite, street number, street name, etc.; I doubt they just have the address all shoved into one field.
So then to match that data, once again Places should be using input fields to ensure that the suite, street number, street name, etc. is positively identified.
C) PLUS Google often throws up a dupe when address formats are just slightly different. So I get if SHE changes the listing to suite 1st and then continues to see listings all over the net with suite last, bet she's going to throw a dupe!
I'd actually expect less dupes if the address is corrected. The system continues to know the address' original formatting, and has now been told that the correct formatting. Now when it encounters occurrences of either format it should be able to match it to the existing listing.
D) PLUS as we know even the slightest NAP change can cause lost reviews.
I think my answer to C applies here too. But this is actually again an argument for Places to collect each field separately so that it is positively identified to begin and thereby greatly reduce the chance of a future address edit ever being needed.
2) CUSTOMERS - The address looks broken, stupid, backwards or like a typo to an average person in the US.
I already addressed that in my original response. That is a display issue. Each element of a proper address in maps is identified and therefore could be displayed differently for any country that did not follow the international norm. But until such functionality is added, then it only makes sense to display things as per the international norm. To put the suite where you want it would actually make the address look wrong to customers in the rest of the world. And to force incorrect data into the database just so it looks right in the meantime is wrong; the functionality of displaying based on country needs to be added instead.
In summary, there's not much Jade can do; the addresses do need to be correct in Maps. What really needs to happen and perhaps what she can push for is that the functionality to accept each element of the address separately needs to be implemented, and while you are at it error checking should be added. Brand new, fresh code does not have to be written; it can just be borrowed from Map Maker. They could add a feature whereby if you don't get the street name you need do to poor mapping in the region, you have a box to freehand it in, and then that is sent to a Maps Editor who first corrects the road and then corrects the address to choose the now available road. The customer is then only freehanding the suite and street number, and the results would then be in the same format every time for the database.
Don't forget, Places serves world wide customers, and so many people expect to see features in many places. What I foresee as being the best functionality is to have the blanks that Map Maker has for entering an address, and then a picture of an envelope below with the address field changing as you add address elements. When you choose/change the country, the order of the elements would change on the envelope. You do this be creating a database of how each country writes an address, and then you also use that database for displaying addresses in Maps and G+.
because if it happened to my client and support would not change it, I would be livid! If that's the way it's supposed to be, then make it consistent across the board.
