For a long time I'm using advanced segments created in GA in my API calls. I never experienced any trouble with this. However since last week new created segments don't show up in the management API. I checked it with several profiles, but new segments just won't show up. I have thought maybe there is a limit, but when I remove some segments and add some new, they still don't show up. They also don't show up at the Query explorer http://ga-dev-tools.appspot.com/explorer/
Does anyone have experience with this and have a solution?
This is because new segmentation features were added this past July, and they are not currently supported in the API.
So if you segment on users using the new segments UI in the Web Interface, the segments won't show up when listing in the Management API, and they won't work with the Core Reporting API. However, session/visitor segments with conditions continue to work. This is why you're seeing this behavior...until the API has full support for this.
You can review the Management API changelog, Release 2013-07-15 for exact details on this.
You should subscribe to the changelog so you'll be notified if support is added.
Related
I'm trying to use the Google Analytics Management API to automate the management of a large amount of GA Properties, which is what it's for according to the docs.
However, I'm having trouble with a lot of settings, that it seems like are not available through the API. The expected format of a GA property resource is quite limited in the fields you can set, and it seems to not allow specifying other fields.
Specifically, I am interested in setting the "Advertising features", aka whether to enable the Demographics and Interest Reports:
When updating this setting through the GA UI, the field within the request seems to be called demographicsEnabled, but I cannot set or retrieve this value when using the Management API.
How can I set this and other values through the Management API, or other means? If only a small fraction of the settings for a property can be set through the API, that seems kinda useless for managing large accounts, as the docs claim you can do - so I assume there has to be a way I'm just not seeing here.
How can I set this and other values through the Management API, or other means?
You cant the management api is very limited in what fields you are able to update. Unfortunately unlike a number of other google apis documentation it doesn't actually tell you which fields are writeable. I will mention that to the team.
If only a small fraction of the settings for a property can be set through the API, that seems kinda useless for managing large accounts, as the docs claim you can do - so I assume there has to be a way I'm just not seeing here.
The API was not intended for managing large accounts IMO. It was probably only intended for getting information about what accounts a current user has access to.
What i suggest that you do is create a feature request asking for the ability to update the fields that you are trying to update. The team is normally very open to those types of requests.
Link it here and i will be happy to bring it to the teams attention next time i speak with them.
AFAIK this and many other features are not available in Management API.
I'm trying to fetch rooms (added from calendar.google.com) service account (created from https://console.cloud.google.com/iam-admin/serviceaccounts) in spring boot project.
I had one service account which I created 4-5 month ago, it was working and it is still working with the 3 specific rooms.
But if I add service account mail to other rooms, then these rooms are not returned in the project.
I did all the steps written here:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount
https://support.google.com/a/answer/1034381?hl=en
Also, I tried removing the service account email from the room's "Share with specific people" list in Calendar, and then added it back (this helped sometimes in the past).
But the re-added room was also not returned in my project.
I'm using this method from java to get the rooms.
https://developers.google.com/calendar/v3/reference/calendarList/list
This look like a bug, so do you know how can I work around this?
If you shared the resource calendar with the Service Account through the UI, by adding the corresponding email in Settings and sharing > Share with specific people, the calendar might not have been added to the CalendarList.
In order to make sure that a calendar is added to the CalendarList of a Service Account, you should use the API and call calendarList.insert.
Update:
There are currently several open issues in Issue Tracker regarding Service Accounts in Calendar. The situation you are experiencing is most probably related to that: check this, this and this, for example.
Meanwhile, I don't think using the API can be avoided. Maybe you could develop some kind of UI to make it less painful?
I hope this is of any help.
I'm running a few car simulations using the HERE Routing REST API, and I'd like to be able to get the accurate speed limit for where the car is so that it doesn't go too quickly or slowly for the simulation.
I can see that the speed limit is included within a link.
However, I can't seem to find how to get a link given its Link ID, or if that's even possible with the current API.
In the old API it seems like there was a getlinkinfo.json endpoint which ought to do what I need, but using it on my current freemium account says that I'm unauthorized.
Is this a feature tied only to pro accounts, is it deprecated, or is there just some other way I have to go about this?
As mentioned in the comment above getlinkinfo.json from Routing API has been depricated for sometime now and the alternative is to use HERE Telematics Advanced Data Sets API (https://developer.here.com/documentation/platform-data/dev_guide/topics/quick-start-view-map-data.html) The data is split into different layers and tiles which could be queried for link attribute information.
I'm looking for a Voice Authentication API, and I find Microsoft's one.
When looking at prices, it asks you for a region. The problem is that
it only shows a region
I've been reading about Azure's regions, and it say that is where data is stored, so my question is if it would be possible to use it in a different region than allowed.
Thanks (and sorry for my spelling mistakes).
Quick Answer:
Normally yes, but currently the Speaker Recognition API is only offered out of the WestUS datacenter.
If it's mandatory that you have low-latency when using the service, I suggest you look into setting up and/or temporarily subscribing to a CDN service. Or, if you have a lot of time on your hands, and know waaaaay more than I do about this subject, you may be able to design a local cache to mitigate latency if you're distant from WestUS.
Less-Quick Answer:
First off, you should use the dashboard interface at https://portal.azure.com to sign up. You will first need to create a Pay-As-You-Go subscription as your payment-medium, but it will give you much more control over & visibility into your service.
Here's what the signup pane looks like inside of https://portal.azure.com:
It appears that, in it's current "PREVIEW" deployment, you are right the services is only offered from the the WestUS data center. Normally you will have the option to one of ten's of global datacenters, but it is common that PREVIEW services aren't deployed globally until they're out of PREVIEW status.
If the problem you are looking to remediate is latency-based, look into the CDN suggestion in my "Quick Answer."
If your issue is about getting different pricing based on your location, the location of the datacenter you choose will not affect this. If geographic-discounting applies to you, it is based on the country that is assigned to your Microsoft Username/Password combination at the time it was created. This value cannot be changed once a username/password combo has been created, and consequently, any payment info used along with this uname/pass will need to have a billing address in the same country.
I'm using this link https://www.google.com/reader/api/0/stream/contents/feed/FEEDHERE?output=json&n=20
to fetch feeds using Google's algorithm. As you can see I'm not adding any other parameters, just fetching the returned data in JSON format. My app will be heavily used hopefully and if I send a lot of requests to this link, will Google block my access or something?
Is there anything I can include, like userip, url for my app (so if they have problem to just contact me) or something else?
The most basic answer to your question is that Google will change its Terms of Service whenever it likes, and you've got no say in the matter. So if it's allowed today, it might not be allowed tomorrow, at Google's whim.
On this issue, though, you seem fairly safe. From the Terms of Service (these is the general document, since Reader doesn't seem to have a specific one):
Don’t misuse our Services. For example, don’t interfere with our Services or try to access them using a method other than the interface and the instructions that we provide.
Google provides RSS and Atom. They provide these feeds, so I assume they expect that they'll be used. They don't say that it's a misuse to point someone else at those feeds, so it looks OK for now, but they could add such a clause at any time.
All online services are subject to the terms and conditions of the providers of those services. So, as others have said, they may be ok with your use today, but they can change their mind any time down the line. I doubt including a URL or email or contact info will help anything, because when these services change, they don't notify every user of the service, they just announce the change publicly, and usually they give several month's notice in order to give users a chance to adapt their applications, but this is not standardized or enforced so there is no guarantee. One example would be the fairly recent discontinuance of the Google Finance API (for which no replacement has been announced).
The safest approach would be to design your app such that this feature that uses google's functionality is decoupled as much as possible from the rest of your app, so that, when or if the availability of the service changes (ie it's no longer available at all) you can adapt your app to use some other source for the feeds with minimal impact to the rest of the app. Design for change and plan for the worst.