We’ve been doing some homework related to new project concepts at My Store Locator Plus, our new SaaS locator service. Our recent studies show that American’s are obsessed with food and booze. And the post office.
In case you haven’t noticed, your Store Locator Plus and My Store Locator Plus apps may be working a little different during the last few weeks of 2016. You didn’t change ANYTHING but suddenly things are not exactly like they were before.
It is a special Christmas gift from Google to all of us.
Sometime in late 2016 Google updated their Google Maps API. We are not sure how many changes went into this release. I must have missed the call from Larry and Sergey this time. However we do know a few things that changed that impact customers.
#1 – Geocoding Requires Accurate Addresses
You better make sure your addresses that are sent to Google are darn-near perfectly formed. No more hiding meta in that address 2 field. If a business does not have a suite named “Attn: Customer Service” as part of their official address don’t put it on there. It very likely will not geocode.
Yes, we know it used to geocode back in September. Sorry, folks. Google changed the rules.
Continue reading Small Google Tweak = Big Changes For Some
Looks like Google is turning the screws a little more on their attempt to squash as much competition in the maps market as possible. Over the past few months they have tweaked their Google Geocoding API algorithms. Each change is going to make it just a little more difficult to get your addresses to return a correct latitude and longitude. It is definitely having an effect on locations people are entering into Store Locator Plus but the truly concerning issue is not with addresses you can fix but how it is going to impact all the odd variations of addresses your customers type in during a search.
As is typical from the Google Maps people, the results from their in-house applications including Google Maps The Website is very different from what non-insiders get. Any application using the Google Maps Geocoding service, whether a $20,000/year OEM license or a few-dollar-or-less-per-month Pay-As-You-Go API key, will see different results. The sad part is that what worked perfectly fine “yesterday” no longer works today.
Several known addresses that were designed to “test the system” suddenly started failing our internal testing over the past few days. After rolling back our software and servers to older releases to ensure we did not introduce a problem we’ve discovered that the change is almost 100% guaranteed to be a change in Google’s Geocoding API algorithms.
Diane Blackwelder CFP ®, Charleston Financial Advisors LLC, 4 N Atlantic Wharf, Charleston SC 29401 USA
Last spring that geocoded perfectly fine. Today it comes back “ZERO_RESULTS” which is Google-speak for “bad address”.
This does not work either:
Diane Blackwelder, Charleston Financial Advisors LLC, 4 N Atlantic Wharf, Charleston SC 29401 USA
Only the 100% proper address works:
Diane Blackwelder c/o Charleston Financial Advisors LLC, 4 N Atlantic Wharf, Charleston SC 29401 USA
Yet on Google Maps ALL 3 of these variations come back with the correct address.
This happens with a number of other addresses as well including this example using Google Maps in Germany with the same type of results:
Hotel Berlin Märkischer, Hof am Tacheles, Linienstraße, 133 Berlin 10115 Germany
While this only impacts a very small percentage of addresses people enter into Store Locator Plus, or just about any other mapping service using Google besides internal Google services like their Places (think Adwords but far more costly), it is still very clear what Google’s long term plans are for businesses using their map services.
Granted, Google can always fall back on the “well, that is technically not the right address” argument but the fact-of-the-matter is that these addresses worked perfectly well before. The same addresses work perfectly well in Google-owned properties TODAY. The addresses do NOT work for any third party applications because someone at Google decided they shouldn’t. Not nice, Google. Not nice. It is increasingly clear that Google intends to slowly strangle all third party mapping-software providers so they can collect all the customers that end up being left behind and throw them into their pay-per-request services.
Looks like we are once again having to seriously consider introducing alternative Geocoding and map image technology solutions. We have been investigating Open Street Map for some time. It looks like 2017 is finally going to see that option come online. It is almost a certainty for our MySLP SaaS service and may be integrated into one of our planned live-service options for our Premier Subscribers.
When people ask why we spent so much time and money building a SaaS service for maps, this is one reason why. It is much easier for us to help our customers have a superior experience for their end users when we can setup, testing and activate alternatives in one step. With per-website installations of Store Locator Plus on 20,000+ servers in 128 different countries providing the same type of pro-active response is impossible. We don’t have any control over what those webmaster are doing and not all of them are tech-savvy.
Sure, buy-and-own options like Store Locator Plus can be cost effective but if you’re business relies on your locator having a managed service makes a lot more sense.
There are some new Google changes that we anticipated nearly a year ago and is not specific to Store Locator Plus.
Effectively Immediately, all new websites that come online as of June 22, 2016 will require a Google Map API key. This is no longer optional. Store Locator Plus has had the ability to set a Google API key since version 4. Go to the General / Server tab and enter your Google API Server Key.
You can learn more and sign up for a key from the Google Maps documentation site.
Any users running Chrome including those using Android based web browsers will no longer be able to auto-detect their location using the location sensor unless the source site is running https. That means that your website must have a valid SSL certificate. If your site URL does not load when you use https:// as the starting part of your web address the location sensor provided by the Power Add On will not work.
Store Locator Plus, a top-ranked business locator for WordPress sites, was updated today with a patch for Google Maps API for Business users. Google customers that were using their client ID and private key to access the higher performance Google servers through the Store Locator Plus plugin will once again be able to add and update locations after a prior release introduced a bug that caused geocoding requests to fail if the enterprise access keys were enabled.
Google license and API keys are NOT REQUIRED for the Store Locator Plus plugin to function. Users that do have a Google Enterprise or Maps for Business account can, however, take advantage of Google’s higher-tier mapping services directly through Store Locator Plus. With a Google Maps for Business Account key, Store Locator Plus can geocode up to 100,000 locations daily and will request the geocoding data from the high-performance Google Enterprise servers. These servers can answer geocoding queries 5 to 10x faster than the free service that Google provides if the client ID and private key are not activated.
Other changes in the recent release include a patch to the Store Locator Plus location taxonomy, which allows third party roles & capabilities plugins to access the Tagalong category management system and grant or deny access for managing categories to site users. Also included is an update to the search form markup structure which sets the foundation for better user interface control in future iterations of the Enhanced Search and other add-on packs that augment the search form layout.
Store Locator Plus Changelog
The latest release of Store Locator Plus, version 4.2.23, fixes the automatic WordPress update notification system for the premium add-on packs. The prior versions would not always report when an update was available for the add-on packs. Without the inline notifications provided by the WordPress admin panel the only option to perform an update was to perform a manual installation. The latest patch will significantly improve premium add-on updates for Store Locator Plus.
Also, in this release, DeBaat provided patches that fix the shortcode attributes for homeicon and endicon, allowing each WordPress page or post that uses the [[slplus]] shortcode to override the default icons for the home and destination markers.
Store Locator Plus Changelog
Store Locator Plus version 4.2.19 was released tonight. This version has been tested with the latest WordPress 4.1 release candidate that is scheduled for public release any day now. Minor CSS updates were made to the Store Locator Plus default theme to address changes in the forthcoming Twenty Fifteen WordPress theme that is coming as part of WordPress 4.1.
Store Locator Plus Changelog
Version 4.2.10 of the Store Locator Plus plugin for WordPress was released today.
The recent update adds settings to enable Google Maps for Work clients to use their client ID to enable their access to the Google Enterprise servers. For clients that have purchased the annual license from Google the new settings will provide access to the higher throughput services provided by Google. The enterprise-level services includes up to 100,000 geocoding requests per day on a high throughput communication channel.
Charleston Software Associates is the first, and possibly the only, Google OEM License plugin for WordPress. New services are in development that will allow any Store Locator Plus customer to purchase higher-limit blocks of geocoding services directly from CSA via the Pro Pack add-on. The new pre-request service is scheduled to be launched by January 2015 if production schedules remain on track.
The 4.2.10 includes a fix to the geocoding service which now utilizes the map domain setting under the User Experience / Map tab to request geolocation info from Google.
A patch to the SLP 4.2 add-on pack framework fixes a bug that caused excess memory consumption.
Version 4.2.10 will now show not only installed versions of your add-on packs under the Info / Plugin Environment tab but will also report any newer versions of add-on packs that may be available from the CSA servers. Accurate upgrade reporting will require the add-on packs having already been upgraded to version 4.2, making this feature more useful for forthcoming upgrades. The new feature does not rely on the built-in WordPress upgrade testing process which does not always query third party servers in an efficient manner and often misses update notifications.
Store Locator Plus Change Log
After moving to a new AWS server I discovered that my mail configuration files were not configured as part of my backup service on my old server. In addition my new server is using sendmail instead of postfix for mail services. That mean re-learning and re-discovering how to setup mail relay through gmail.
Cloud servers tend to be blacklisted. Sure enough, my IP address on the new server is on the Spamhaus PBL list. While Amazon allows for elastic IP addresses, a quasi-permanent IP address that acts like a static IP, which can be added to the whitelist on the Spamhaus PBL it is not the best option. Servers change, especially in the cloud. I find the best option is to route email through a trusted email service. I use Google Business Apps email accounts and have one setup just for this purpose. Now to configure sendmail to re-route all outbound mail from my server to my gmail account.
Configuring Amazon Linux
Here are my cheat-sheet notes about getting an Amazon Linux (RHEL flavor of Linux) box to use the default sendmail to push content through gmail.
Install packages needed.
# sudo su - # yum install cyrus-sasl ca-certificates sendmail make
Create your certificates
This is needed for the TLS authentication.
</p> # cd /etc/pki/tls/certs # make sendmail.pem # cd /etc/mail # mkdir certs # chmod 700 certs # cd certs # cp /etc/pki/tls/certs/ca-bundle.crt /etc/mail/certs/ca-bundle.crt # cp /etc/pki/tls/certs/sendmail.pem /etc/mail/certs/sendmail.pm
Setup your authinfo file
The AuthInfo entries start with the relay server host name and port.
U = the AWS server user that will be the source of the email.
I = your gmail user name, if using business apps it is likely @yourdomain.com not @gmail.com
P = your gmail email password
M = the method of authentication, PLAIN will suffice
# cd /etc/mail # vim gmail-auth AuthInfo:smtp-relay.gmail.com "U:ec2-user" "I:email@example.com" "P:yourpassword" "M:PLAIN" AuthInfo:smtp-relay.gmail.com "U:apache" "I:firstname.lastname@example.org" "P:yourpassword" "M:PLAIN" AuthInfo:smtp-relay.gmail.com:587 "U:ec2-user" "I:email@example.com" "P:yourpassword" "M:PLAIN" AuthInfo:smtp-relay.gmail.com:587 "U:apache" "I:firstname.lastname@example.org" "P:yourpassword" "M:PLAIN" # chmod 600 gmail-auth # makemap -r hash gmail-auth < gmail-auth
Edit the sendmail.mc file and run make to turn it into a sendmail.cf configuration file. Look for each of the entries noted in the sendmail.mc comments. Uncomment the entries and/or change them as noted. A couple of new lines will need to be added to the sendmail.mc file. I add the new lines just before the MAILER(smpt)dnl line at the end of the file.
Most of these exist throughout the file and are commented out. I uncommented the lines and modified them as needed so they appear near the comment blocks that explain what is going on:
# vim /etc/mail/sendmail.mc define(`SMART_HOST', `smtp-relay.gmail.com')dnl define(`confAUTH_OPTIONS', `A p')dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl define(`confCACERT_PATH', `/etc/mail/certs')dnl define(`confCACERT', `/etc/mail/certs/ca-bundle.crt')dnl define(`confSERVER_CERT', `/etc/mail/certs/sendmail.pem')dnl define(`confSERVER_KEY', `/etc/mail/certs/sendmail.pem')dnl
Add these lines to the end of sendmail.mc just above the first MAILER()dnl entries:
</p> <p style="padding-left: 30px;">define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl</p> <p style="padding-left: 30px;">define(`ESMTP_MAILER_ARGS', `TCP $h 587')dnl</p> <p style="padding-left: 30px;">FEATURE(`authinfo',`hash -o /etc/mail/gmail-auth.db')dnl</p> <p style="padding-left: 30px;">
If you are using business apps you may need these settings to make the email come from your domain and to pass authentication based on your Gmail relay settings. These are also in sendmail.mc:
MASQUERADE_AS(`charlestonsw.com')dnl FEATURE(masquerade_envelope)dnl FEATURE(masquerade_entire_domain)dnl MASQUERADE_DOMAIN(localhost)dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl MASQUERADE_DOMAIN(charlestonsw.com)dnl
Make the configuration-helper into a sendmail.mc file and restart sendmail:
# make # service sendmail restart
Configure Gmail Services
This is for business apps users, you need to turn on relay.
Go to “manage this domain” for your business apps account.
Go to “Google Apps”.
Click on “Gmail”.
Click “advanced settings”.
Find the “SMTP relay service” entry. Add a new entry.
Only addresses in my domain, require SMTP, require TLS all need to be selected.
Give it a name.
Charleston Software Associates has officially become a Google Enterprise customer. The new licensing agreement for Google technologies will further strengthen the Store Locator Plus, a location mapping and search plugin for WordPress, product offering in coming months. The new licensing agreement provides CSA with direct access to the Google Enterprise support team as well as access to their high throughput map services servers.
The combination of access to the Google Maps API for Business services and improved Google support will pave the way for the development of advanced add-on packs as well as general improvement of services in the base Store Locator Plus product offering. On the drawing board for the future of Store Locator Plus is improved direct access to the Google Maps API for Business for customers with their own API keys and new services from CSA for customers that cannot afford the 5-figure investment.
One of the first products that is on the schedule is higher limits and faster throughput on the Geocoding API calls. This is the service that adds the latitude and longitude to all locations entered into Store Locator Plus. Some clients are loading tens-of-thousands of locations via the CSV import feature provided by the Pro Pack. Unfortunately the standard, free, Google Maps API service only allows a maximum of 2500 requests per IP address. Since many shared hosts have thousands of sites, some of which are using Google API services, it is possible that as few as 100 locations will hit the daily geocoding limit. A new service, still in the planning stages, will allow customers to use the CSA servers to encode their locations for a nominal access fee.
General product improvements are expected as CSA takes advantage of Enterprise Support at Google while developing the new services and features. Getting an in-depth technical overview of the Google API services and the best practices for implementing various API calls will extend the feature set and improve the performance of Store Locator Plus and the associated premium add-on packs.
To the best of my knowledge, Charleston Software Associates is the first WordPress locator plugin author to obtain a Google Enterprise license. My goal is to make Store Locator Plus the first and best plugin for leveraging the new services this license will provide. The next year should be an exciting one for Charleston Software Associates and the Store Locator Plus product line.
Store Locator Plus is helping 45,000+ WordPress sites present interactive store locator and directory maps to their customers. Along the way I have gained the loyalty and trust of thousands of web consulting agencies, design agencies, and website owners from mom-and-pop shops to multinational corporate enterprises. Part of keeping that loyalty and trust is keeping up with changes in technology and in business.
Over the past month I have been in conversations with both Google and Microsoft regarding their map services. It is no surprise to anyone that has been paying attention that maps are THE Go To Service for both these companies. The proliferation of mobile devices and the partnership it brings between “show me what I want” and “for where I am standing right now” has catapulted mapping services from a “yeah, we have that too” service to a must-have component.
Monetizing The Maps
Based on my recent conversations with both companies it is clear. Google and Microsoft are the top players in mapping technology and they are going to monetize that technology every way they can. They are NOT going to leave that money sitting on the table. If you are a business and are using maps to enhanced your customer experience, the writing is on the wall:
YOUR BUSINESS WILL BE PAYING FOR MAPS.
Period. End of story.
Google and Microsoft have all been putting a LOT of work into their map products. They are both offering paid services for business maps. They are also putting a lot of pressure on third party service providers, like Charleston Software Associates, to start paying for access to those maps.
It is no longer an option to provide premium map services to your customer base and avoid paying a license fee if there is a map solution involved at any step of the process. If you do charge for ANYTHING even remotely related to showing a map on a website you need to purchase a map license. Have a freemium model, like Store Locator Plus, where “all the map goodness” is baked in to the free offering but the “CSS and HTML special sauce” exists in paid add-on packs? Doesn’t matter, it is tangential to the maps and thus a “premium maps offering”. If you earn ANY money in ANY way related to a map API you must purchase a license.
How much are those licenses? Tens-of-thousands of dollars depending on who you talk to. Have 100,000 visitors looking at your map page in a year? Try something north of 6-figures.
No wonder Apple decided to contract their own mapping services. Makes complete sense why they stuck with it after the first roll out that was less-than-perfect and current iterations are “not quite right”. If a small business is paying tens-of-thousands and a big business is paying hundreds-of-thousands, imagine what sort of licensing fees Apple had to be paying.
What This Means For SLP
I have been working the business plan for Charleston Software Associates and trying to justify the nearly $20,000 license fee that Google is charging for an OEM license starting next month. It is an annual fee that may (and likely will) increase in coming years. Thankfully I have just enough people buying premium add-on packs to justify the expense.
How does this affect Store Locator Plus? I plan on providing the same plugins I have provided for the past 2 years. I hope to continue providing a free base product in the WordPress directory, though that may change. It is possible that I will need to keep a Google OEM license “locked up” on my servers and make a call-back to my cloud presence before locations can be geocoded. I am still working out the legal and technical details on that aspect with Google. Hopefully things can remain as they are with only improvements and “no additional middle-men” in the process between your website and the Google servers.
For the foreseeable future everything will remain as it is. This puts a significant amount of added pressure on Store Locator Plus to generate revenue. Based on the current install base that should not be a problem. Sadly less than 10% of the 45,000 installed sites purchase ANYTHING from Charleston Software Associates. More than 41,000 sites use the free product with zero contribution toward its development and support.
One thing is certain, starting in July I am locked into the Google Maps program for at least a year. That means SLP and the add-on packs will be around until at least August 2015. The best way to ensure SLP is around much longer than that is for users to support the endeavor by purchasing a Premier Subscription. The recurring annual or monthly revenue helps offset the costs of the Google OEM license.
DIY Maps? Not So Fast
In case you are thinking “no big deal if SLP were to go away, we will just put Google or Bing Maps into our site directly”, not so quick. If your business is getting more than a few-thousand visits to your map you are going to get a call. It is only a matter of time. When you do the conversation goes something like this “Are you running a business that benefits in any way from having the map on your site? Yes? Here is your $20,000 bill.” . The only way out of it will be having a registered OEM licensed product such as Store Locator Plus.
“If SLP goes away there are other WordPress locator plugins on the market.” True. For today. They are all “getting the call” over the next few months. By this time next year there will be only TWO types of WordPress map plugins on the market. Premium with support and free but in constant danger of becoming outdated, unsupported, and abandoned.
Getting A Deal On Map Licenses
How can you get the best deal for your Google Maps license? Buy a Premier Subscription. It is FAR cheaper than getting a license directly. CSA is taking the “up front hit” on the license fee which is then distributed among all users. When Google starts fine-tuning the Geocoding and map presentation service to more closely monitor per-site user stats, Premier Subscribers will be the first to have unrestricted access and higher data caps.
Paying For Good Things
I can’t say I blame Google of Microsoft. They have a great product that they have been letting businesses use at no charge for a very long time. They have poured millions of dollars into the acquisition of intellectual property and millions more into the research and development of the products.
I have no issue with paying for the services that enable my customers to provide a better experience for their users.
For Store Locator Plus, I have elected to continue to support Google. I’ve been a long-time fan of Google. I am an investor in Google stocks since the early days and have been a paid Google Business services user for nearly as long. I like the company, the culture, and their positive impact on the technology landscape. Plus they just seemed more interested in my business and helping me out. I also think it is the best option for my users that have been “with Google” through Store Locator Plus for that past few years.
One of the immediate benefits is that I will have access to the Google Enterprise development team, apparently including someone into extreme skiing. More important, however, they can help advise on how to better implement the technology.
In addition the new license allows for much higher data caps and throughput than the base product. I am planning several new service options to increase map throughput. One of the top items on that list is a paid bulk upload service that will allow larger sites to geocode up to 100,000 locations daily.
I have a lot of locator coding in front of me over the next few months and will be bringing some new coders up-to-speed to help get it done. In the meantime I ask for your patience and support as I navigate the changing landscape of mapping solutions. I hope that I can remain a loyal and trustworthy guide for my customers.
Thank you for your continue support of Store Locator Plus!
Store Locator Plus was updated today with a behind-the-scenes patch that will facilitate a new Enhanced Search “append to user-entered address” feature. This patch comes as part of the base plugin version 4.1.28 and will go largely unnoticed by most users. There are minor updates to the new Above and Beyond NyloBoard theme that should also go unnoticed by most users.
Lost your Android phone somewhere in your house, car, friends house or other undisclosed location and cannot find it? Not that I’ve EVER done such a thing, but I did stumble upon a feature in the Google Play Store that I never knew existed…
Geolocate and RING PHONE.
Where is this feature hidden?
Right out in the open on Google Play.
Surf to Play.Google.com.
If you are not already logged into your account, log in to the same account you use to setup and sync your Play Store apps on your Android device.
When signed in you will see the settings icon, a gear in the top right corner of the page. Click on that and choose “Android Device Manager”.
Google will ping your device, get the GPS location, show it on the map and give you an option to ring the phone at full volume for 5 minutes.
If the battery is dead you are on your own.
At least you don’t have to borrow a friends phone to ring your cell… though you may need to borrow their computer to surf to the Google Play Store!
PayPal went offline for over an hour last night making the second time in a month and the third time in the past 2 months that the service was unavailable. PayPal services have become increasingly unstable over the past year with numerous technical issues and down time that has impacts hundreds-of-thousands, if not millions, of users. My business was impacted last night during one of the busiest days of the past 2 years as the long-awaited Store Locator Plus 4 release was launched yesterday morning.
Once again I set out to find a suitable replacement. After some research into Amazon Payments, which has the same fee schedule as PayPal yet also has a “reserve” clause that holds your funds for 7-to-14 days, I opted not to use them. Same with Elavon and their ridiculous 3.5% + $0.40 per transaction fee, a monthly processing fee, batch processing fees and another myriad of add-on fees and costs that I had completely forgotten about after leaving the hard goods retail world a decade ago. Same for almost all “merchant services” (talk about a misnomer) credit card processors out there, charging more fees for less service. That left only two choices on my short list: PayPal and Google Checkout which is soon to be known as Google Wallet for Digital Goods.
As you can probably surmise by the name of the service, Google Wallet for Digital Goods will ONLY be useful for merchants that sell and ship digital goods. If you are shipping physical goods you can stop reading now, suck it up and go with PayPal. For those selling digital goods online or via mobile platforms you may want to keep reading. Maybe. As I learned along the way, the re-branding of Google Checkout to Google Wallet remains half-ass. Clearly Google has not assigned their “A-Team” to this project and it appears to be the red-headed stepchild of the Google Business offerings. As such I decided, like those with physical goods online stores, to just “suck it up” and stick with PayPal and all the warts that come with it. Yes, PayPal rates are higher than Google’s rates. Yes, PayPal SUCKS at helping merchants fight fraudulent chargebacks and actually turns a profit processing those chargebacks. But PayPal clearly thinks of merchant services as their primary business and not a “give these college kids something to work on”-back-room project like Google does. Pretty harsh review about Google Wallet for Business, I agree, but I also feel it is warranted.
I’ve checked out Google merchant services many times in the past. Despite some cleaned up modern graphics to help sell the service on the front-end, the back-end is a virtually unchanged hack job of an interface. Not only is the interface very pedestrian, it is rife with links to outdated help documents, is completely lacking the tools any serious online business needs to research and report on their sales, and is over-simplified to the point of being utterly useless for any real accounting such as import and processing transactions in QuickBooks. It is no wonder the Google Checkout service failed to ever gain ground against PayPal or the relatively-new-to-market Amazon Payments services.
The Fee Schedule
As with any merchant service one of the first things I look at is processing fees. Many credit card processors, places like Elavon and Authorize.net, eat you alive in processing fees. 10-cents here, a quarter-there. Before you know it you’ve shelled out $900 for $10,000 worth of sales. It is death by a million paper cuts. It was true 15 years ago and is true today, traditional credit card processing companies suck at dealing with new-economy merchants. On the other hand, places like PayPal, Amazon Payments, and Google Wallet for Digital Goods are all tooled specifically to help new economy merchants and have fee structures that are friendly to small businesses. As such, the first stop at Google Wallet is the fee schedule.
At Google Wallet you will find a very simple web page that states the fees are the LOWER of 5% of the sale OR 1.9% + $0.30. For anything that is selling at $10 or more the rate is 1.9% + $0.30 regardless of volume. Both PayPal and Amazon Payments require merchants to sell $100,000 PER MONTH before you qualify for that rate. If you sell $100k PER YEAR this lowers the fees you pay to the merchant processor by $600 when compared to PayPal.
However, when you sign up for the Google Wallet for Digital Goods service you are required to agree to the Terms of Service agreement. Within that document they have a myriad of links to various addendum pages including the Rate Schedule (list of fees). That link goes to an old Google Checkout transaction processing fees page that states the fees are IDENTICAL to the Amazon Payments/PayPal structure with one critical exception; Google charges 1% more per transaction if the buyer and seller are in different countries. So much for competitive rates.
When I discovered the discrepancy in published fees I decided I better get an answer to which fee schedule is the REAL schedule. If it is the original 1.9% deal then making a switch may be worth the effort. If, on the other hand, it is the tiered schedule that starts at 2.9% AND has a 1% “different country” penalty the switch would be a bad decision as I would lose money in fees AND a week of productivity would be lost during the transition. Thus I wrote Google an email via the customer support link at Google Wallet.
Kudos to Google Customer Service, they did respond quickly and gave me an example of a $9.67 transaction and a table that was cut from the web page I already read that states the fee as 1.9% plus $0.30. However they completely ignored the fact that the Terms of Service were wrong. Nor do I think that if this guy pulled up the WRONG information that Google would stand behind the rate schedule some customer support dude sent me via email. I can already see Google’s response when my first 3.9% processing fee for an order from the UK comes in… “Sorry Mr. Cleveland, the rate IS 3.9%, the customer service dude gave you bad information. You did read and agree to the Terms of Service, didn’t you?”. Customer Service also completely skirted the “buyer and seller in a different country” portion of my question and whether or not the 1% add-on fee applies. Though he did avoid answering the question in a very subtle ways saying, just before his $9.67 example “for transactions in the US”. If my read-between-the-lines skill are what I think they are then his answer was “yeah man, we’re gonna nail you for an extra 1% for selling anything to those dang non-Americans” which is EXACTLY what I don’t want as I try to expand my sales into an international customer base.
A Collection of Fail
I’m not sure why Google even has the Google Wallet for Business / Google Wallet for Digital Goods / Google Checkout That Is Almost Dead service online in its current state. How do they expect anyone to have any confidence that their transactions will be processed properly when Google, king of the World of Internet Searches, cannot even build a half-functional website. It doesn’t bode well for the service if the production manager on this site doesn’t take the time to hire one of their bazillion interns to try to surf the site and make sure it works. Fixing basic things like broken links or non-conflicting information would be nice.
Final decision? Not really. These kind of services change frequently and if Google ever decides to stop putting merchant services in the back room and “letting the kids play with it” I think they can be competitor. Especially as it is tied to their prolific mobile platforms payment engine that handles all of those android app sales. However someone needs to be put in charge for the non-app-store side of that business and try to actually compete with PayPal. Until they do so Google Checkout will continue to be a second-rate service that does not instil enough confidence in business owners such as my self to start putting all their online sales into the “Google Wallet Basket”.
Maybe next time around I’ll choose Google. For now I’ve decided to keep dating the wart-nosed older sister with more experience and stability than the younger less-refined and very schizophrenic cheaper date. That old girl may trip over her walker and make us late to our next dinner date, but at least I know she’ll be there. Warts and all. As for that younger sister, maybe she’ll grow up some day.
For those of you that follow my blog posts and forum activity you’ve probably been wondering where the heck I’ve been. Sadly I was not on some exotic trip somewhere, or even a local weekend getaway for that matter. Instead I was playing furniture mover, construction assistant, and general mayhem manager for just over a week now. The house flooding that happened last July finally started the repair process which was a nightmare. The contractor has been great, but along the way we discovered a leak at a roof seam which meant replacing an entire side to the house. Then we found the last contractor nailed through some water pipes which means some unscheduled repairs to the master bedroom. Needless to say I’ve been busy as heck but have not been busy with getting SLP4 wrapped up or answering forum questions.
I think we’re entering the final stretch of construction and actually had the opportunity to spend most of the day on SLP code and related issues. The past 24 hours I’ve been chasing down some issues with SLP4 and an exponential delay in processing CSV imports. Turns out the “increase the delay each time a location hits OVER QUERY LIMIT” is great in theory, but in the real world you can hit Google’s infamous “Daily Limit” which caused all sorts of problems for me during my testing.
Google Query Limits
Google has two different paths to reaching the “Over Query Limit” issue. Both are typically related to a bulk import using the CSV Import in Pro Pack. Users visiting your website are using the client side geocoding process which Google counts towards their personal browser query limit which, to paraphrase the Google website, “you don’t have to worry about, nobody but a spam bot will hit that limit”.
However server based requests, which is the proper method for handling mass lookups of locations and geocoding them with proper latitude and longitude coordinates, is another story. You CAN hit one of the two limits Google enforces. The first limit is the “how many requests per minute” limit, or “Rate Limit”. The rate limit is usually fairly happy as long as you are not requesting more than a dozen geocodes per minute. If you run at “full throttle” for too long, Google will put you on a brief hold.
Rate Limit Management
Store Locator Plus does a fairly good job at managing the Rate Limit with Google. This is the most common cause of Over Query Limit (OQL) and by introducing a slight delay between requests the Store Locator Plus engine can mitigate the OQL responses. In SLP3 the process was fairly simple, if you receive an over query limit response from Google, wait a half-second and re-submit. It will do this process up to the number of retires you set in the settings panel.
With SLP4 the process is far more intelligent. While it will still retry n-times based on your setting, it starts out with a 2 second delay and increases the delay by 1 seconds each time an over query limit message is received. These parameters are based on Google’s recommendations when OQL is received, waiting 2 seconds before the first request that returns OQL and waiting 1 second between subsequent requests. The SLP4 engine will keep track of the delay between all of your location geocoding requests, extending the delay up to 6 seconds between requests until the time the Google stops returning the OQL message. This makes the SLP4 bulk imports much faster and has shown to get more locations encoded than the SLP3 geocoding engine. With SLP4 you can also change the maximum delay to increase it if you are on shared or cloud hosted server where one IP address may have many sites using Google service, or turn it down if you are on a dedicated server with a dedicated IP address.
Daily Limit Management
The other way Google stops you from running geocoding processes is via the Daily Limit. If you’ve been abusing their geocoding service for too long they will shut you off for at least 24 hours. Normally you (or the IP address you share) need to make at least 2500 requests before they put you on this limitation. In my testing I reached nearly 10,000 locations encoded before I ASSUME I was put on the Daily Limit restriction. Since Google returns the same general Over Query Limit response for both Rate Limit and Daily Limit I cannot tell for certain but there are some key indicators. Once I was put on Daily Limit, I could not encode a SINGLE location from the server request interface. I also learned that if I tried to re-geocode a location my 24-hour wait limit was extended. I have no idea by how much, but it seems like they won’t reset your Daily Limit or put you on a strict Rate Limit program once you’ve “crossed the line”.
Google also notes in their Web API Strategies document that you can be locked out from their service, meaning your IP address can be permanently banned from doing any geocoding.
The short version of what this means: if you hit the Daily Limit STOP trying to geocode your locations for at least 24 hours.
Mitigation of OQL
– Set the Google Retries to 3, more than 3 doesn’t usually yield more locations being geocoded and just adds more marks against your Rate Limit or Daily Limit.
– If you are on a SHARED IP address server (virtual server, virtual dedicated server, cloud server, or don’t-know-what server) set your maximum delay to 10 seconds.
– If you suspect you have hit your Daily Limit, import your data with “skip geocoding” turned ON. This will get the locations into your database, though they will not be searchable, so you can later geocode them in smaller blocks. I try to do no more than 100 locations per re-coding session, wait 20 minutes, and try 100 more. Stop the process when any single batch has more than half the locations returning “Over Query Limit” warnings.
– Look closely at the SLP4 messages that are returned. They provide more information and better statistics on the uncoded locations. Not all uncoded locations are Over Query Limit issues. Some addresses simply cannot be located by Google or got lost in the Google processing. Each result will report different status messages. Only re-try geocoding locations with OQL messages.
– Use the CSV lat/long fields to skip geocoding on any locations where you know the proper lat/long. You can use free services like the Texas A&M service for US locations to manually look up lat/long. They even allow spreadsheet input of locations.
– Once you have locations geocoded use the export feature in Pro Pack (v4+) to get the lat/long out of the system for future updates. Any time you can avoid the bulk import geocoding process you will speed up the import AND stop Google from giving you the Overy Query Limit message.