What is the rate limit for direct use of the Googl

Question

In the Documentation for Google Analytics Collection Limits and Quotas

It gives the rate limits that are implemented by the various Google-provided libraries. I can't seem to find a published rate limit for users that are POSTing directly to measurement protocol (https://www.google-analytics.com/collect).

Is there one and if so what is it?

---

Edit on 10 July 2015 -

A few commenters asked for an example of the kind of data I am sending in.

Using a series of calls to wget with a sleep of one second between each call.

Here is an example with the app name and tracking code removed:

wget -nv --post-data 'ul=en&qt=7150000&av=0.0.1&ea=PLET&v=1&tid=<my_tracking_code>&ec=Move+to+Object&cid=1434738538-738-654031&an=<my_app_name>&t=event' -O /dev/null 'https://www.google-analytics.com/collect'

I've tried sending these queries to the /debug endpoint and all of them are valid. My first upload worked as expected and reports looked good. Subsequent uploads of the same data set to different GA properties have had mixed results. Sometimes no data appears in reports. Sometimes partial data appears in reports. During upload, realtime reports always show activity, though.

---

Answer 1

Last Update: Please watch this video which explains all GA quotas policies: https://youtu.be/1UfER93ALxo

In particular, your issue might be result of 10 requests / 1 second limitation: https://youtu.be/1UfER93ALxo?t=5m27s

I can confirm the same thing. In my case I had own buildHitTask which constructs URL for a measurement protocol request (MPR) and stores it in the hitPayload field. But instead of original GA reporting - I was saving those URLs into cookies for delayed reporting.

In my experiment, only 10-20% of 2,000 measurement protocol requests were actually "stored".

Rest of hits are not available in GA Reporting UI, neither API or BigQuery. Each request was sent with 2 seconds delay via new Image() method, and slowdown in case of errors. Received results are not consistent. Both success and failed hits are randomly distributed across whole time period.

Please let me know in case if you find more details on this constraint!

Answer 2

Directly from the documentation Google Analytics Collection Limits and Quotas

These limits apply to the Web Property / Property / Tracking ID.

10 million hits per month per property

Measurement protocol

Universal Analytics Enabled

This applies to analytics.js, Android iOS SDK, and the Measurement Protocol.

200,000 hits per user per day 500 hits per session not including ecommerce (item and transaction hit types). If you go over either of these limits, additional hits will not be processed for that session / day, respectively. These limits apply to Premium as well.

Now I agree it doesn't specifically state the per second it rate for measurement protocol but the above one dumped Measurement in with analytics.js so I think we can assume its

analytics.js:

Each analytics.js tracker object starts with 20 hits that are replenished at a rate of 2 hit per second. Applies to all hits except for ecommerce (item or transaction).

But just to make sure I am sending an email off to the development team they should make it more clear where the per second rate of the measurement protocol lies. I will repost here when I hear from them

Response from Google

The Measurement Protocol does not do any kind of rate limiting or quota-ing by IP address or tracking ID or anything like that. However, most of the client libraries do rate limit in some form or another.

As Linda points out in her answer, there are various limits and quotas imposed by the back end, but those are done at processing time, not collection time.

Conclusion

There is no limit to sending data through the measurement protocol. But when the data is processed limit may be applied. I think they may be referring to the max 2 million hits a month. It seems it's the libraries that apply limits on how fast you can send data not the measurement protocol directly.