Thanks for the explanation. I understand you have some valid reasons
for making the change. Still, wouldn't it be quite simple to also make
the city/country IDs available as report fields, instead of just the
string values?
On Dec 30 2011, 7:10 pm, Evgeniy Bogdanov wrote:
> Mikael.
>
> I'm agree
Mikael.
I'm agree with you that this method gives us as API's users some
problems.
But as you can see - API is growing and evaluating.
As a developer i think that new behavior is good idea.
And I'll try you to explain why.
You know that searching in database by integer works faster than by
strin
Hi Evgeniy,
The problem is that it unnecessarily adds complexity when for some
fields, the filter value passed by the user can't be used as such, but
needs to be passed through another service first to change it to an
ID. It doesn't seem like very good design when the same field has two
different
Hi Mikael.
I do not understand your problem. If you have string - you can get ID
and vice versa, what is wrong?
You're trying to compare different APIs.
GA API have many good things, but this is generally other API for
other platform.
And this 'other platform' makes such differences.
Regards,
Ev
So this field returns the city name as string, but when the same field
is used as a filter, then an ID needs to specified? And even though
filtering must be done using the IDs, it is not possible to retrieve
the IDs as a field in the report, and instead a separate service has
to be used for this? T
Hi Mikael.
Unfortunately you didn't point what type of library and programming
language do you use.
Problem is that in v201109 changed idea of targeting.
Now for all locations you need to specify ID of location, not it's
name.
You can get know this ID by calling LocationCriterionService (http:/
I'm trying to get a geo performance report in v201109 that's filtered
by city. My request is:
CityCriteriaId
Impressions
CityCriteriaId
EQUALS
Atlanta
20110101
20111229
Au
