Suite # Address Format - A Google Employee Response

[Colan Nielsen]

I used the troubleshooter to report the address on a clients listing that was displaying funny, it has the suite# listed first. "b105, 5826 West Olive Avenue Glendale, AZ 85302"

I thought Google's response was interesting, I wanted to see what we could make out of this:

Thanks for informing us about your address appearing differently on your
local Google+ page than it does on your dashboard. After looking further,
we've determined that b105, 5826 West Olive Avenue Glendale, AZ 85302 is
an appropriate way for your listing to be displayed.

Note that the address on your page might be different from what you've
input into your dashboard. Our processes might alter user-input addresses
to make them more standardized and easier for users to access.

I found this odd because although it does make sense in some places to have the suite# first, I rarely see it this way on Google..and in this case, the majority of the business citations do not list it with the suite# first...

 

[Linda Buquet]

Hi Colan,

Thanks for posting this in public for other's benefit. I have quite a bit of info to share on this issue, but am limited on time right now plus need to go dig up some threads from the G forum and MapMarker that are buried - to support what I have to say.

Bottom line in a quick nutshell is that Google Places and MapMaker have different rules, don't always sync up AND sometimes conflict. MM puts Suite in front of street because that is the conventional format I guess in most of the world, although obviously not in US.

I'll go find the threads later but I started sort of a big issue about this and I guess got management at MapMaker and Places arguing and trying to figure out how to make the 2 play nicer with each other and make the data inputs more consistent between the two. Sounds to me from the support email you got, like the MM side of the house is winning.

So much for NAP consistency, right?

Need to run but I'll have more to share on this later and I know some of the other pros have run into issues with this too, so hopefully others will weigh in as well.

 

[Linda Buquet]

Here's my MapMaker thread that stirred the pot:
Help a Girl out with a Bad Edit - Suite # in Wrong Place

Choice quotes from the VERY long thread above:

You state that it is a problem that the suite number shows up in front of the street. It is not really a problem; that is the world wide standard and only the US uses the suite at the end of the road method. Maps and Map Maker are set up to follow the world wide standard, and the problem is when you try to freehand in an address that doesn't match the standard. And therein lies another issue which gzub already explained; that the other map produce enforce fairly strictly the address format but Places does not. I'm not saying one a strict or lax method is better for a single product, but if you are going to have multiple products and pass info back and forth between them, then you do need to be fairly strict.

The main issue is that Places and Map Maker do not have the same fields available to them and they take a different path to get into maps. In places they err to the side of allowing any format of address, even if part of it is invalid (more user friendly). In map maker the err on the side of data integrity where the data must fit within the strict schema that is defined in their database (easier for geocoding & developers).

This is why when a user in places or maps puts in an address which cannot be converted to fit in the standard fields of the database it is all stuffed the line where you added the suite number in map maker. If the entry had edited to be 345 Estudillo Ave #102 ..." in Places (and all things worked the way it should!) we would have seen it show up in Address Line where you put just the suite.

Essentially all of Googles products which can import data into their geographic databases should use one standard API. At the moment each product uses a separate path which is why you see so many discrepancies between maps, places, map maker and other sources of data.

I would encourage that you make sure that you make sure that the fact that these data issues exist between the different Google Geo products is brought up on the Places side to make sure that Google sees these issues from multiple product groups. You shouldn't have to come over to Map Maker to perform edits and I shouldn't have to go to Maps to edit data to fix things (not that I mind you visiting).

A related thread in the MM forum that could more aptly be titled "Google Places is from Mars and MapMaker is from Venus!" More Problems With Address Formatting Between Places and Map Maker

Then there are heated private threads I've had with Google about this and some good public threads in the Google Business forum that I don't have time to dig up right now. Late doing research for my next consult, so need to run, but that will give you PLENTY to chew on!

 

[Keenan Glass]

In my opinion, I wouldn't worry about how Google displays the format and just keep listing the NAP across the web in a consistent manner.

 

[Cleaner44]

If a new company were just getting started and there was nothing establised yet, I wonder what would be the best format.

If the Google Map listed as:
1234 W Main St #123

But the company website listed as:
1234 W Main St, Suite 123

Would it be better to change the website to the Google Map format and build all citations from there or would it be fine just to go with the website format?

 

[Linda Buquet]

Zero citations either way? I research a bunch of other address stuff before deciding so with this limited made up example hard to say.

If that was a Google created Place page with address listed that way, and without knowing any other details, my tendency more often than not is to leave the address in the format G thinks is best.

 

[Cleaner44]

For purposes of my example, I was saying if there was no Google Places/+ Local created. Just searching the address as 1234 W Main St, Suite 123 Anytown, USA I often find that Google will return the map as a search result and convert the Suite to #123. So my thought was that maybe it would be best to start creating citations with the # format that Google seems to prefer.

Make sense?

 

[Linda Buquet]

Oh I see. I thought you were saying there was a Place page but you were calling it a maps listing. Just re-read and I see what you mean.

I have to say I'm torn about Suite vs #. I think MM prefers Suite and it's one of the most important feeds to maps and Places. I prefer Suite for customers because I think it sounds better. But maps seems to like street abbreviations and # over Suite, possibly I'm guessing due to limited display space on maps.

Wish I had the magic answer, but for the most part as long as whatever you pick you are consistent, you should be OK. She's fairly good at basics like Suite vs #.

Whichever way you go, just be sure to put suite on line #2 as required now.

 

[Andrew Sawyer]

Oh I see. I thought you were saying there was a Place page but you were calling it a maps listing. Just re-read and I see what you mean.

I have to say I'm torn about Suite vs #. I think MM prefers Suite and it's one of the most important feeds to maps and Places. I prefer Suite for customers because I think it sounds better. But maps seems to like street abbreviations and # over Suite, possibly I'm guessing due to limited display space on maps.

Wish I had the magic answer, but for the most part as long as whatever you pick you are consistent, you should be OK. She's fairly good at basics like Suite vs #.

Whichever way you go, just be sure to put suite on line #2 as required now.

I don't have and hard data but from my experience using "Suite 123" is better than "#123" in the Address Line. GMM seems to like it better.

 

[Flash]

Back to the original issue, you also need to be aware that when editors (either volunteer or Google employees) go through an area and fix everything up so they are all formatted the same, they are going to change the address to the standard maps format. They have no visibility to see that it is a claimed listing, and most listings are not claimed. And even if they knew, they would still correct it, because it is not just a placement issue, but rather the suite number at the end of the address gets combined with the data nearby (street name at least, can be more, up to and including the entire address) and then that gets shoved into one of the fields, so it is corrupting other parts of your address also. I often see the entire address shoved into the suite number field. You don't notice that it is wrong because it all still is displaying in the correct order and the marker is where it was manually placed; but this is where people ask why their marker suddenly jumped to a spot a couple of miles away... something else in the listing was updated either by the owner or the bots and this caused the address to be re-evaluated.

 

[Colan Nielsen]

Thanks for that great insight Flash! I long for the day when maps/mapmaker and Google Places are all synced up...

 

[Cleaner44]

I notice that these days Google+ pages automatically generate addresses in a long form such as:
123 East Main Street
as opposed to
123 E. Main St.

I wonder if this will become dominate...

 

[Linda Buquet]

Hey Colan,

I noticed this listing still has Suite listed 1st. (plus.google.com/105398195305314513407/about)

Could you weigh in on this thread? Does Suite number before street address cause problems?

Kristen has same problem with support refusing to fix the address. She's wondering if you had a drop in ranking or have any indication that citations took a hit???

 

[ARKlady ARKtechCo]

We've done the suite before the address and now use the second line instead but interesting response.

 

[russofford]

Hello All,

I noticed in a G+ Local listing for a client of mine that Google chose to display 'St 14' in front of the address... instead of Suite 14 or #14. (The dashboard has 'Suite 14' in the 2nd line.)

In a comment on an edit I made on a GMM POI just now, 'Flash' just told me the following:

As the box is for the suite/unit/office/shop/etc. number, there is no need to proceed it with "Ste". Could you please cut it back to just "14". Google will also allow "#14", but they do not like descriptors.

What I understand from this is that you should not use 'suite' nor 'ste'... but just the raw number and the # sign in front of the raw number would be acceptable.

A 'descriptor', would then be variations on the words: suite, ste, unit, office, shop, etc.

Russ