Does Suite number before street address cause problems?

[Kristen]

I wondered if anyone could lend some input on whether it would cause problems for the suite number to be displayed before the street address in a Google place page.

On one of my client's listings, a Google rep moved the suite number before the street address instead of after the st. address.

Thanks in advance for your input.

Sandy, the Google rep stated...

Hi Kristen,

After looking further, we've determined that '#345 1234 Kirkwood Court Anytown, Ca'‎ is an appropriate way for your listing to be displayed.

Our systems automatically format addresses this way, if we change your suite number after your street name, like you've requested, our systems will not be able to read your listing's data clearly and could cause possible data presentation issues in the future.

Thanks for understanding and have a nice weekend!

Cheers,

Sandy M.
The Google Local Team

 

[Linda Buquet]

Oh dear....

Is it OK if I move this thread to the public forum? (If you need me to I can change the address if you want to keep the client data private)

I need our MapMaker experts to weigh in and they don't have access to the private forum since they aren't clients. But I REALLY want to get their input.

In a nutshell in case you were unaware, MapMaker formats addresses with Suite 1st because that's how's it's done in the rest of the world. I guess the US is unique. So normally this problem only happened in the past if a MapMaker editor from overseas ended up working on your listing. If it happened we were normally able to get support to fix it.

HOWEVER an address formatted like that in US LOOKS BROKEN AND WRONG to US customers PLUS I worry it would mess with citations.

I've raised a big stink about this before and at one point Places and MM were going to try to standardize or compromise or something to make this right for all. I HOPE the reply you got from Sandy is not the new standard!

After I get Gregg and Andrew to weigh in with anything new they might know, then I'm going to escalate this to Google again!

 

[Kristen]

Absolutely, please feel free to move this to the public forum. I would love their input! Sounds like a mess. :-(

 

[Linda Buquet]

OK, moved to public and made address generic in case you wanted to keep private.

Gregg and Andrew are pretty good about checking in but maybe not on weekends. So hopefully they'll weigh in by tomorrow night. If not, please PM and remind me to follow up and I'll email and ask them to share their insights. (Wondering if something has changed and this is a new requirement or something.)

 

[Linda Buquet]

Actually just remembered this issue came up before with Colan. SAME support reply. See thread below.
Suite # Address Format - A Google Employee Response

Plus see post #3 in that thread for the MapMaker posts where I created the big stink about the issue.

 

[Kristen]

Thanks for the resources Linda. So basically, I should leave it as is? Did you see any drop offs in citations when this happened with your client?

 

[Linda Buquet]

Thanks for the resources Linda. So basically, I should leave it as is?

Did you see any drop offs in citations when this happened with your client?

Well thing is if support REFUSES to change it, then there is nothing you can do. If it's right in dash and they won't change the live listing you are stuck.

And no was not my client, it was Colan's. There is no way that I know of to see how many actual citations Google is really counting for a business. You can search Google as I taught you to see how many POTENTIAL citations are out there. But whether or not she'll count them, if suite is in wrong place is anyone's guess.

Tomorrow hopefully Colan will weigh in too and we'll see how it affected his client.

 

[Colan Nielsen]

Our client that I used in the example was having trouble ranking well before the address was switched to the format with the suite# displaying at the front of the address. It's really hard to say with any certainty how much the address format was contributing to the clients ranking issues.

This particular client had some duplicate issues that were causing some problems as well.

 

[Flash]

The answer you received back from support is correct. When data is stored on a database, each element should be stored in a separate field. The street number, street name, city, province/state, country, etc. are all stored in separate fields. That is how the various tools, including Map Maker, record them and how Maps can distinguish between them. It also makes sure that the data can be understood; for example, there would only be one South Main Street in the database and every property along it would be connected to that one road, rather than having addresses that have South Main Street, S. Main Street, S Main Street, South Main St, South Main St., S Main St., S. Main St., S Main St and S. Main St (plus every possible misspelling). The map is a computerized item, and it needs consistent data to work right.

You can then take the information stored in the fields and custom display it for the region you are in. So it would be possible to display the suite in the standard US position; but at this point that functionality has not been added to Maps. Linda was correct to state that they currently are using the most common addressing format in the world.

The problem is that Places does not follow the Maps convention, despite the fact that they are not a separate product, but rather are a subset of Maps. They allow a freehand address, and then just store it in the fields "Line 1" and "Line 2". There is no attempt at error checking it or validating it. Even worse, it seems to pass the address Maps as just a single field, and Maps usually cannot understand it. Your suite number will appear to be right because Maps will have a mangled address, with the most common one being the street is now Kirkwood Court #345‎. This means that Maps actually does not have any idea what street your listing is on, since there is no such street in the database, and is what leads to markers suddenly relocating or duplicate merges with listings that are on the other side of town. The issues can be even worse, I've often seen the entire freehanded address from Places all shoved into the Address Line field (which is where the suite number and nothing else belongs), and the the street, city, state, etc. are all blank. But even though Maps can't recognize the address, everything is still in the order it was entered into Places and so no one ever suspects.
So it is not actually a good thing when you see your address entered the standard US way.

Basically, in Map Maker there are specific fields for each element, and there are strict guidelines as to how they are used. If Places Support did not follow them, you can expect that a mapper (employee or volunteer) will come along later and correct the edit done by Places Support.

Also, there is actually no way for them to put the name in as you wish. Places Support does the edits within Map Maker, and within Map Maker you have to fill in each field one by one, with everything after the building number being from drop down lists that just give you what is close to the marker. They would only get Kirkwood Court as an option, there would be no street named Kirkwood Court #345‎ in the dropdown list of choices.

One thing you should know, USPS considers the suite in either position to be valid.

 

[Linda Buquet]

Thanks SO much Gregg...

Still leaves 2 problems and I wonder what your thoughts are.

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

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!)

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!

D) PLUS as we know even the slightest NAP change can cause lost reviews.

2) CUSTOMERS - The address looks broken, stupid, backwards or like a typo to an average person in the US.

I'm going to bring this up to Jade again and see if I can get any answers.

 

[Kristen]

Thanks everyone for your input.

Linda, thanks for your efforts reach out to Jade and help us get these address issues resolved. With so many potential ways for listings to get messed up, when several of these issues all happen in one listing, it really is a major setback considering the lack of control we have over this stuff.

 

[Linda Buquet]

You're welcome Kristen.

Just emailed Jade and some other Googlers, alerted them to this thread and also added:

I totally get what Gregg is explaining from a maps/database issue. Makes sense.

HOWEVER the Places dashboard is NOT in-line with the way Mapmaker works.

AND it’s not in-line with the way yellow pages, directories and every other listing source in the US works either.

PLUS it’s an arbitrary INCONSISTANT change in that, the only addresses that get borked are listings that someone from MM gets involved in. Not consistent OR fair.

AND IT CAUSES PROBLEMS like all the issues I raise in post #10.

I think it’s really time (since support is telling people they REFUSE to correct it) that this is addressed, explained, fixed, made consistent or whatever.

 

[Flash]

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+.

 

[Linda Buquet]

Everything you say makes so much sense and thanks for taking the time to explain it Gregg. Your points about dupes being minimized makes a lot of sense too. Didn't think of that.

It's just so frustrating that Places and Maps don't jive and that things are not synced between the two.

It's also frustrating that it's not consistent across the board. If all Suite #s were flipped we?d know we just had to live with it and consumers would get used to it and not think the rare flipped address was an illiterate business owner that wrote their address wrong.

The way it is now 99% of addresses are formatted according to US address standards. It's just the occasional unlucky business that has a run-in with maps or support that gets their address flipped and is stuck with it. Lucky I don't work with clients any more 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.

 

[Flash]

Don't forget, it isn't that support won't fix it; it is that they can't fix it. The system won't let them enter invalid address data.

The address isn't broken in this case, it is the display of the address that needs repair.

 

[Colan Nielsen]

I had a listing that wasn't showing the street# at all last week. I sent in a TS report to Google with the correct address format (as per Google Places account) and they fixed it, however they used the MM format of suite# first.

In the past the Google Places support employees would always change the address as I specified. But the last couple have done the Map Maker format.

Do you think the Google support employees will be doing it this way from now on?

What I'm wondering is why could they update an address to the Google Places format before, but now they can't?

 

[Linda Buquet]

Do you think the Google support employees will be doing it this way from now on?

What I'm wondering is why could they update an address to the Google Places format before, but now they can't?

Good point - they used to and now it seems they won't/can't. The answer why is not clear. I mean I think Gregg will come back and say it's because support fixes things in MM and MM does suite that way. BUT you are right and I've seen them format address to match dash before AND have seen them fix the backward Suite in the past too.

There have been A LOT of things support used to fix that now they won't. Dr. dupes, address formats, URLS. The standard answer is usually something like "we've determined this is an accurate representative of the business."

I sometimes wonder if we are dealing with burned out support reps that are tired of fighting the scraping algo and bots that tend to have a mind of their own and do what they want. I wonder if the attitude is "if we go to the trouble of trying to fix it, the algo is just going to change it again, so why bother. If it ain't broken and the data is basically correct - the formatting is just off a little - we just aren't going to mess with it any more."

 

[MiriamEllis]

Gregg,
I just wanted to let you know that I've found your two lengthy response to this thread to be eye-opening, educational and first rate. I really, really appreciate you taking the time to share your understanding of this area with all of us. Engrossing read.

 

[Andrew Sawyer]

I had a listing that wasn't showing the street# at all last week. I sent in a TS report to Google with the correct address format (as per Google Places account) and they fixed it, however they used the MM format of suite# first.

In the past the Google Places support employees would always change the address as I specified. But the last couple have done the Map Maker format.

Do you think the Google support employees will be doing it this way from now on?

What I'm wondering is why could they update an address to the Google Places format before, but now they can't?

Probably they either got new "tools" as the call them (UI interface for making edits/changes) or were told to actually follow the proper formatting for addresses in Maps.

What is super annoying is that when you make an edit to an address in Places it is a freeform field and it always will auto-abbrevate in a manner that doesn't match conform to GMM addressing. What I have to do is make the edit in Places, undo the auto abbreviation, submit, and check the edit in GMM to make sure the address conforms to the drop down. You can do this (provided you don't make edits in a dashboard). Though I don't know if the same works if you're the one to have claimed the feature but make the edit from Places (not dashboard).

My suggestion is after a feature is set up, go into MapMaker and make sure the address conforms to the drop downs. This includes the state not being abbreviated! Google seems to do okay with translating addresses well if they're set up the "long way." As Flash said, Google doesn't do well if it doesn't know what the address is or guesses wrong.

 

[Colan Nielsen]

My suggestion is after a feature is set up, go into MapMaker and make sure the address conforms to the drop downs. This includes the state not being abbreviated!

Hi Andrew,

So are you suggesting that a best practice would be to create a listing in Google Places with a certain address format, let's say with what is on the business website. After it has been verified, go check MM, see what the format is there and then go back into the Google Places account and make the address format match MM?