>> All right so, hello everyone. My name is Sumit Chandel. I'm a Developer Advocate on
the AdWords API. Today, I'll be talking to you guys about the ReportService in v201008
which is faster, better, and stronger than its v13 counterpart, as you'll soon see. Okay
so, v13 ReportService, the way things were. So these are some of the steps you followed
to grade your reports. The first is the report type, the columns, the aggregate type, the
date ranges you want to cover, and what not. Next, you scheduled your report. And once
it's scheduled then basically you poll for ready status. Now, this is a cross-client
report. It could take three hours to come back. And any minute [INDISTINCT] lack of
budget, it could still take a few minutes. So you do that for a bit, and once it's ready
and then you download your report and then filter as needed. So as I was mentioning,
you can [INDISTINCT] it beforehand, if there are certain campaigns that you cared about--you
have to just get everything back and then filter it on your own. All right, so in code,
this is what v13 would look like when you are doing scheduling reports. You basically
create the report, [INDISTINCT] campaign status that you care about more. You select the columns,
start and end date, you validate the report job beforehand, of course. Finally, you schedule
it. And then you wait for it to either succeed or fail. And if it succeeds, download the
report. Print your report stuff, and I guess most of you are--are very familiar with this.
[INDISTINCT] reporting the v201008 way. So the first step is the same, setup your report
type, the column, and the aggregate type. The same way you would for v13. The one difference
here is that the report columns that you once selected, you have to make a request [INDISTINCT]
trying to get those, and select that [INDISTINCT] it up. Next, you--in your report definition,
when you filter the data a little bit [INDISTINCT], you can set the predicates on your report
definition before sending it out. And then finally, you download the report synchronously
using a GET request rather than [INDISTINCT] or anything and polling for the ready status.
Now we'll see how--how all of that works. So this is what we call the blank using a
Java-Client Library to get the various columns available based on our report type. In this
case, it's the "KEYWORDS_PERFORMANCE_REPORT". This column would return these columns back.
So brief [INDISTINCT]. So we've got the columns now and setting it for our report definition.
The next step is to set the predicates. So this is that new thing I was talking about.
We've set--you set the filters you care about before you even run the report and let our
service do the filtering. So in sample 1, we're just saying we're just--we're sending
our predicate for an AdGroup ID that we care about. In this case, the predicate operator
is an equal so we want to be that exact AdGroup ID. In the second sample below, that's a predicate
for our impressions. So basically, we want--we're sending out a predicate for any campaigns
that have a greater number or have impressions that are greater than [INDISTINCT] equals
to zero. And then final, the last step is to add report definition. So once we've got
the columns, once we've got the predicates we care about and the filtering, the next
step is to add the report. So the first few steps are very, very similar to v13; create
the report definition, set the report type, the date range. The selector we've [INDISTINCT]--[INDISTINCT]
that just before and all the other steps. So we set the selector [INDISTINCT]. And then
finally, create the operations, set the operator to add and then call mutate to add the report
definition, right? So, the adding--the adding of the report definition then haven't changed.
They're very similar to the whole V2009 concept of GET, mutate [INDISTINCT]. So that's just
been converted over from the ReportService as well. So how do you run the report? You
issue an HTTP GET Request to a reportURL. You can see it over here. Basically, that
URL is your report definition ID [INDISTINCT]. At the time that you make the GET request,
that's when the report runs and returns. So there might be a question there. It used to
be there is no [INDISTINCT], you know that sometimes the reports will take quite a while
to return. So why does this GET request times out by the time--before the report is ready?
Well, with the new service, we've actually made a point of returning within that timeframe--within
the timeframe of a GET request timeout. So that means you can look forward to getting
your reports--you report data much faster. Another important note, in the GET request,
you have to set the authorization header. As you can see there, [INDISTINCT] authorization
header, "GoogleLogin auth" equals [INDISTINCT] user.getRegisteredAuthToken. So the auth code
[INDISTINCT] something you have already created by this point as your ID [INDISTINCT] service.
I think we're in the header here. I should make my request. That's just for added securities
that no [INDISTINCT] user could just go and put that URL and [INDISTINCT] your report.
So before--when you're taking for date ranges, you can actually set the date ranges for them.
And these are the various [INDISTINCT] that are available. So the idea here is that you
add the report only once. So I create the report definition. Let's say, I want to just
cover the last seven days, so [INDISTINCT] report [INDISTINCT] last seven days. I create
that before definition once. I've added it and then every seven days I'd have a [INDISTINCT]
for example, that [INDISTINCT] get request to the report URL and then we'll get that
report every seven days. And again, every time I [INDISTINCT] the GET request, that's
when that report is run, right? So then, it'll probably last seven days, and it's more important
that way. In case this [INDISTINCT] crashes one day or something I need to run a one-off
report, then you can set a--create a new report definition with the same fields, you set a
custom date for the date's randomness and then just run that [INDISTINCT]. So these
are the various report types that are available in v201008. A lot of these look familiar.
I think a few of them are new, on the next slide here. So also that it's very straightforward
in [INDISTINCT]. You might have noticed that structure reports weren't listed there, whereas
those existed in v13, right? The reason why those are listed in v13 was because in v13,
campaigns that serve zero impressions would not get returned in campaign reports--in campaign
performance reports. So in v13, that's why we have structure reports so that you could
get all the campaigns on your accounts whether they serve zero impressions or not. And then,
you have an idea of what their structure would looks like. In v201008 whether it serves zero
impressions or more, all campaigns are returned in the return data. So you'll always get a
view of the structure of the account--the campaigns under it. So that's why there are
no more structure reports in v201008. Okay, so one note about cross-client reporting,
it's not available in v201008 yet. So cross-client reporting is only available in v13 for now
and that's the reason why we keep ReportService in v13 around for a little--a little longer.
There are plans to, of course, have cross-client support available in v201008. No specific
timeline on when that's going to be available yet. But we're looking into that.