We've set Google Analytics GA4 event transfer via Measurement Protocol. We followed documentation fully - https://developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events?client_type=gtag
Everything was fine in test GA counter, but after moving on production counter events stopped getting into interface (though keep being sent to connected Google BigQuery).
To be clear, we can see that events are counted, but not users.
0 for users, 25 for events
We changed only API secret and Measurement ID in our configuration. The major difference between test and prod counters: production is linked to Google AdWords and GoogleBigQuery.
Would be very grateful for any ideas and insights in that case.
I have same problem. You need to set engagement_time_msec parameter.
For example:
"engagement_time_msec": "1"
More: https://support.google.com/analytics/thread/117981433/events-sent-from-measurement-protocol-do-not-set-active-users?hl=en
The Measurement Protocol V4 is for GA4 properties(which is also the
one you are using).
According to the official document:
https://support.google.com/analytics/answer/9408920 It says "Google
Analytics 4 properties counts users who engaged with your app/site for
any non-zero amount of time during the previous 30 minutes".
GA4 uses "engagement_time_msec" parameter to identify user interaction
time. This explains why you can see the number of events but not the
number of users. If you want users sent from MP to be counted as
active user, simply add the "engagement_time_msec" parameter to your
event.
I think this is "by design". Even this screenshot in the official docs shows Users in last 30 minutes: 0 https://developers.google.com/analytics/devguides/collection/protocol/ga4/verify-implementation?client_type=gtag#realtime
As far as I can tell it's not possible to enable Session Hits Count for events triggered via the new measurement protocol (or whatever is necessary to get active users/sessions).
It might be possible to find a workaround for this issue:
using Tag Manager
using the undocumented url format (https://www.thyngster.com/app-web-google-analytics-measurement-protocol-version-2)
Related
I'm currently developing a facebook App whose purpose is to
For a given page, list the last X posts
For each of said posts, list the last Y comments
For each of said posts, list the last W reactions (e.g. likes)
For the page as a whole, display the Z most active users considering the last X posts
The app is not yet published (And, since it'll only provide server to server communication, it might never be) and it currently has one admin and 4 test users.
I'm currently hitting rate limits for the comments endpoint, whereas I've never got any alert for the reactions endpoint.
The rate limit documentation says that some endpoints do not count for rate limiting, but it doesn't say which ones. So I assume that, in my case, only the comments API calls are eating my rate limit.
One approach I might consider to go over the rate limit is to create test apps for my app. They do have their own app-id and app-secret, and share the same app-scoped User ID namespace, so user IDs will be consistent and I'll be able to use both Apps to display aggregate data.
What I don't know is do test apps have their own rate limit?, or do they "eat" part of the production app rate limit?
I want to avoid creating the logic to rotate the App credentials on each call only to discover the rate is still the same.
Edit: I created a test app and hardcoded some calls to use its credentials. However, said calls aren't shown in test app's dashboard. I believe this would mean that its calls are attributed to the main app anyway.
We have a user who is getting 1000 results back from a realtime API query but is expecting more.
From the docs:
https://developers.google.com/analytics/devguides/reporting/realtime/v3/reference/data/realtime#resource
It does not appear that the realtime API response contains a facility for paging.
Is it correct to assume this API endpoint:
https://developers.google.com/analytics/devguides/reporting/realtime/v3/reference/data/realtime/get
Can return a maximum of 1000 results?
You need to remember that real-time is still beta. The real-time request doesn't include a next link which means there is no way to get extra data back.
Try setting &max-results=10000 see what that returns. The max rows for the Reporting API is 10000, however I have been unable to find any information on what the max number you can set in the Real-time API is. Real-time isn't returning an error if I set it to 10000 however I don't have an account with that many real-time users so I cant test it. I am going to send Google an email to see if I can get a verification what the max number is for the real-time api.
https://www.googleapis.com/analytics/v3/data/realtime?ids=ga:78110423&metrics=rt:activeUsers&access_token={accessToken}&max-results=10000
You might want to add a issue request to issues - google analytics requesting that they add nextlink at the very least.
I know that fb have made available some documentation about the requests limits to the api https://developers.facebook.com/docs/marketing-api/api-rate-limiting,
but it is not clear how each api call is calculated...
i.e, If I want to get stats for ~10,000 adsets, how can I evenly space the time between the calls ?
The best answer i could find for this question from another SO thread -
"After some testing and discussion with the Facebook platform team, there is no official limit I'm aware of or can find in the documentation. However, I've found 600 calls per 600 seconds, per token & per IP to be about where they stop you. I've also seen some application based rate limiting but don't have any numbers.
As a general rule, one call per second should not get rate limited. On the surface this seems very restrictive but remember you can batch certain calls and use the subscription API to get changes."
Source - What's the Facebook's Graph API call limit?
Official Doc-: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Rate limits are imposed on each app. The rate limiting tool gives you information about how close your app is to being throttled. Click on any sample to get more detail on the types of utilization.
Your app can make 200 calls per hour per user in aggregate. As an example, if your app has 100 users, this means that your app can make 20,000 calls. This isn't a per-user limit, so one user could make 19,000 of those calls and another could make 1,000. This limit is calculated based on the number of calls made in the previous hour.
Source-: https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
Heavily rate-limited per ad account. For development only. Not for production apps running for live advertisers.
If the answer is yes, then what is it?
By maximum number of connectioned allowed per application I mean how many instances of the same api/key can be used to get the friends list at any one time, will Facebook block too many requests?
EDIT I have been looking at http://developers.facebook.com/ but have not been able to find the answer to my question there.
From their Policy
If you exceed, or plan to exceed, any of the following thresholds please contact us as you may be subject to additional terms: (>5M MAU) or (>100M API calls per day) or (>50M impressions per day).
The only information I was able to find is something in a forum.
http://www.quora.com/Whats-the-Facebook-Open-Graph-API-rate-limit
After some testing and discussion with the Facebook platform team,
there is no official limit I'm aware of or can find in the
documentation. However, I've found 600 calls per 600 seconds, per
token & per IP to be about where they stop you. I've also seen some
application based rate limiting but don't have any numbers.
As a general rule, one call per second should not get rate limited. On
the surface this seems very restrictive but remember you can batch
certain calls and use the subscription API to get changes.
You can see how many API requests your users can have a day if you go to your Insights page and click on "Diagnostics". You can also see some other request statistics if you click on "Performance".
http://www.facebook.com/insights
I am using the GA Data Export API to interact with Google Analytics and I'm making a lot of progress, I am using this URL Endpoint initially to pull all the profiles under an account:
https://www.google.com/analytics/feeds/accounts/default
This URL retrieves each GA ID (profile) and each UA. One thing I've realized is one account can contain multiple UAs and when this happens, this request pulls all profiles. We have a client who has about 115 profiles under like 10 different UAs, and the request takes about 30 seconds for the initial request (and then I believe it must be cached, because it speeds up considerably after this, but then the next day the same thing occurs).
Is there a way to get a list of UA's without pulling the profiles? This way I can query the UA specifically for the profiles instead of pulling each one.
Any advice on this would be really helpful!
Thanks
UPDATE: Here's some documentation on the specific call I am using right now:
http://code.google.com/apis/analytics/docs/gdata/gdataReferenceAccountFeed.html
UPDATE 1: I have found some interesting information in the docs
Once your application has verified
that the user has Analytics access,
its next step is to find out which
Analytics accounts the user has access
to. Remember, users can have access to
many different accounts, and within
them, many different profiles. For
this reason, your application cannot
access any report information without
first requesting the list of accounts
available to the user. The resulting
accounts feed returns that list, but
most importantly, the list also
contains the account profiles that the
user can view.
So this means that you have to use the default accounts call to get these back? Surely, somebody has had this issue before?
So apparently, you can query the account if you know the UA-ID, however there is no way to get back a list of only UA IDs.
One way you can do it is have the user enter their own UA ID instead of having them choose one; not as user-friendly as it could be but better than making the user wait 30 seconds!