Re: AdWords API Differential get? - Justin Evans - com.googlegroups.adwords-api

8 messages in com.googlegroups.adwords-apiRe: AdWords API Differential get?

From	Sent On	Attachments
Justin Evans	23 Oct 2006 02:16
Richard Jones	23 Oct 2006 06:21
Justin Evans	25 Oct 2006 07:49
LeTic	26 Oct 2006 03:50
eule...@gmail.com	26 Oct 2006 04:04
Randy Wigginton	26 Oct 2006 08:42
Patrick Chanezon	26 Oct 2006 10:29
JezC	27 Oct 2006 03:18

Subject:	Re: AdWords API Differential get?
From:	Justin Evans (just...@theslice.co.uk)
Date:	10/25/2006 07:49:37 AM
List:	com.googlegroups.adwords-api

Hi Rich

I'm going to need to return to this, so will try out these theories then.

Thanks very much for your help.

Justin

Richard Jones wrote:

On Mon, Oct 23, 2006 at 02:16:58AM -0700, Justin Evans wrote:

To elaborate, if we retrieve our data from the API, store it in a database, and then interface from our local DB, the data in our DB has a risk of becoming outdated. So we need to perform a new request to retrieve the data again in case anything has changed. This means we may need to delete the data in our DB first, or after an update, or compare all of the data we receive against the DB to see if it is different and subsequently update records etc. Surely it would be more efficient to receive only the data or instructions concerning data which has been added, modified or deleted between a date range?

Do you mean "which adverts did someone add through the user interface since last time we did an update"? Or "which keywords have had new impressions"?

The two questions are a bit different. If you have a (common) scenario where you keep track of campaigns/adgroups/keywords/ creatives in a database, but allow people to make arbitrary changes through the UI, then you need to periodically re-synch your database with the contents of the account. This is a potentially expensive operation because there is no "see updates since ..." operation through the API. You have to revisit everything down to the keyword/creative level and do a "diff" against your database. We have written code to do this, and I suspect lots of other developers on this list have written similar things. It's time-consuming and fiddly to write this code, but ultimately not very hard. We run this sort of process every week, because the quota cost is unpredictable and expensive.

Second issue is how you might look at new "events" happening in the account - say a keyword which gets more impressions. Here you can run a report across the whole account (or across multiple accounts if you're an MCC) which will get the keywords which have non-zero impressions/clicks/whatever, and you can store those events in your database. Run the report periodically - eg. daily - and you will use a predictable quota budget which you can calculate in advance.

You might ask why you can't run a report to see all keywords/adverts. In fact this is not possible currently because reports don't report keywords/adverts which have zero impressions, nor negative keywords (for the same reason).