I have sent them a email to refund my money etc...
Has anyone else had this problem before and if so did they refund you?
Im scared!
In four years, tens of thousands of keywords and many many clients accounts, I've never ONCE had a mistaken bid "just show up" that wasn't my own fault. I sincerely doubt Google makes this error.
I never disputed a credit card charge from Google but they thought I did, and they banned me for life from participating under my own name and email address.
In one of my sectors, one or two of our competitors routinely bid WAY more than the rest ($25 per click as opposed to $1 per click, for example) in order to stay on top during special campaigns. I know this is not in error because they do this in MSN and Yahoo (where we can actually see what the maximum bid is) at the same time as well. Believe it or not, it's a valid strategy that people use for position and branding. Why should Google have to guess your intent?
You might get lucky and get a refund, but I doubt it. I'd be willing to bet that as far as Google is concerned, you bid on the clicks, they delivered them, and you owe them for them. They held up their part of the bargain. There's no question of ethics here. So you will have to "be a man" (?) and pay up, since you can't return the traffic.
If you make a mistake, it's YOUR FAULT. Don't blame others. It's your account, take care of it. If you made an typo, that's YOUR FAULT. Nobody stole anything, nobody wronged you, anyone who can't see that is nuts.
Why is everyone willing to give Google the benefit of the doubt, but not a fellow webmaster?
Do you think Google could not make a mistake?
Let's clarify this with the original poster: how did you triple-check it? Did you verify the correct amount by viewing the campaign subsquent to adding it? Or did you simply check that the amount was correct in the entry field?
This IS a common programming mistake, and it is not unreasonable to consider that Google could have made it. One should not assume that had they made it, thousands of people would have been affected and it would have been immediately noticed as an error. You don't know what is inside of Google's code. It is possible that a mistake was made that was in a seldom-used execution path.
That said, you shouldn't be running with campaign limits that would allow this to go this far. Of course, if you have a large number of products, it is difficult to break them down into enough campaigns to effectively partition potential loss. The 25 (or 50) campaign limit is arbitrary and idiotic.
This IS a common programming mistake, and it is not unreasonable to consider that Google could have made it. One should not assume that had they made it, thousands of people would have been affected and it would have been immediately noticed as an error. You don't know what is inside of Google's code. It is possible that a mistake was made that was in a seldom-used execution path.
Sounds like a good reason for G to be audited, not for click fraud, but for software bugs that may cause high click charges.
Why is everyone willing to give Google the benefit of the doubt, but not a fellow webmaster?Do you think Google could not make a mistake?
I didn't realize this was an "us versus them" situation. I believe it's much easier to explain by user error than by a software bug that should have been uncovered by thousands of other webmasters, even with a rarely executed path.
You're not going to prove a bug exists until it can be re-created. Of course, those in the "Google is evil" camp can also use this to indulge their own ill feelings towards the big G.
At any rate, it's easy enough to trace back through the account history that logs all changes.
The poster never said that he made a mistake. He said he checked it three times.Why is everyone willing to give Google the benefit of the doubt, but not a fellow webmaster?
Do you think Google could not make a mistake?
In this particular case the odds that the poster made the mistake compared to Google are astronomical in favor of the poster making the mistake. Clearly we can see the most likely mistake a human would make in placing a bid would be to misplace the decimal. So the chances of him making it 21.00 instead of .21 is very high, relatively speaking. The chance of the Google algorithm making that mistake compared to making it any other number are simply much lower. There is no default bias for the Google algorithm to change the bid from .21 to 21. If the bid was changed to 72.41 instead of .21 I would believe it was much more likely a problem with Google than with the user.
However since this is not an error that you can specifically tie to Google but one you can tie directly to humans and probably the most common one at that, all things considered, it is unrealistic to think this was anything other than the original posters fault.
This IS a common programming mistake, and it is not unreasonable to consider that Google could have made it.
What is a common programming mistake? Dropping the decimal. The problem is it would have magically had to drop it in only one very specific instance. While the chances of that are possible, they are amazingly slim. Why would it not change it for all bids in all campaigns, or for all users or any other factor? The reality is, the chances are much greater the user simply made a mistake.
One should not assume that had they made it, thousands of people would have been affected and it would have been immediately noticed as an error. You don't know what is inside of Google's code. It is possible that a mistake was made that was in a seldom-used execution path.
Certainly, but it is 1000 times more likely that the user mis-typed their bid.
I've placed bids (many of them) in the $7 - $10 range and you can be sure I knew the max I'd spend that day.
I do the same thing when I bid a nickel.
If you get a refund are you going to give Google a share of your sales that day? That's the ETHICAL thing to do.
What is a common programming mistake? Dropping the decimal. The problem is it would have magically had to drop it in only one very specific instance
Yes, dropping the decimal is a common programming mistake. This mistake can be made in a number of non-obvious ways.
For example, it is common to store currency values as fixed-point values in pennies, 1/10's of pennies, 1/000'ths of pennies, etc. To do that, you multiply incoming values by a factor. The number of zeros can be large, and it can be very confusing. Sometimes this involves converting to text, laying the text down in a buffer, doing little tricks with laying \0x00 into the buffer. There are a zillion opportunities to make this mistake. Most of them don't involve forgetting to type a decimal point where it belongs.
Fields in database records or "wire" records (i.e. data being sent from one computer to another) often assume a decimal point in a particular position. It's easy to make a mistake when moving character data into such a field.
Bugs occuring in only one very specific instance are the norm, NOT the exception. The easy cases are caught before they become bugs in production code. There's a "long tail" in bugs. And it is a LONG tail! It is difficult to impossible to have 100% test coverage of execution paths.
It's not at all uncommon to have code that is only executed in 1%, .1%, or .001% of all cases.
Here's one thing that the brokerage industry does to track and verify this kind of thing. It is common practice for every single packet that is sent by and received by an order-entry system to be logged in it's raw form.
For example, let's say I send an order to buy 100 shares of GOOG at $475.00. Let's say I'm not a normal retail customer, but an algorithm trader.
First thing, my system will log the order in two different ways. It will probably log the order to a database. At some point, it will format the order into the form required by my broker's API. Either right before or right after actually sending the order to the broker, I will also log the stream of bytes sent to the broker. The stream log will be done with no interpretation whatsoever - a binary record of exactly what was sent. The one bit of twiddling that is typically done is that a timestamp is added. The less fiddling the better, as it minimizes the chances of the log being inaccurate.
My broker's system, upon receiving the order, will also immediatley log the received bytestream data. It will probably also log the parsed and decoded data in a database.
My broker's system then sends the order to an exchange or ECN. Again, this is logged both in a database, as well as the raw log of the bytestream sent to the exchange.
The exchange will do the same thing.
Ditto for order confirmations, cancellations, etc.
Every party has a complete log of every byte sent to and received from contra parties, which they can match-up with their more highly-processed databases if need be.
99.99% of the time, these logs simply accumulate until they are eventually discarded. Disputes are usually easily resolved without needing to consult these logs.
But they are there, and they are indeed used.
One can track an order from a customer's system to the broker, to the exchange, and all the way back.
I have poured over these logs many times, with my broker, a rep from one of the ECNs or exchanges, or both, many times. Emailed log sections back and forth until everybody understood just what went wrong where.
Such meticulous logging is done, of course, because billions of dollars worth of transactions go through these system on a daily basis.
Despite that, mistakes and errors do occur. Nobody in the brokerage industry would suggest that the NYSE, NASDAQ, Instinet, major brokrages, etc. can't make a programming error. In fact, they have and do, and anybody in the industry has seen it happen time and again. It's rare, but it happens. And, so, the systems are built with extensive logging in place to help track-down those rare cases.
Now, back to Adwords... A paranoid (or, perhaps, prudent) client could certainly install a packet logger on their machine and set it to log every packet sent to Adwords. While it would take some education and very good eyeglasses, they could then go back over their log in a situation like this, and see what their computer actually sent.
Now, let's say this error occurs, you've got it logged, and it shows that you, indeed, send it as 21 cents. Does Google have the other side of the log, and are they willing to pour over it the way the brokerage folks do?
That will probably remain an unanswered question. Because Google is as opaque as the brokerage industry is transparent (at least when it comes to the mechanics of trading...). They probably would suggest that the existence or non-existence of such logs is a trade secret.
When you chnage your daily budget from some figure to some very high figure, it prompts for confirmation and tell us that the new budget is much high then previous one. And if this is done by mistake click "Cancel".
Google can put similar feature in CPC value and prompt user for confirmation to make this situation not happen again.
Give it a rest, it's not the first time.
Having said that, this thread will encourage me to double check everything twice before I click enter. This user's mistake actually helped a lot of folks today.
First of all if you actuall read my post, my question was "Has anyone else had this problem before and if so did they refund you?"
Im not trying to screw google. I want to work something out with them that is fair. I will let you all know what happens. Probaly by today I will have a answer.
Thanks for your posts that are supporting my side of it. :)
$.21 cents can become $21.00 when you type a . (point) instead of a ,(comma) or vice versa depending on your account settings.
For English accounts a .(point) is used to seperate dollars from dollarcents or euros from eurocents. If you bid $0,09 the , (comma) will be ignored and the bid will be set at $9.00
This can be very tricky when you use the numeric keypad on your keyboard while the settings of this numeric keypad are set to a comma instead of a point
For English accounts a .(point) is used to seperate dollars from dollarcents or euros from eurocents. If you bid $0,09 the , (comma) will be ignored and the bid will be set at $9.00
You betcha this is a bug!
That's outrageously bad UI design. There is no reason to accept $0,09 as 9 dollars. Or euros, or anything else. REGARDLESS of locale settings. Any more than 0¦09 or 0*9foo should be accepted.
It's either a valid input of 9 cents, or an error that should be rejected, depending on how you look at it.
Is the original poster English? The plot thickens...
Not all European machines or cultures use the same symbol for decimal point ..
On an azerty keyboard ( for a desktop machine ) the "decimal" key is actually shown on the key surface as a "dot" but will generate a "comma" when struck ..
the foregoing applies to an OS set to "french langauge"
Whereas on an older type laptop ( the sort that requires a separate numerical keypad to be attached ) if one types using only the numbers on the top line ( if one is french ) one is naturally going to use the "comma" key ..whereas an english ( UK ) user would use the "fullstop" key ..for decimal spacing ..
if this is where the error lies it could be solved by G using the OS langauge info of the connected machine to determine what the input intentions were ..thus a french user in the U.S.A would be able to input as per their cultural conditioning ..and the same would apply to an english speaker accessing their account from France whilst on holiday ..
G already does GEO IP identification ( erroneously as not all connections from France are made by people who would naturally use a "comma" as the decimal point ) ..primary OS language sniffing would solve this ..particularly as the biggest effect of OS langauge setting is to determaine how the keyboard hits are interpreted by the OS ..
</return to normal service>
If it's an isolated incident, it makes more business sense to refund the money. Why risk losing a customer that may spend 100k or more over 2k or less?
if this is where the error lies it could be solved by G using the OS langauge info of the connected machine to determine what the input intentions were
Not sure that that's possible, at least not reliably. Sounds so simple on the surface, but really quite a mess. Google knows what country the user is from. There's a locale setting in the user's acccount. The web browser and OS each have a locale setting. Then there is the hardware (keyboard) itself.
Now, which one do you choose?
But it's absolutely insane to just throw the seperator away, causing the intended value to be multiplied by 100! That is, quite simply, a flaw. There is no way you can excuse it.
You might argue that it would be correct to accept either form. Or that the value should be rejected. It's not rational, though, to silently throw away the incorrectly-entered seperator, resulting in an incorrect value.
Given that Google DID make this mistake - there can be no argument with this - is everyone still sure that Google can't make a mistake? Are you all convinced that there are no other bugs lurking in the code?
Explain to them that it was an honest mistake
The poster, however, maintains that he did not make a mistake. Are you suggesting that he lie as an expediency?
The funny things is eventhough my bids were that high, I did not hardly see a increase in clicks. I got the same amount that I average at $.18 cents.
YAHOOO Im happy to get a $1,000 credit!