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 datatypes depending on whether it it's selected as a field in the report or used as a filter.
If the ID needs to be used in the filters, then why can't it also be available as a field in the reports? That would at least make it a bit simpler, as we could then instruct the user to use a city ID when they wish to filter by city (but much better still would of course be to simply filter using the city name string, like in the Analytics API). On Dec 30, 12:44 pm, Evgeniy Bogdanov <bogda...@tagan.ru> wrote: > 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, > Evgeniy. -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and discussion group: http://adwordsapi.blogspot.com http://groups.google.com/group/adwords-api =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en
