Question about the upcoming change history, or maybe don't want it afterall.

[timprepscius]

So one of the things I'm doing these days is keeping track of all of
the changes within google..
And it turns out you guys are adjusting the first_page_cpc for almost
every keyword by little micro amounts everyday.

Before, I thought that it may _drastically_ cut down on bandwidth/
processing if I had a mechanism to get only the changes from google.

But now, I need all of these first_page_cpc values, and I need to
track their changes, which will, in turn, cause me to need our entire
set of accounts everyday. Also, it seems like about 8 months ago
google increased their processing bandwidth, and I haven't had the
problems with the large reports that I had before that. [not really
entirely true though]

So my question is this:
Instead of a change history, which would be nice I suppose, but now I
won't use it anyway.
Would it be possible for you guys to set up a very simple, nice, easy
to use, 1 function call, that will get all information for all
accounts under an mcc account.

You can reduce your bandwidth be over half by making it into a TSV.
It should get both keywords and ads.
It should be alright to have NULL keywords with corresponding NULL
values for keyword attributes and NULL ads with corresponding NULL ad
attributes.
I would like there to be ALL of the information, not just little
dribbles that I get through the reports.

The change history, when you implement it, should really just a be a
subset of this report.
Why have us get multiple reports? Why not just give us _all_ the
information in one nice tidy file?
Do I care if there are columns that only have one value for the whole
report in them? No. Do I care if the file is 20 gajillion-bytes,
no. Do I want all of the possible information for all of the accounts
in one little function call.. Yes!

Oh, and by the way, you _still_ have documentation problems.
Some of which I pointed out nearly a year and a half ago.

-tim

[AdWords API Advisor]

Hello Tim,

I know (and the engineering and product teams know) that the workflow
you describe is difficult to fully implement and much less efficient
than it should be in v13. Your comments, and the comments of other
developers, are making it back to the appropriate folks within Google.

As we've previously said (http://adwordsapi.blogspot.com/2008/12/
preview-of-2009-adwords-api-changes.html), the next AdWords API
release is going to be a departure from v13, and that offers the
engineering team a chance to revisit design choices that currently
result in some common use cases being unnecessarily complex/expensive
to implement. That being said (and I don't intend for this to be
glib), I can't comment publicly about whether specific functionality
will or will not make it into a future release of the AdWords API.

Cheers,
-Jeff Posnick, AdWords API Team

[timprepscius]

Hey there,

I've been refactoring my google code.
Something that would be ultra cool.. Well, in the api-this-isn't-
actually-cool ultra-cool manner..

Assuming that you guys are working on a nice standardized report with
all information contained, where I can call one function call with
minimal paramters and get a nicely formated XML/TSV/CSV/whatever file
with all of the mcc accounts information:

What would be ultra cool, is if I could send you back reports, in
exactly the same format.. No changes in format.. containing changed
item information..
So..

Instead of all of those update criteria calls, update ads, blah blah
blah..

You could almost reduce the API into two calls. (well, not all of the
forecasting-etc-but-you-get-my-drift)
1: Get.
2: Set.

Get would be the ultra-cool-simple-contains-all-of-the-information-
report-that-will-be-easy-to-generate-and-use.
Set would be the _same_ ultra-cool-simple-contains-all-of-the-
information-i-ve-changed-that-will-be-easy-to-generate-and-send.

:-)

-tim

On Apr 2, 2:59 pm, AdWords API Advisor <adwordsapiadvi...@google.com>
wrote:

> Hello Tim,
>
>  I know (and the engineering and product teams know) that the workflow
> you describe is difficult to fully implement and much less efficient
> than it should be in v13. Your comments, and the comments of other
> developers, are making it back to the appropriate folks within Google.
>
>  As we've previously said (http://adwordsapi.blogspot.com/2008/12/
> preview-of-2009-adwords-api-changes.html), the next AdWords API
> release is going to be a departure from v13, and that offers the
> engineering team a chance to revisit design choices that currently
> result in some common use cases being unnecessarily complex/expensive
> to implement. That being said (and I don't intend for this to be
> glib), I can't comment publicly about whether specific functionality
> will or will not make it into a future release of the AdWords API.
>
> Cheers,
> -Jeff Posnick, AdWords API Team
>

[timprepscius]

Just saw, 2009 sandbox announcement.. will read docs. maybe already
there :-)

[AdWords API Advisor]

Hello Tim,

Well, you intuited the get/set (well, mutate) correctly.

During this public v2009 Sandbox "preview" period, we're especially
interested to receive any and all feedback from developers. Please
test out the current functionality (using the sample code until we
release official v2009 client libraries) and let us know what you like
and what you don't like. I can't promise that all suggestions will be
incorporated into the codebase, but, in this period before the
official Production release, the engineering team is most open to
making changes and adjustments to how the current six v2009 services
are implemented.

As mentioned in the announcement, the other services (account
service, keyword tools, etc.) are still further down the pipeline.
Developer feedback about how to improve them over their v13
equivalents has been passed along to the engineering teams who will be
implementing them.

Cheers,
-Jeff Posnick, AdWords API Team