Revisions to the AdWords API Beta Program

[AdWordsAPIAdvisor]

First, I want to thank you all for your feedback, support and patience
over the last several months as we worked to redefine the AdWords API
in a way that would better meet everyone's needs.

Back in November we formed an internal task force to re-examine the API
beta program's structure and quota allocation system. Our goal was to
come up with a revised system that better aligns the needs of all
developers with our own needs as an organization. Over the last few
months this group has gathered developer feedback from multiple sources
including your emails as well as feedback provided via the AdWords API
Developer Forum. <http://groups.google.com/group/adwords-api>

As a result of our task force review process, we've decided to change
the overall structure of the AdWords API Beta program. We believe these
changes will better balance the needs of developers and advertisers
with our own system and resource needs.

Based on our interactions and conversations with you, we have
identified four key issues that needed to be addressed as part of any
new API plan.

* Flexibility and scalability: Our developers need a more flexible
and scalable API program that can address each developer's needs, but
that also can be applied equitably to all developers in order to
maintain a level playing field for everyone.

* Commercialization terms: The terms and conditions need to be
modified so all developers have the opportunity to commercialize their
applications.

* Usage and functional standards: We need to maintain certain usage
and functional standards that increase overall advertiser returns.

* Incentives for efficiency: We need to implement incentives for
developers to design more efficient applications. This, in turn, will
ensure greater system availability for all.

Based on these needs, we will implement two major changes to the
AdWords API Beta program on July 1st, 2006.

* Revised quota allocation system & pricing model: We are changing
the quota allocation system and pricing model to create a more flexible
and level playing field that encourages efficient coding and
application design. Effective July 1, 2006, the current free quota
system will be replaced by a usage-based system. Under this new model,
AdWords API token holders will be charged a nominal $0.25/1000 quota
units consumed. As a result, current developer quota caps will be
removed in order to provide a more flexible and scalable system for
quota allocation and consumption.

* Modified terms and conditions: We are modifying our terms and
conditions in order to simplify developers' abilities to
commercialize their applications while at the same time ensuring that
advertiser returns are maximized through the promotion of certain
functional standards. These new terms also will go into effect on July
1, 2006. Prior to that date, you will be able to view an advanced copy
of these terms and conditions at
http://www.google.com/apis/adwords/terms_preview.html.

In June we will launch an API registration micro-site that provides
more details on these new billing processes and procedures. Please note
that certain developers, such as those who design proprietary
applications to advertise their own businesses, may be exempt from a
portion of these fees and terms. The registration micro-site will
provide more details on these exemptions.

Thank you all again for your feedback and patience over these last few
months. We'll be in touch again shortly to provide you with more
details.

-- Rohit Dhawan, Product Manager

[inasisi]

So all of us need to pay money for using the API, irrespective of how
big our spending is and how small our actual quota usage is? If so
despite all the flowery language that you have used to explain the
change, this reeks of "Bait & Switch" and hate to see a company like
Google get into such cheap practices. You initially provided the API
free of cost to us. Now that we have built all our systems around it
and has kind of become indispensable, you are turning around and going
to charge us for it. Mind you, my programs are very efficient as far as
the usage of my quota goes and I consume only a very small portion of
my monthly quota. But I still hate to have to pay for that usage
especially when we were not told about it initially.

What would be more equitable would be to assign a certain amount of
free quota to people based on their spend and then people can buy more
over and above that.

[Jan Piotrowski]

Full ack, inasisi. This just doesn't seem fair. Are Google's costs for
the API so high? Every API call is one request fewer to the normal
interface...

A better approach would have been to make the free quota assignment
more transparent and add the possibility to buy additional quota if
needed. Then Google could still decide how much quota and usage is
appropriate for a certain spending, and the user could widen his
possibilities on request/payment.

-- Jan

[goran77]

Correct me if I am wrong, but I heard that Adwords Editor does not
consume quota, which means it's usage will not cost (in terms of
quota). Now, if usage of my program uses 1.000.000 per month (250$) or
even more for heavy users, how can I compete with Adwords Editor?

[Robert]

Okay, I give up and stop the development of my Adwords client, because
I see no way to sell it. (After one year coding I wanted to release the
beta version next week.)
But perhaps I misunderstand something?
- Have I to pay for all used quotas, even while developing my program?
Does there are no free quotas? (Alexa.com offers 10.000 free request
each month. 1 Alexa request means 25 Google quotas)
- Have I to pay the bill for my customers, which consume the quotas???
(I'm a developer, not a debt-collection agency.) Why does not simply
add the fee to the Adwords payment of my customer?
Some questions about the new terms and conditions:
- What is an "Application Token"? Does Google certified the Adwords
clients?
- II. 1.) "Each corporate entity of a company, whether an affiliate of
any other corporate entity or not, must use its own Developer Token if
it uses the AdWords API." Does this mean, each of my customer gets its
own developer token?
Do I have the customers accounts link to my Adwords account (API
linking)? If yes, is there a linking API
(http://groups.google.com/group/adwords-api/msg/c5fe3bce836a9488?hl=en&)?

Thank you for your answer,
Robert

[Chris]

Man this is so low ... a multibillion company squezzing a few dollars
out of the folks who are acquiring customers for the adwords program
which in turn gives them an even higher profit and more customers.

We are convincing companies to use google adwords. Then our customers
pay 1000$ to google and 100$ for our service.

Now google even want a share of those 100$ ... pretty fair imho. Good
move on being a "do no evil" company.

Oh and concerning their public relations dep. : like a poster before me
noticed you gotta love the "flowery language" they finally come up with.

[pete]

Our pricing model is so tight, we can't afford to pay this so I guess
we'll have to pass the cost for using the API onto our customers.

At least that way our customers will know who gets the extra money
they're having to pay.

MSN AdCenter is released soon right?

This market is in clear need of some competition.

[hmcclungiii]

I've got 25,000,000 monthly quota for free. So now I'm going to have
to pay $6,250 to have the same quota? Wtf is this? Please Google,
tell us it isn't so!

[Rob]

I agree with Inasisi but for a different reason. The current plan to
make API users pay, displays a fairly shortsighted and mostly technical
driven vision ("we want to limit API use by taxing it"). In my opinion
Google's interests are much better served by having good (API based)
tools to manage campaigns as these will delivery happy and spending
customers. So I would be in favor of a system where a base amount of
free quota (based on MCC turnover) can be supplemented by extra paid
quota (like inasisi).

I'm afraid this move will seriously limit innovation as the small (and
most creative) parties are most likely to drop out first. I suggest
that this plan is seriously reconsidered and that the technical folks
at Google spend more time/money on making the API more scalable, so
everybody wins.

[TM]

Costs aside, there are two clauses in the Terms & Conditions that need
to be revised:

1) Section III.2.f requires that any client support ALL API and regular
AdWords web interface capabilities. So technically any application
that is designed, say, only for getting reports, but not for campaign
creation, is in violation. Same goes for all bid management programs
out there. This is obviously an oversight, unless the intention is to
make all applications out of compliance simply in order to have a
legally easy way to kill any given application. Surely that can't be
the motive since Google could simply have (or maybe does have, I don't
recall...) a specific clause that states that as their right.

2) Sections III.2.c.iii & III.2.d state, respectively, that there can
be no commingling of stats data (say, clicks for the prior month), and
that any reporting of such data (say, clicks for the prior month for
Google and Yahoo) must clearly label the data as being from Google and
the Third Party. The latter one sure seems reasonable. Not sure what
the exact intent of the former was, but again, obviously, this is
silly; every application in the world would commingle data to some
degree if it was intending to generate a report like that. (Yes, of
course it is possible to store it separately, but that would be
impractical.) So III.2.c.iii needs revision.

So, just a request to revise at least these clauses. Thanks!

[bombaywalla]

AdWordsAPIAdvisor wrote:
> Please note
> that certain developers, such as those who design proprietary
> applications to advertise their own businesses, may be exempt from a
> portion of these fees and terms.

Could someone please explain the rationale for this exemption?

[dw]

This is absurd. I can't believe Google of all companies would want to
stifle innovation like this. Who is going to develop applications if
they have to implement EVERY SINGLE feature of the API? That would
take months. Not to mention that most people only need/want certain
features for their apps. I don't need my app to support 'local
business ads' or whatever other stuff Google is going to add over the
months and years.

Why was the language added? To protect their brand image no doubt.
Google doesn't want people using commercial tools that limit the
functionality of AdWords. The problem is now only large companies will
be able to develop applications as it is going to take months and
months to re-create the AdWords UI.

Google: You need to understand that having access to a good API allows
your advertisers to SPEND MORE MONEY!!!! More efficient campaigns,
easier to manage, better measurement. This makes for more satisfied
customers, which means long term advertisers. Come on now, you guys
are smarter than this.

[Robert]

TM wrote:
> 1) Section III.2.f requires that any client support ALL API and regular
> AdWords web interface capabilities. So technically any application
> that is designed, say, only for getting reports, but not for campaign
> creation, is in violation.

I also don't understand this. Can the Adwords API team clarify this?
This limitation prevents and forbids the development of tools for
special cases and niche markets (Adwords Backup tool, Adwords reporting
tool, a keywords crawler with an button "Add to my Adwords account").

Perhaps Google can be give some example for each
section/number/character in the TOC which application is allowed or
forbidden?

Robert

[triv]

I also have to add, that theses changes in the quota system, does not
seem fair and I am considering not to use the API anymore, especially
stop developing our software for it.

Maybe peaple start thinking about screenscraping again...

I hope, Google will change their plans in terms of quota system. I also
would suggest, that every user gets free quote depending on the
spendings and then will be able to buy additional quota if needen...

Think about it!
An angry developer

[NJ]

Same question : WHO will be elligible ? HOW BIG is the "portion of
these fees" ?
Thanks !

[Daniel]

I also think that these measure isnt fair.
Many Customers wheter one of the big advertiser or the little webmaster
with shop have realised the power of adwords for their business. Every
tool that spends time, money and gives more flexibility brings up
better results for the customer campaigns so they can spend more money
- so google earns more :-)

so why thwart all developers with such limitations?!

>Maybe peaple start thinking about screenscraping again...

i suppose that many developers scrapes google but this is another
subject ;)

Greetings from Germany!

[JezC]

Hi TM,

Read section III.2.f more carefully.

It requires that you implement all the functionality of the calls you
use. It explicitly states that if you are working on a bid management
tool, you only need to implement stuff for bid management - but you
have to implement all the bid management functions. Bid management
tools don't need to manipulate adverts.

The T's and C's allow special purpose uses. It doesn't require you to
develop a full interface for all aspects and every API call - unless
you use part of the functionality of everything that it does.

Here's the statement on the T's and C's that makes this grindingly
clear:

"For example, if a particular AdWords API Client enables
bid-management, all aspects of AdWords bid management and all API calls
related to AdWords bidding must be enabled and exposed by that client
within 3 months after those functionalities are available in both the
AdWords API and the standard AdWords Web-based user interface."

Google obviously has listened to the feedback about the last T's and
C's they offered, which were clearly not what they intended to mean. I
think this new set is closer to a useful intent.

I'm not entirely happy with the changes, but they do:

* now allow OSS developers to contribute free implementations
* allow customers to use a shared copy of code (standard commercial
distribution)
* permit development of specialised tools
* allow multiple specialist tools to be used (there is a technical
limit on two API clients having concurrent access, but no contractual
limit)

I've submitted several pages of reasoning about why I'm unhappy. Not
rants (I hope), but argument based on absorbing as much of the text and
intent as possible. I recommend that you do the same. Rather than
reading someone elses' opinion and getting excited, go read the
original document - then get rational ;)

Cheers, JeremyC.

[Kenneth Gomez]

Very well said Jeremy.

--

Cheers,
Kenneth Gomez.
http://www.kgomez.com
"The heights by great men reached and kept,  Were never attained by sudden flight, But they, while their companions slept, were toiling upward in the night."

[MikeyB]

Okay,

I have been waiting for this that you can buy extra quota and a change
in the terms.
Actualy this is a good step for the commercial bussines, but i agree
that the costs are a bit high indeed.

Just see what the times brings us.

Lets thing this way $0.25 for 1000 quota is the worst case, maybe we
can buy more quota each month for a lower price or maybe maybe maybe
...... something else.

We will see what kinda strange things are gooing to happen.

Mike

[TM]

Thanks for clarifying JezC, I didn't read it closely enough after all.

But, the language in the Terms and Conditions is actually still legally
vague on this. Using an example does not sufficiently specify the
legal boundaries of applicability. And since "functionality" is not
defined in the Ts & Cs (if it were, it would be called out, defined and
then capitalized as "Functions", "Functionality" and the like), when
the clause says "If an AdWords API Client is capable of conducting any
***campaign management*** [emphasis mine], then it must do so for all
available AdWords ad media formats available at the time of use.",
"campaign management" functions could be interpreted broadly. But the
example continues on to state a single specific element (the array of
supported media formats) that must be kept up to date. So there seems
to be room for interpretation, and therefore, for tightening up the
language.

Whatever, it's not that big a deal. If Google wants to shut someone
down, they'll shut them down. Only a very well-funded firm could fight
against GOOG's deep pockets if a fight broke out. So, as I said in the
original post, I don't suspect there was this nefarious intent, just
not-specific-enough writing. (But who am I to talk? My post was
sloppier! :-P ) And, admittedly, going through all these little
nit-picky things is a pain in the rear for the lawyers writing the
document.

[thomp361]

You have to be kidding me, charging us for API usage is crazy....Google
you've really done it this time. If you guys indeed follow through
with this we're leaving. I agree with inasisi, the "bait & switch"
tactic makes me sick.

I would vote for a quota thats based on your adwords spend rate with
the option to purchase more on an as needed basis. That way everybody
wins, google gets more adwords $$ as we get more quota which allows
both parties to grow.

[Jon Tara]

While I think there are still some kinks to work out, this certainly is
welcome news - if for no other reason than removing the uncertainty
over the Adwords API program. Developers have been in limbo for months
with no future visability.

Further, while some may be unhappy with the fees, this plan is a big
plus for small developers and advertisers. It gives us equal access to
the API to that afforded to big clients. Although big clients may still
be getting a free quota, at least small clients will now have access to
whatever quota they need to get the job done. Access for a fee is
better than no access at all. (And a quota of 15000 units/month is no
better than none at all.)

This is going to eliminate a lot of unnecessary effort diddling with
quota rationing when that effort should be spent on developing
functionality. It will make quota considerations strictly an economic
decision. If the cost of developing applications that use the quota
efficiently, or rations it out to clients, etc. is worth it, it will be
done.

It also allows me to make a decision to go ahead and complete
development of a caching client/server for commercial sale, so I hope
to be able to offer some relief on API costs. Those plans have been on
hold pending an announcement about the future of the API program.

What I plan is a server that an Adwords can install locally, and have
their in-house Adwords client(s) connect to the local server instead of
directly to Google. It will cache data in a local MySQL database. This
server can be used as a test server (something sorely lacking) for
initial API development without incurrent quota charges. Once an API
application is developed, this server will sit between the user's API
application and Google, and will both speed-up retrieval of data
already in the cache and save money by eliminating unnecessary accesses
to Google. Other than changing your application to connect to your
local server rather than directly to Google, it should be completely
transparent, not requiring you to use a specific language or
higher-level API.

I agree with the comments several have made about the requirement that
commercial apps implement the entire API. Although this doesn't apply
in my case (I will have to implement the entire API for this to be
useful to a broad range of users), it does seem unduly restrictive. I
note, however, that this is nothing new - this language has been in the
"commercial" part of the agreement now for some time. Keep in mind that
this does NOT apply to in-house applications - your in-house
application is free to implement whatever feature set you need.

But it seems Google has missed the boat on this one. By far, I think
the GREATEST need will be for niche applications. But the agreement
only permits comprehensive applications that would basically be a clone
of the Adwords Editor.

Doesn't make sense.

But Google seldom does. Where they found somebody who apparently spends
some of their life outside of the GooglePlex and has somewhat of a
clear view of reality is beyond me, but it's a welcome change of
attitude in the right direction. They are showing signs of common
sense. I hope they keep it up.

[romas]

Real world example:

I have 10 000 keywords (product names), I need to update price of bids
1 time per day per keyword (based on keyword/product performance data):
10*10 000 = 100 000 tokens * $0.25/1000 = $25 per day
30 days *$25 = $750 per month only updating bids 1 time per day.
Bid day parting is impossible for sure, I can't afford to update bids 3
per day: day/evening/night : $2250 per month: $27k per year.
Am I wrong?

What is the reason to kill adwords API development?

Regards,
Romans

[Peer Jakobsen]

Are all of you 10000 keywords important enough to change the price
every day.

How about analyzing clicks/impressions and CPA or ROI on each of your
10000 keywords and then divide them into for example 3 segments based
on importance. Then you could propably change the price 3 times a day
for you top segment, once a day for your medium segment and once a week
for your bottom segment.

This way you would propably end up spending less quotas.

romas escreveu:

[Richard Jones]

On Fri, Apr 14, 2006 at 01:08:48PM -0700, romas wrote:
> I have 10 000 keywords (product names), I need to update price of bids
> 1 time per day per keyword (based on keyword/product performance data):

We don't have much love for the quota system, but I have to agree with
Peer that you shouldn't need to adjust all 10,000 keywords every 8
hours.

We use a mixed strategy to cope with accounts with large numbers of
keywords:

* Exclude keywords which have no data (impressions/clicks) over the
last hour. Obviously if you've got no data, then you can't make any
sensible decisions.

* Exclude keywords which we've previously adjusted in the last 90
mins. Because of the reporting delay there is no point adjusting a
keyword too often, because you don't really have new data for it.

* Exclude keywords where your calculations don't actually move the
price. We round prices to the nearest pence, cent or yen[1], and if
the old price is the same as the new price, ignore it.

* Keep everything in a database so you don't have to use Adwords API
unnecessarily. In general you shouldn't need to use the API to fetch
anything, because your database should know what keywords you have[2].

The upshot of this, particularly the first rule, is that even though
we nominally run the bidding program every hour, it hardly spends any
quota at all, and only adjusts a small handful of keywords.

Our bidding engine which does the above is here:

http://www.annexia.org/tmp/bid_engine.ml

The interesting stuff happens towards the end of the "run" function.
Thanks to the magic of functional programming and functors, I can show
you the engine, but the "secret sauce" is kept in the functor's input
parameters, stored in other files.

Rich.

[1] Actually Yen isn't handled correctly at the moment - a bug that
needs to be fixed.

[2] Another bug is that it needs to be changed to use updateCriteria
v3 as detailed by Patrick here:

http://adwordsapi.blogspot.com/2006/02/updatecriteria-doesnt-have-to-blush.html

It'll use even less quota then.

--
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

[romas]

Richard Jones wrote:
> On Fri, Apr 14, 2006 at 01:08:48PM -0700, romas wrote:
> > I have 10 000 keywords (product names), I need to update price of bids
> > 1 time per day per keyword (based on keyword/product performance data):
>
> We don't have much love for the quota system, but I have to agree with
> Peer that you shouldn't need to adjust all 10,000 keywords every 8
> hours.

Sure I agree with you. It was just an example. I am not going to adjust
bids for 10 000 keywords every hour.

But real life is more complex then simple calculations. I can imginate
many possible scenarios that will be killed by new quota systems.

Another example: I want to add new 1000 keywords to my account. What
prices I should set? I do need to test different prices to see
clicks/impressions/budget spendings.
If price range is from $0.01 to $1 how many tokens I will spend to find
the best prices for my keywords? I have goals on budget, roi, cpa, cpo
and clicks. I need to test different prices, it is expriment, not only
smart calculations. I will not be able to test keywords for different
pricing fast enought if I will change prices 1 time per day per 1% of
keywords in set.

How I will know that keywords "ABCD" will meet my goals at price range
$0.3 - $0.35 with this creative(s)?
Keywords estimation even can not say me how many clicks I will get.

Regards,
Romans

[Robert]

JeremyC, I read section III.2.f carefully.

section III.2.f: "_Full Campaign Management Functionality_. All AdWords
API Clients must expose at least as much campaign management
functionality as is available in both the AdWords API and the standard
AdWords Web-based user interface of any version of AdWords during the 3
months preceding use, for the general functions being affected by the
AdWords API Client (which must include, without limitation, giving the
end-user the ability to make calls to all parameters made available by
the AdWords API Specifications for that particular functionality)."

Do you see the words "must expose at least" and "which must include,
without limitation"?
Which services belongs to the "campaign management functionality"?
CampaignService? AdGroupService? CriterionService?

> The T's and C's allow special purpose uses. It doesn't require you to
> develop a full interface for all aspects and every API call - unless
> you use part of the functionality of everything that it does.

Is this your interpretation?

> Here's the statement on the T's and C's that makes this grindingly
> clear:
>
> "For example, if a particular AdWords API Client enables
> bid-management, all aspects of AdWords bid management and all API calls
> related to AdWords bidding must be enabled and exposed by that client
> within 3 months after those functionalities are available in both the
> AdWords API and the standard AdWords Web-based user interface."

There is no hint in this example that this particular AdWords API
Client doesn't require a full interface for all aspects and every API
call.

Imaging: I say to you: "Build a house, every parts should be blue. For
example, the door should be blue." Then you say: Ok, I make the door
blue and the window red. But this would be wrong.

Google Team, what do you mean?

Robert

[JezC]

Hi Robert,

spot on correct. I have written about the arbitrary drawing of lines
around parts of the API, extensively, in private correspondence with
Google, and given them use cases, based on our wants and experiences.

The revised T's and C's show that Google intends that developers need
not expose the whole API and develop a complete replacement UI.
However, the lines around a product and its' use of the API are drawn
by them, based on their preconceptions of what products should be
delivered by third parties. This is much the same scenario as late last
year when the T's and C's were most recently modified. Google gets an
idea of what the market wants, issues a set of terms and then gets
critiques that show how the terms could be improved.

As an example of how Google's preconceptions affect the drawing of
lines, I might have a client whose preference was only to manage
keywords - as a business they might not want to touch the Content Match
network or Site Targeting. I'd still have to develop an implementation
that delivered services the client explicitly didn't want to touch.
This would increase costs for the client for services they didn't want
to use. It could be the difference between choosing to use a
competitors API and services - Overture is, IIRC, about $2,500/month
for up 96 bid changes per day on all managed keywords. With the
management costs of being forced to deliver services that weren't
required for a Google implementation, and the quota costs, the
opportunity cost of delivering on Google may be higher than could be
justified before demonstrating returns from Overture.

If you can think of other use cases that would break the T's and C's,
derived if possible from real user experience, I think you'll find that
your concerns are taken into account - though it could be months before
you see that response in the form of a new set of T's and C's.

The last round of T's and C's clearly made our activity (the
OCaml/command line tools for the API), completely outwith the terms.
That obviously wasn't the desired intent. With complaints in postings
here, our private complaints, and quite probably the complaints of
others that I'm not aware of, the new T's and C's are a consequential
improvement.

Google has to protect its' interests, and the T's and C's are how it
does it. However, it also has to be part of a support ecosystem - the
oak on which ten thousand species create a thriving community. If that
support structure of third party businesses, to compensate for the
parasites and pests, doesn't exist, then Google is weaker. So I'm sure
that these are not the final form of the T's and C's, just a Beta :)
Google is responding to rational criticism by improving the T's and
C's. Your posting will help.

Cheers, JeremyC.
--
Merjis : web marketing through insight : http://merjis.com/

[riverman]

let me add my meek voice to the chorus. usage charges are a huge
mistake...making the interface more efficient rather than taxing users
would be a far better approach.

we've stuck with Google because of the huge advantage the API gave them
when managing keywords. this new charge negates that advantage, so
we'll dust off our screenscrapers, code them for MSN and
Yahoo/Overture, and spread a not so inconsiderable amount of ad
spending among all the players.

[Jan]

A very big German Adwords API user was told that there will be free
quota based on advertising spend. The person he talked to couldn't say
if this is for all API users or only for him and his big business or
for all Adwords API users. Also he wasn't able to tell more details.

German posts on this topic:
http://betamode.de/2006/04/18/adwords-api-doch-weiterhin-umsatzabhaengige-quota-zuteilung/
http://www.abakus-internet-marketing.de/foren/viewtopic/p-217083.html#217083

No reason to stop posting our thoughts here what we think about
removing the free quota system till Google changes Adwords API's T's
and C's or someone posts a confirmation here or on the blog. But a
first step into the right direction.

- Jan

[Daniel]

the quoata system are only one of the new terms. that about the term
that it is forbidden to store google, yahoo, msn and other providers in
one application under one GUI?!?!

[Andy Scrase]

I think this topic has been done to death, but I am going to pitch in
my 2c anyway.

Although it's good news that Google have finally announced a new set of
T&C, I am concerned that the proposed pricing model will make our
Adwords project financially unviable.

We are writing "efficient" code, using local caching etc. We need to
build creatives from product databases and that in itself is pretty
expensive. Bearing in mind that a lot of exceptions (such as spelling
mistakes) are thrown back, it can cost a lot more than $.25 to place 4
ads (assuming the rate card remains the same).

So we now have to pursuade our customers to (a) buy adwords (b) pay us
our margin (c) pay for the quota cost, and also we need to keep on top
of development for the moving target that is the API. We are going to
have a hard time selling this package and make any money out of it.

I think a lot of us were hoping that the old model would be retained
and extended, where quota was based on ad spend, and anything over the
quota incurred a cost. This seems a much better model to me, as the
primary motivation is to increase the efficacy of the Ad campaigns,
which is a win for the customer through better advertising, a win for
Google by trading quota cost for greater ad spend (recurring versus one
off revenue on an Ad by Ad basis), and a win for developers by
minimizing quota cost and increasing profits through greater ad spend
(assuming some kind of commission pricing model).

I suspect that the proposed model will drastically decrease usage of
the API as the economics sink in. I hope this wasn't the intention.

So, in summary, I hope someone on the Adwords team makes a note and
thinks hard about this pricing model, and who it is going to benefit.

Regards
Andy

[kwal...@gmail.com]

> I think a lot of us were hoping that the old model would be retained
> and extended, where quota was based on ad spend, and anything over the
> quota incurred a cost.

Same hope here. Good post Andy, we are right there with you.

[Shane O'Grady]

I was hoping for the same type of model. Hopefully Google will listen
to us and implement another change to the T &C's.

[hmcclungiii]

I fourth the motion.